Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Unbreakable encryption using a (home made) hardware dongle.

Status
Not open for further replies.
Ok, I still have some morning coffee left so I write a scenario how I could decrypt any message without the dongle. I make some assumptions that I hope are correct.

This is the key information that I base this scenario to:

Assumptions:
- I know how the PC software works.
- The USB dongle is a black box to me.
- The (PC-side) PRNG creates x Kb of random data for every 32 bit checksum it receives from the dongle.
- This x Kb of random data is used to encrypt x Kb plaintext "on the fly".
- I know your password.

1) I initialize the PC-side PRNG with your password.

2) I take first x Kb of the ciphertext and brute force it. All I have to do is to iterate through 2^32 possible checksum inputs to the PC-side PRNG.

3) After this the PC-side PRNG should be in correct state for me to brute force the next x Kb of the chiphertext.
...

Ok, there is an important point missing. The PC PRNG is a cumulative process. The PC has a circular cache of 1million random bits, but these bits are not know to you. Those million bits are the result of numerous back/forth cycles between the PC and PIC, and each time a checksum is scrambled INTO the EXISTING million bit cache.

No encrypting is done until there have been at least X cycles between both the RNGs, with many checksums.

So the "random" content of the million bit cache is totally dependent on ALL previous processes, all checksums, typed passwords and PIC internal key etc.

Then each cycle (with 2 checksums) that million bit cache spits out 1000 bits etc which are used as the data key to encrypt the file. So with those 1000 bits chosen randomly from 1 million bits you can't guess the contents of the million bits.

TO WTP Pepper; I don't have problem with you wanting to use 128bit AES on a micro to do your encrypting, although it's not really relevant to trying to find security flaws with my proposed system.
 
Are you planning to continue this idea.. simulation or prototype?

No encrypting is done until there have been at least X cycles between both the RNGs, with many checksums.

I think this is the most important thing to ensure very hard-to-break encryption. You will end up with encryption that is made from small X kilobyte pieces where each piece is encrypted with unique "very long" key.
 
Last edited:
an OTP would not be difficult to implement. ANY binary file could be used as a key. the encrypted file would have an index location where in the file the key begins at, and the user would have to memorize the filename of the key. the plaintext is xor'ed with the binary data to produce ciphertext. each time the key is used for generating ciphertext, the program stores an offset for the last byte it used in the keyfile, so that the next time it encrypts, it begins at that location, and no two messages are encrypted with the same string of bytes from the key. the sender and receiver would need to use the exact same file for the binary key. it's not advisable to do this using windows system files as a key, as auto updates often overwrite many of these files with new versions.

for example, one could record white noise from an FM radio into a wav file that's many Mb in size, and call it noise.wav, and use this as a key file, or use a jpeg file, or any binary file. an exe file may not be a good choice, since there are sections of repetitive data.
 
Last edited:
Hi MisterT, yes I was planning to continue although this has not been a rush project, and is still hobby level priority, and I have lots of time consuming "proper" work on at the moment too.

I have been working on a few of the support areas, for instance I have built a hardware RNG that generates entropy from 100% physical bits with no math processing. The project is small and cheap and pretty much finished, i have been just writing up a web page for it, and when done will post more info on this forum too. You can see some of the dev work on the other forum "All About Circuits" in the project section, with "hardware RNG" in the title.

I have also coded up a windows app to visually display the RNG data entropy in a number of ways to better allow me to fine tune RNG systems etc, I will release that as freeware soon also. Hopefully I can put together a small suite of free RNG and encryption tools on my web page over the next few months. :)

UncleJed613; Yes it's easy enough to use a one time pad from a large random file. The problem I see with that is that files themselves are NOT secure. Even if you keep the RNG key file "safe" on a hardware dongle, your software can't read that until you plug the dongle in and then the whole file is loaded into PC RAM using the very standard and hackable windows APIs, so the moment your software works, a snoop program can just grab the entire key file from the PC RAM and all security is lost.

The system I am proposing has the benefit that; not only is much of the key data on the hardware dongle, but a lot of the process is also done on the dongle and neither the process nor the key is available anywhere, unless they have the dongle AND pull it apart.
 
Last edited:
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top