11-17-2022, 09:03 PM
(11-17-2022, 07:59 PM)JRace Wrote: Cool. I've always had a fascination with crypto, although I am certainly no expert. I know just enough about the subject to NEVER trust my own work. Actually, after testing the program below to make sure it worked, I filed it away and it's been my shameful little secret for years, so YOU, dear reader, are among the only people in the world, besides me, who know about this program.Thank you for this program. I made the modification for output file existence, refusing to do anything in that case. But it's what I chose to do.
This was written, as a proof-of-concept, for GWBasic back in the bronze age.
It uses a combination of substitution (by adding a "random" number to each byte), and transposition (rearrangement of bytes).
Due to the repeatable nature of the linear consequential random number generator used by GWB (and QB and QB64PE), the sequence of "random" numbers used for encryption may be easily recreated for decryption.
The program asks for the name of an Input File (which is the file you want to encrypt or decrypt), an Output File (which will contain the encrypted or decrypted data), and a Key (which will be used as the "seed" for Basic's built-in pseudo-random number generator).
WARNING:
Must be tested: run this program a few times to ensure the decrypt/encrypt goes down as expected on the same data set. Then run a program which employs "RANDOMIZE TIMER", run it (hopefully it would be a short time). After that, load this program again and test the decrypt/encrypt like before. It might be easy to emulate eg. the Timex Sinclair random number generator (I read somewhere it just stores 64KB jumbled-up numbers and always refers to that table) but trying to do it for a 16-bit software interpreter and ancient Intel-based processors is harder.
That said, an antidote is to place "RANDOMIZE" statement alone as one of the first lines in the code, then involve the integer that must be input to start, into the encryption.