Author Topic: File encryption / decryption  (Read 6422 times)

0 Members and 1 Guest are viewing this topic.

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: File encryption / decryption
« Reply #15 on: December 09, 2020, 01:20:40 am »
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

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: File encryption / decryption
« Reply #16 on: December 09, 2020, 01:37:19 am »
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.)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

Offline NOVARSEG

  • Forum Resident
  • Posts: 509
    • View Profile
Re: File encryption / decryption
« Reply #17 on: December 09, 2020, 01:44:37 am »
gotta problem with that see latest thread "Having trouble with PUT"

Offline NOVARSEG

  • Forum Resident
  • Posts: 509
    • View Profile
Re: File encryption / decryption
« Reply #18 on: December 09, 2020, 04:00:14 am »
Quote
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

Quote
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.

Quote
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.

« Last Edit: December 09, 2020, 04:33:15 am by NOVARSEG »

Offline SMcNeill

  • QB64 Developer
  • Forum Resident
  • Posts: 3972
    • View Profile
    • Steve’s QB64 Archive Forum
Re: File encryption / decryption
« Reply #19 on: December 09, 2020, 07:36:35 am »
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.  ;)
https://github.com/SteveMcNeill/Steve64 — A github collection of all things Steve!

FellippeHeitor

  • Guest
Re: File encryption / decryption
« Reply #20 on: December 09, 2020, 08:20:56 am »
Not for arrays, as that behavior is QB64-exclusive. One would have to BSAVE back in the day.

Offline Bert22306

  • Forum Regular
  • Posts: 206
    • View Profile
Re: File encryption / decryption
« Reply #21 on: December 09, 2020, 06:16:15 pm »
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.

Offline bplus

  • Global Moderator
  • Forum Resident
  • Posts: 8053
  • b = b + ...
    • View Profile
Re: File encryption / decryption
« Reply #22 on: December 09, 2020, 08:30:39 pm »
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.

Offline NOVARSEG

  • Forum Resident
  • Posts: 509
    • View Profile
Re: File encryption / decryption
« Reply #23 on: December 09, 2020, 08:59:47 pm »
Got it working..

Quote
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
« Last Edit: December 09, 2020, 09:06:05 pm by NOVARSEG »

Offline Bert22306

  • Forum Regular
  • Posts: 206
    • View Profile
Re: File encryption / decryption
« Reply #24 on: December 09, 2020, 09:14:31 pm »
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.
« Last Edit: December 09, 2020, 09:25:30 pm by Bert22306 »