*****
Question
In the above code is:
DIM string1(16384) AS STRING
equivalent to
DIM string1 AS STRING * 16384
for the application as shown?
****
Interesting. In your scheme, however, you will need to input two long strings, in order to encrypt or decrypt the actual plaintext file. If I read this correctly. The plaintext string1 and this string2. Or perhaps, both strings make up the plaintext?
Another way to do this, create one string, consisting of the plaintext, and then XOR each byte with a pseudo-random byte from the QB64 RANDOMIZE function.
Then, all you have to send to the receiver is the seed used in the encryption step. This has a formal name: "symmetric key stream cipher." Pretty hard to crack, as long as the random number sequence is at least as long as the plaintext.
Or, instead of XORing, another possibility is multiplication in encryption, and division in decryption. But that will create a longer ciphertext than plaintext.
Hi bplus
so they are not the same exactly?
DIM string1(16384) AS STRING
DIM string1 AS STRING * 16384
GET or PUT seems to like the array type.
bplus
Interesting
whoop made a mistake i had 2 string1
****
DIM string1(16384) AS STRING
DIM string2 AS STRING * 16384
PRINT LEN(string1())
PRINT LEN(string2)
are they the same length?
Interesting. In your scheme, however, you will need to input two long strings, in order to encrypt or decrypt the actual plaintext file. If I read this correctly. The plaintext string1 and this string2. Or perhaps, both strings make up the plaintext?
Another way to do this, create one string, consisting of the plaintext, and then XOR each byte with a pseudo-random byte from the QB64 RANDOMIZE function.
Then, all you have to send to the receiver is the seed used in the encryption step. This has a formal name: "symmetric key stream cipher." Pretty hard to crack, as long as the random number sequence is at least as long as the plaintext.
Or, instead of XORing, another possibility is multiplication in encryption, and division in decryption. But that will create a longer ciphertext than plaintext.
Fun stuff.
I just put your code in the IDE, no offense but it's a mess, which tells me you hadn't tried it yourself.
Not good.
Not only should we not try it on important files, we shouldn't try it at all, not safe.
But we couldn't run this one, as is, so there's that ;-))
I don't have any IDE at present
The middle section was left clear but I confess I don't understand what it's doing.
What the middle is an attempt to do, is to read a file in chunks of data of 16384 bytes (though I have no idea why such a number was chosen), XOR those chunks, and then put them back into the file.16384 is a binary number. It was Peter Norton's favorite size when working with files
OPEN “TEMP.TXT” FOR BINARY AS #1
l = LOF(1)
a$ = SPACE$(l)
GET #1, 1, a$
FOR i = 1 TO l
b$ = b$ + CHR$(ASC(a$,i) XOR 97)
NEXT
PUT #1, 1, b$
CLOSE
There’s the exact same program, simplified down for usability and understandability.
FOR i = 1 TO lwhere b$ is variable length
b$ = b$ + CHR$(ASC(a$,i) XOR 97)
NEXT
PUT #1, 1, b$
There’s the exact same program, simplified down for usability and understandability.
Since string1 = string$(16384,"a"), it’s nothing more than a repetitive set of “a” characters, which is CHR$(97). Since XOR works with numbers, I simply hardcoded that XOR 97 above and was done with it.
Read a file into a string.
XOR the contents of the string.
Write the string back to “encrypt” the file.
It’s that simple, unless folks just want to try and complicate things to obfuscate their code/process.
DIM string2 AS STRING 'variable length string
DIM LFILE AS _UNSIGNED LONG
DIM FPOS AS _UNSIGNED LONG
DIM NBYTES AS _UNSIGNED LONG
FPOS = 1
OPEN "TEST.TXT" FOR BINARY AS #1
LFILE = LOF(1): PRINT LOF(1)
DO
IF LFILE = 0 THEN EXIT DO
IF LFILE < 16384 THEN
string2 = SPACE$(LFILE) 'gives string2 the correct length for GET and PUT
GET #1, , string2 'file read
FPOS = FPOS + LFILE 'FPOS = file position after GET
NBYTES = LFILE
GOSUB XORstring2 'encrypt or decrypt
SEEK 1, FPOS - LFILE 'adjust file pointer
PUT #1, , string2 'file write
LFILE = 0
END IF
IF LFILE >= 16384 THEN
string2 = SPACE$(16384) 'gives string2 the correct length for GET and PUT
GET #1, , string2 'file read
FPOS = FPOS + 16384 'FPOS = file position after GET
NBYTES = 16384
GOSUB XORstring2 'encrypt or decrypt
SEEK 1, FPOS - 16384 'adjust file pointer
PUT #1, , string2 'file write
LFILE = LFILE - 16384
END IF
LOOP
PRINT "DONE"
CLOSE #1
END
XORstring2:
FOR x% = 1 TO NBYTES
a$ = MID$(string2, x%, 1)
MID$(string2, x%, 1) = CHR$(ASC(a$) XOR 97)
NEXT x%
RETURN
Wouldn't it take the "man in the middle" quite some time to figure which encryption scheme is being employed?
To me, this could be as nasty as actually trying to crack the scheme.