Mr RB
Well-Known Member
Hi, this is an idea I have had for a while and I would like to get some feedback from the "great minds" of the forum (ie people who I have discussed RNGs and encryption etc with in the past).
The idea would be to use a cheap PIC 18F micro that has +10k ROM and +2k RAM, as a very good Psuedo RNG (PRNG) like my Black RNG, which produces a very large stream of random data where the process in the PIC cannot be reverse engineered by receiving any of that data.
The PIC is plugged into a USB serial port only when encryption or decription of a file is required, and only sends/receives serial (so there is no access to re-program the PIC).
Basic principle to encrypt a file;
1. typed in text password -> seeded into blank PC cache
2. PC runs its PRNG -> fills PC cache with random data
3. a 32bit checksum (of the cache) is sent to PIC, PIC uses checksum to reseed its cache
4. PIC runs it's PRNG -> fills PIC cache with random data
5. a 32bit checksum is sent back to the PC, PC uses that checksum to reseed its cache
(goto 2 and repeat)
The process ends when an amount of random data has been produced that is the same size as the file to be encrypted. Encryption occurs on the fly, so each byte of the file is encrypted in turn.
This means there is never one "state" of either RNG which represents the whole encryption, and could possibly be "captured" by a memory capturing trojan etc on the PC.
Likewise the remote PIC cannot have it's state captured, any serial snoop trojan etc could only ever capture the 32bit checksums to and from the PIC.
Ideally, if a third party does not have access to the PIC the encrypted data is uncreakable.
Also, if two identical PICs exist they can be used by two parties to decrypt each other's encrypted files.
Any weaknesses? The best I have at this point is that if the typed in password was known (say captured with a trojan keylogger) then that message encrypted with that password could possibly be decrypted by someone who could fully reverse engineer the PC side software AND had a recording of all the serial checksums.
However if the text password was different then all checksums and checksum replies would be different, so knowlege of a previous password or previous checksums would be useless. So ideally if a different password was used on each file or transmission then they still remain unbreakable.
I'm open to suggestions.
The idea would be to use a cheap PIC 18F micro that has +10k ROM and +2k RAM, as a very good Psuedo RNG (PRNG) like my Black RNG, which produces a very large stream of random data where the process in the PIC cannot be reverse engineered by receiving any of that data.
The PIC is plugged into a USB serial port only when encryption or decription of a file is required, and only sends/receives serial (so there is no access to re-program the PIC).
Basic principle to encrypt a file;
1. typed in text password -> seeded into blank PC cache
2. PC runs its PRNG -> fills PC cache with random data
3. a 32bit checksum (of the cache) is sent to PIC, PIC uses checksum to reseed its cache
4. PIC runs it's PRNG -> fills PIC cache with random data
5. a 32bit checksum is sent back to the PC, PC uses that checksum to reseed its cache
(goto 2 and repeat)
The process ends when an amount of random data has been produced that is the same size as the file to be encrypted. Encryption occurs on the fly, so each byte of the file is encrypted in turn.
This means there is never one "state" of either RNG which represents the whole encryption, and could possibly be "captured" by a memory capturing trojan etc on the PC.
Likewise the remote PIC cannot have it's state captured, any serial snoop trojan etc could only ever capture the 32bit checksums to and from the PIC.
Ideally, if a third party does not have access to the PIC the encrypted data is uncreakable.
Also, if two identical PICs exist they can be used by two parties to decrypt each other's encrypted files.
Any weaknesses? The best I have at this point is that if the typed in password was known (say captured with a trojan keylogger) then that message encrypted with that password could possibly be decrypted by someone who could fully reverse engineer the PC side software AND had a recording of all the serial checksums.
However if the text password was different then all checksums and checksum replies would be different, so knowlege of a previous password or previous checksums would be useless. So ideally if a different password was used on each file or transmission then they still remain unbreakable.
I'm open to suggestions.