File encryption / decryption

[bplus]

Here's the source of my obfuscation:

Code: QB64: [Select]

1. DIM string1(16384) AS STRING
2. DIM string2(16384) AS STRING
3.  

Probably meant

Code: QB64: [Select]

1. DIM string1 as STRING * 16384

[SMcNeill]

Or perhaps:

DIM string1(16384) AS STRING * 1

An array of 16384 characters to process, rather than a single string?

(Though if that’s the case, why not just make it an array AS _BYTE?  No need to get ASC values then.)

[NOVARSEG]

gotta problem with that see latest thread "Having trouble with PUT"

[NOVARSEG]

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.

OK I got to be careful here. I did try my own code and it crashed . Maybe  I really don't understand how PUT and GET works. Im thinking in terms of the functionality of the DOS interrupts for file read and file write.  The inputs for those functions are location of a file buffer, number of bytes read / write and the file handle.

When  the file is read , the file pointer advances. So just before the NeXT write we gotta decrement  the  file pointer by the number of bytes that were read (using SEEK).  That is how the file is processed.

FOR i = 1 TO l
   b$ = b$ + CHR$(ASC(a$,i) XOR 97)
NEXT
PUT #1, 1, b$

where b$ is variable length
but
DIM string2 AS STRING * 16384
PUT #1, 1, string2
probably won't work the same.

[SMcNeill]

PUT works the same in QB64 as it has in all other versions of GWBASIC, QBASIC, and QB45.  It doesn’t matter if it’s a variable length, or set length string.  The commandis consistent.  ;)

[FellippeHeitor]

Not for arrays, as that behavior is QB64-exclusive. One would have to BSAVE back in the day.

[Bert22306]

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.

In other words, your "secret key" would be 97. Give that secret key "out of band," securely, to the receiver, and send the ciphertext to the receiver over an unsecured channel, and the receiver can easily recover the plaintext.

But, the problem with this scheme is that a dedicated intruder, so-called man-in-the-middle, could try to figure out what that secret key is. For example, find out what are the most repeated cipher characters. Should be encrypted forms of <space> or "e," typically. Once you have those few most-frequent examples, you can easily determine what the "secret key" was. You'll only have a short list of candidates. XOR those tentative secret keys with the ciphertext, and you'll get gibberish a couple of times maybe, then very soon recover the plaintext.

Instead, if you use 8-bit random bytes, from a PRNG, with RANDOMIZE USING (which repeats the sequence from the beginning, for any given seed value), you'll create a ciphertext that is really difficult to crack. Get that seed value to the receiver over some secure channel, and you're golden. The pseudo-random sequence has to be at least as long as the plaintext.

Another tangential point. I tried concatenating two XOR computations, using a different PRNG seed value for each set of computations. This did not improve anything. The ciphertext actually became less "random," statistically, than the single XOR method. And it could still be converted back to plaintext with only one XOR operation by the receiver.

[bplus]

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.

[NOVARSEG]

Got it working..

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

[Bert22306]

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.

True enough, but that technique, also known as "security through obscurity," has a bad reputation among cipher geeks. The "proper" way to design a crypto protocol, according to this community of geeks, is to make it "impossible" to crack, even if the bad guys know the protocol. This describes all the popular encryption protocols today.

So, in the scheme where the keystream is generated by a PRNG, this man-in-the-middle, even if he knows how the scheme works, will be required to test a huge number of possible seed values. Trial and error, but requiring a prohibitively long series of trials. Compare this with XORing always with one ASCII character, such as "a" and you can see, the series of trials will be very limited. It will probably take only two attempts, at most.

Symmetric key stream ciphers are perhaps the fastest of all encryption and decryption protocols. A variation of this is to use a block code, and then create the keystream out of the entries in each block. Another scheme is to create blocks of plaintext, but that's not as fast. Thing is, in all of these, the XOR operation is super common.

So, anything you try to devise, which ends up being repetitive, in any "security through obscurity" technique, a dedicated hacker will figure out, sooner or later.