Unbreakable encryption using a (home made) hardware dongle.

[Mr RB]

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.

 

[KeepItSimpleStupid]

Would this help? http://www.cyberguys.com/product-details/?productid=63758

Also type "USB AES" in their search box. There is a gizmo that will encrypt over USB. Didn't understand it.

Then there is this: http://storage.toshiba.com/storagesolutions/pc-notebook/mkxx61gsyg-series

 

[()blivion]

I'm not one of the "great minds" of the past, but that doesn't mean I don't know anything about this kind of stuff.

Just to clear something up first, is this theoretical dongle firmware open to the public? I'm assuming yes. Anyway...

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.

In theory, yes, but in practical firmware implementations this is not necessarily true. If I know anything about MCU's it's that there are ways to get information out of them when you shouldn't be able to. But it's a shot in the dark to be sure. It's possible to find a flaw in the PIC's firmware that allows data leakage through typical software exploitation techniques, especially if your firmware is written in C using the standard C library. This flaw could be in the PIC's USB stack or your end user code, it won't matter, a flaw is a flaw. Also as you're no doubt are aware, some PIC18 have self programing capability's usually specifically to support USB boot loaders. (you see what I'm getting at?) If a flaw in the firmware was found, even with it's a Harvard architecture one could get the ability to write bytes of program memory, or read bytes of data memory. So getting information out of this device from just a x86 PC program is possible.

In the end, the above is all academic. If you had the resources of a good sized country, then yes it's totally do able. But you would most likely have to have at least that. It would take months, maybe years of good hard R&D to figure it out. But once figured out it can be a simple, small, fast piece of code that does the job perfectly. I always wanted to check and see just how exploitable PIC18's are. I was even thinking of creating some firmware specifically to play with the idea. It would work something along the lines of return oriented programing to get enough elicit instructions executed on the PIC to read or write arbitrary things to arbitrary places. Then the dominoes fall down and it's game over.

In short.... *THIS* is one possible problem. Even with PIC's.

 

[Mr RB]

Would this help? http://www.cyberguys.com/product-details/?productid=63758
...

Thanks for the links. I've seen these encrypted thumb drives, they are useful enough but have a number of issues;
1; it says; "Meets specific agency directives like TAA and FIPS compliance". That means the standard AES encryption is one the agencies can easily break.
2. " 256-bit Advanced Encryption Standard (AES)". My proposed system would use a million bit encryption, which itself is also of a much higher standard than AES, bit for bit.

The main issue with those encrypted dongles is the data is inside and the dongle and the encrypter/decrypter must be transported together. With my proposed system the data can be transported, but the necessary hardware component needed to decrypt it is kept elsewhere, physically secure.

...
Then there is this: http://storage.toshiba.com/storagesolutions/pc-notebook/mkxx61gsyg-series

Interesting! I had not seen those before, but it is basically just a hard drive with another AES chip built in. Basically it offers the same security as the dongle as the data can easily be read directly from the hard disk (or dongle EEPROM) and the AES (likely with a short user password) can easily be broken. As easily as using a keylogger to get the user's passwords, or maybe just as easy using a brute-force password spammer.

...
Just to clear something up first, is this theoretical dongle firmware open to the public? I'm assuming yes.
...

For my own use I would not release the firmware for the PIC hardware. But if firmware was released it would contain a random password in the order of 10kbyte (80kbit). There are also many other variables that can be changed in the black RNG, which could be made available for each user to customise if they were to build one.

Thanks for raising this as a potential security issue but even if someone was to program a brute-force system to try to break the encryption they would have to emulate both the 1Mbit RNG in the PC in conjunction with every combination of the 80kbit PIC RNG, and all possible user passwords... Just the 80kbit in the PIC represents 10^24000 combinations that all have to be emulated! The RNG I am talking about not only has an enormous amount of states but can use any amount of time for encryption, to increase security, unlike a standard algorithm like AES.

...
Anyway...
In theory, yes, but in practical firmware implementations this is not necessarily true. If I know anything about MCU's it's that there are ways to get information out of them when you shouldn't be able to. But it's a shot in the dark to be sure. It's possible to find a flaw in the PIC's firmware that allows data leakage through typical software exploitation techniques, especially if your firmware is written in C using the standard C library. This flaw could be in the PIC's USB stack or your end user code, it won't matter, a flaw is a flaw.
...

No that's not possible. The PIC would only RX and TX checksums through it's serial port (USART) and that talks to USB via a standard FT232 type USB->serial IC. Once the hardware dongle is built it cannot possibly be hacked via interception or communication, only by physical breakdown to get to the PIC and then attempting to beat it's hardware protection and then read its ROM.

And that is not really likely, because if someone has the dongle they can decrypt everything without pulling it apart!

Please keep the critiques coming, it would be good to find some flaw with this system.

 

[()blivion]

So we are talking about a Rs232 to USB conversion? That certainly improves the security. But that doesn't make it impossible.

I don't know if I am explaining myself properly, or just not understanding you properly. So I'll try again.

Corrections
I was not talking about intercepting the data being sent to and from the PC and PIC. And I was certainly not talking about brute forcing the PIC's internal state. The idea was about sending a specially crafted set of data to the PIC that is far from what the PIC expects to see. This can potentially cause the firmware to screw up in a predictable way. This can lead to a simple leaking of information if the program memory protection bits are enabled. Or allow execution of arbitrary PIC instructions provided the proper memory protections are off. The idea is based on standard "hacking" technology. And either situation ruins the security of the system if the PC is assumed compromised.

Below is an example scenario depicting that the over all process is possible. It is a highly fictitious example using overly simplified algorithms and routines that are unrealistic or obsolete, so would most likely have no real practical use. This was only done for simplicity's sake, the CONCEPT is still applicable to real world situations, it would just be more complicated to implement and much harder to explain.

Overview
The the security of this theoretical system hinges on the fact that the information in the USB dongle is secret information that a malicious individual can not ever acquire because the attacker can not know the internal state of the PIC without programer level access. However, through malicious software running on a PC communicating to the dongle via serial protocols, the attacker can send crafted data to the PIC that eventually gains control over it. This is possible if flaws in data handling exist and the PIC18 has unprotected self write ability. Then the attacker has the ability to read and write the contents of any memory space, it is absolute control over the device and thus unhindered access to it's secret information.

Theoretical example
Let's postulate that this device was built, it used a serial port as "stdin", it used the C library function "gets" to get data from the serial port, and it has no program memory read or write protections enabled.

Because "gets" is what reads the serial port, the PIC firmware routine will require a "stop byte" from the PC side to signal that the checksum data has been fully sent. Under normal operation this is fine, because the PC program will only ever sends the correct amount of data to the PIC, followed by a proper stop byte. However if we are attackers that have compromised the connected PC, we can alter the software so as to send whatever we want to the PIC. This creates a security flaw because if no stop byte is sent to the PIC, the firmware will continue to read serial port received chars and put them in data memory one address at a time, no matter how many bytes the PC sends to the PIC.

So, we send more data to the PIC than what is expected by the serial port routine. We send a dummy checksum made of irrelevant data, and then we tack on some extra data to the end. The PIC takes this serial port input, one char at a time, and writes it to it's internal buffer, incrementing the data memory address pointer each time. However... after it gets to the end of the checksum, there is still more data left to be stored and the PC does not send the stop signal. Now because it's more efficient, the space made in the PIC firmware was only made just big enough for the checksum, since that was what the PIC was expecting to be storing. Because of this, the PIC is going to take any extra data it gets, and write it to data memory locations beyond the space for it, regardless of whether that other memory is being used already or not.

What this means is that some information in the PIC is going to get overwritten with DATA THE ATTACKER CONTROLS!!!

Now, let's assume that right after the checksum buffer, is some critical control data for internal house cleaning subroutines. For a HIGHLY farfetched and convenient example, let's assume the next data memory addresses after the checksum buffer is buffers used for a program memory subroutine of some kind. The order of data after the checksum is...

(1) A pointer to a location in program memory that the subroutine is going to work with.
(2) The buffer for storing information to be written or read to program memory.
(3) A control byte/bit that decides if we are reading or writing that memory address.

Normally, The data in these three buffers is only ever controlled internally by the PIC when the house cleaning subroutines are called. This part of the firmware works properly and would not be accessible from the outside. However, the algorithm that takes serial data and writes it to data memory IS INTERNAL to the PIC, and we ARE able to force it to write data to those buffers. Because of this, and because of the flaw in that algorithm, we as attackers are able to seed this critical algorithm with data that we control. Even though we shouldn't be able to.

This gives us the ability to program any byte of program memory in the PIC, with any data, as many times as we want!!

So in theory if the above system really existed, we could craft our own small PIC program that would read the contents of the data memory out on the serial port back to the PC. Turn that program into it's hex form as raw data, then we send the dummy checksum, the address of an unused area in program memory, the first instruction of our malicious PIC program, and the fact that it is a write operation, and finally the expected stop byte. When the PIC gets the stop char, the serial reading algorithm will terminate, then the PIC will do what ever it does until the house cleaning subroutines are called. This routine will do what it is supposed to do, BUT it will be doing it with our control data, which instructs it to write our program to program memory. Then we just repeat this process until our small program is fully written to the PIC. All this would be packaged with our PC malware, and would effect the PC software (driver or application) that communicates with the dongle.

Conclusion
I could program a PIC to prove the above scenario, so it is physically possible. However, it is certainly quite preventable. In the end, to know if this theory is PRACTICABLE and to stop it from happening, you need to account for at least these things when making your project....

Is there boundary checking for incoming data on the PIC's serial port?
What language is the PIC firmware written in? (ASM > C in this respect)
What library functions are used? (also a problem caused by C, refer to this)
Is the PIC's program memory protected?
Is the PIC's firmware source code available for study?
What buffers are after the checksum buffer?

If you can account for the above things totally and completely, then you can make the hack impossible. It is all a matter of if the PIC controls the data transactions, or if the PC does. Putting all the control in the PIC's hands with well written buffer handling is the best way to prevent this problem from happening. If the PC get's to decide anything, always assume it will decide to do the absolute worst things. And program the PIC to be able to handle it.

If I feel like it I may write up a program for a random PIC18 that demonstrates the above exploit. It should be totally working within MPlab, but also 100% workable with real hardware.

 

[Mr RB]

Thanks for taking the time post all of that, and I have read it all and (hopefully) understand correctly what you are proposing.

From my viewpoint, none of that will be an issue. The proposed system would use the PIC 8bit USART module. The PIC would receive a 4byte checksum at a fixed baudrate. In the event of any data error, like; >4bytes <4bytes or timeout, the PIC would realise a data error and send a single error byte back out the USART.

In the event of any 4 contiguous bytes being received, the PIC would treat it as a valid checksum, and store the 4 bytes into 4 RAM locations. The PIC then mathematically hashes those 4 bytes (32bit checksum) into the RNG cache data. The cache would be probably 1kb (8000 bits) in length.

Then the PIC RNG is run for X amount of cycles, scrambling the data in the cache until it is 8000 bits that cannot be reverse engineered to the original 32bit checksum. Then a math process derives a "result" 32bit checksum from the contents of the 8000 bit cache. That is sent back via USART as a "reply" checksum to the PC.

Because the 32bit "question" checksum is only hashed into the existing 8000bit cache, not replacing the cache, it means the same 32bit checksum will deliver a totally different result even if called repeatedly (in a fashion similar to "rolling code" RNGs.

The 32bit replay checksum could not be reverse engineered to give the 8000 bit cache data, nor could the 8000 bit cache be rev engineered from the first 32bit (question) checksum.

On the PC side, the process is basically the same but the cache will be 1 million bits in length and the speed of the PC means the RNG process can be done for a lot more iterations. Then a new checksum is generated and sent back to the PIC.

The combination of the two large but private RNGs scrambling each other is used to generate (cyclically and in real time) the key data used for encryption and decryption.

I hope that explains better the overall process I had in mind. I will also answer your specific questions;
1. Yes there is 4byte "boundary checking" for PIC RX data
2. usually C, although I often use some inline assmbler for speed
3. no library functions are used for serial, i usually just grab the RX byte from register RCREG, if a byte is there
4. yes the PIC would be code protected
5. PIC C source would be available if I release a public version for people to make (my personal device would differ in operation somewhat)
6. I can't see buffer placement as being relevant for the reaons outlined above

Thanks for your time.

 

[WTP Pepper]

Google TEA (Tiny Encryption Algorithm) for a simple and highly effective routine.
Without having the time to read all the responses, I think you are looking for a Public/Private key algorithm.
There are many out there, just implement them correctly.

BTW, never consider any algorithm unbreakable. It's only a matter of time and the amount of effort a code breaker will do before he/she will break it.
You can learn alot about this by reading about Alan Turing and the Bletchley Park cryptoanalysers. He was a genius of our time.

ALWAYS ALWAYS use publically published algorithms. They will have been scrutinsed by the world experts. Never use anything that the author will not disclose how it works. It could be complete rubbish.

Remember, the strength of a good algorithm should always be with the key.

 

[()blivion]

Google TEA (Tiny Encryption Algorithm) for a simple and highly effective routine.

TEA is worthless for strong encryption. Way to easy to bruteforce. To symmetrical.

It's intended purpose is for data that becomes obsolete fast, but needs real time protection. They use it in games, server-to-client encryption. It has low overhead/latency but an acceptable level of encryption for it's speed. But It's not suited for maximum level of security encryption.

Halo PC uses TEA.... among other games.

BTW, never consider any algorithm unbreakable.

The one time pad method has been mathematically proven to be unbreakable.

ALWAYS ALWAYS use publically published algorithms.

This is true, you never know when your "perfect" algo has a stupid simple problem that makes it easy to crack. One is always best to use what has been around for a while.

 

[Mr RB]

...
BTW, never consider any algorithm unbreakable. It's only a matter of time and the amount of effort a code breaker will do before he/she will break it.
...

Many systems are totally unbreakable, and some are theoretically breakable but infeasible to do so, like a key with 80000 bits, which is breakable but would take hundreds of years even on the fastest computers.

...
ALWAYS ALWAYS use publically published algorithms. They will have been scrutinsed by the world experts.

I disagree, and it's not relevant. Standard algorithms are generally optimised for standard use, for on the fly encryption like DES and AES etc when applied to a data stream. They need to be fast, and they are necessarily low in overal data security.

Custom algorithms can be an entire order of magnitude harder to break simply because they do not need to be small, fast and on the fly like standard commercial algorithms. So in terms of maximum security, standard algorithms are of a "poor" performance.

I'm not new to this, what I am asking is for people to discuss any flaws this proposed system might have that may be exploited, so I can address those potential flaws when creating the system.

...Remember, the strength of a good algorithm should always be with the key.

Absolutely, and with most standard algorithms the key is as poor as a 8 character typed password. I'm essentially proposing a 80000+ bit password "key" which is contained in a hardware dongle and cannot be accessed by observation of data to/from that dongle, and that 80000 bit "key" used upon a 1 million bit slow crypto engine. This is NOT an 8 character password used on a 256 bit fast crypto engine.

There's obvious similarities to a public/private key system, although I am not proposing any public key there are really two private keys.

I appreciate ()blivion's input re the potential issues with the serial data to and from the hardware dongle, and I think that has already been addressed.

Hopefully MisterT or anyone else might have a look in to this thread and suggest a possible security issue, or ()blivion might have some more good suggestions.

 

[()blivion]

or ()blivion might have some more good suggestions.

LOL, I'm working on it, but I really don't see a obvious flaw in your system. Seems plausibly uncrackable. You really do need that 1kB key. Brute forcing such things is virtually impossible with even the fastest modern supper computer that I know of. But still, I wouldn't underestimate the governments of the world. For all we know they have massive quantum, optical, or chemo-mechanical computers that specialized in cracking all known types of encryption and are thus trillions and trillions of times faster than anything us civilians have even seen.

Though that is being a bit paranoid to say the least. A variation of the Rijndael algo is used by the NSA for national secrets... allegedly.

Edit: Oh... and a list of peoples names has cracked more encrypted data than all the crypto analytic computers in the world combined.

 

[misterT]

Many systems are totally unbreakable, and some are theoretically breakable but infeasible to do so, like a key with 80000 bits, which is breakable but would take hundreds of years even on the fastest computers.

256 bit AES key would take 3.6*10^59 years (worst case) to break if you do it by brute force and at 10 GHz rate. Compare that time to the age of the universe (2.7*10^49 years). Of course AES can be broken more "easily" than that, but still 80 Kb key sounds a little overkill. AES is "weak" because of its simple algorithm, not because of the short key. But there's nothing wrong with extra security if you have the memory and time to encrypt/decrypt

https://www.wolframalpha.com/input/?i=((2^256)+/+10000000000)+seconds+to+years

I didn't go through all the material yet. I'll try do that later and hopefully have something useful to say

EDIT:
Did I understand correctly that the proposed system is extremely secure because of:
1) Big key (or RNG state)
2) The details of the algorithm is kept secret (contents of the PIC ROM).

Also, if I understood correctly then the security depends heavily on the size of the data being crypted (number of checksums created by the PIC).

 

[()blivion]

256 bit AES key would take 3.6*10^59 years (worst case) to break if you do it by brute force and at 10 GHz rate. Compare that time to the age of the universe (2.7*10^49 years). Of course AES can be broken more "easily" than that, but still 80 Kb key sounds a little overkill. AES is "weak" because of its simple algorithm, not because of the short key. But there's nothing wrong with extra security if you have the memory and time to encrypt/decrypt

https://www.wolframalpha.com/input/?i=((2^256)+/+10000000000)+seconds+to+years

Yup, 100%.

One thing I'd like to add too. A lot of times, it's not even running the decrypto algo that takes forever, it's checking the plain text that eats all the time.

Example. Let's say we had a plain text phrase that was no longer than 256 bytes. And we wanted to encrypt this phrase so only the intended receiver could read it. Now let's suppose we screwed up and used a 16 Bit key to encrypt with. It would take no time at all to brute force through this, if the plain text is in computer readable text format. Now let's assume the exact same scenario, but this time we take the plain text phrase and put it through CAPTCHA, turning your plain text into a long string of pixel data, *THEN* encrypt it with our 16 bit key. This image data is such that any combination of flipped bits is a valid image. It's a "raw" format image as they say. Now..... it may be easy enough to reverse the encryption for 16 bits of key and brute force through all the combinations, but checking that the plain text data you get out of the decryption process actually is valid information is a whole lot harder to do. In fact, it would be virtually impossible for a computer to do with the above example provided that CAPTCHA remains difficult. And 65,536 images is a lot to look through by hand. But with the raw plain text example, one only needs to check for a percentage of valid English words. For 16 bits, this would take milliseconds in a modern PC.

This may at first glance seem like an unrealistic situation, but there are very common data formats that can be your starting place which are pretty much just as effective at making THE WHOLE PROCESS harder to brute force. For example... zipping your files before encrypting. Some Zipping formats ("Solid compression" format for example) make the integrity of the whole message more dependent on each individual part of it. This makes an attacker have to decrypt a greater amount of cypher text each pass in order to test the brute forced messages validity.

So in conclusion, it's a lot more than just the encryption algo that makes your cypher text unfeasible to brute force.

 

[Mr RB]

...but still 80 Kb key sounds a little overkill. AES is "weak" because of its simple algorithm, not because of the short key. But there's nothing wrong with extra security if you have the memory and time to encrypt/decrypt
[.../quote]

Thanks for looking in MisterT. Yeah the 10k key was just arbitrary based on the fact that most 18F PICs have 16kbype or so of ROM, so using 10kByte as a random key should be trivial.

"Time" is a good point, but still it should not take too long, say a couple of seconds, to really hash that 80kbit key through the 8000bit RNG cache in the PIC. That is only needed on the first checksum, then each additional checksum would be much faster, a few mS or so.

...
EDIT:
Did I understand correctly that the proposed system is extremely secure because of:
1) Big key (or RNG state)
2) The details of the algorithm is kept secret (contents of the PIC ROM).
...

1. Yes, ideally nobody will have the 80kbit key apart from the person who owns the dongle, and as far as 2, no the algorithm is known BUT the TOTAL algorithm is a bifurcated RNG with very large states, where part of the RNG is inside the PC, and part of the RNG is secure within a dangle, so the two systems scramble each other, and 3. over time, in real time they produce the data key, so to decode the entire data requires a large number of cycles, requiring both RNGs working together.

Initially I was going to use the two RNGs to generate ONE data key, as the final output. But on further thought it seemed better to generate the data key on the fly as the RNGs operate over time, so the data key is not a result of any one "state" of the system, but is actually a running output from a long term scrambling process. If you remember my BlackRNG MisterT, the RNG engine "scrambles itself" over time so the algorithm and patterns are different over time, so the data key would be generated by different "algorithms" for different parts of the data key.

To ()blivion; Thanks for the tip that the inital data file could be zipped or in some other format. It sounds a little like the dreaded "obfuscation" although you are right of course the more layers of process done to the data the more total processing needed to decrypt by brute force.

 

[()blivion]

It sounds a little like the dreaded "obfuscation"

Yes and no, It's some where between "trapdoor functions" and "obfuscation". Easy to do one way, much much more difficult to do the other way. But not actually dealing with the encryption/decryption it's self.

Always remember that most all open algorithms for encryption rely on the fact that it is infeasible to run through all the possible combinations in a timely manner. This is based on the assumption that running through just one combination takes a relatively long time. So the above idea is just designed to increase the time it takes for each iteration, and thus drastically increases the time it takes to do the whole operation.

As you have pointed out, Some algorithms on the market are insecure. And this is mostly because they avoid the above in exchange for decryption speed.

 

[misterT]

Ok, I'm still not sure if I fully understood the complete system, but here is what bothers me the most:

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.

Is it possible that the amount of data is so small that the dongle is involved only for one iteration? If this is the case then only one checksum is generated by the PIC.. and all I have to do to decrypt the message is to know/guess your password and iterate through all possible 32bit checksums.

How much data I can encrypt with only one iteration (one checksum generated by the dongle)? How exactly is the "amount of random data" collected? I do remember how your RNG works.. it has a big circular buffer of random data.

EDIT: I believe we have to assume that the PC-side software is well known, because if it isn't, this conversation is useless (because the system is automatically unbreakable)

 

[misterT]

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:

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.

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.

If I don't know your password, I could brute force that also. It could take some time, but I would only need to do it once.

The point here is that if the plaintext is not mixed in the PRNG, the dongle is useless. And if you mix the data in the PRNG, you can't decrypt the message (because the PRNG can not be reverse engineered).

 

[()blivion]

Could the password not be entered into the equation from the dongle side? I know, it's a totally different device than what we were talking about, but it would defeat the above scenario.

Edit: Another thought, along the same lines of a slightly different device.

Could the dongle be made to provide a string of random data to the PC, data that is only recoverable with the dongle + it's seed/password, instead of a using a checksum method? Then you could use one time pad encryption on your plain text.

 

[WTP Pepper]

()blivion wrote:TEA is worthless for strong encryption. Way to easy to bruteforce. To symmetrical.
It depends who you are trying to hide your data from. Hackers or Well financed Government Agencies.

()blivion wrote:The one time pad method has been mathematically proven to be unbreakable.
No. It depends on how the OTK is derived. You could be stupid enough to use all "ones" which is still a OTK. A simple NLSR of say 8 bits is a OTK but very breakable.
Humans are incapable of deriving their own OTK without maths. There is the weakness.

Mr RB. I can buy a SiLabs 100Mips 8051 core processor for £3 and implement 128AES that can work on a 100Kbits stream in stream mode.

I still thinks it's all down to implentation and good asm programming skills.

Write a decent USB driver to do block encryption before writing to a USB device and you are sorted.

 

[()blivion]

WTP Pepper

()blivion wrote:TEA is worthless for strong encryption. Way to easy to bruteforce. To symmetrical.
It depends who you are trying to hide your data from. Hackers or Well financed Government Agencies.

()blivion wrote:The one time pad method has been mathematically proven to be unbreakable.
No. It depends on how the OTK is derived. You could be stupid enough to use all "ones" which is still a OTK. A simple NLSR of say 8 bits is a OTK but very breakable.

Let me clear them quotes up better for you...

TEA is worthless for STRONG ENCRYPTION. Way to easy to bruteforce. To symmetrical.

This statement can be confirmed right in the wiki entry for TEA.

TEA has a few weaknesses. Most notably, it suffers from equivalent keys—each key is equivalent to three others, which means that the effective key size is only 126 bits.[3] As a result, TEA is especially bad as a cryptographic hash function. This weakness led to a method for hacking Microsoft's Xbox game console, where the cipher was used as a hash function.[4] TEA is also susceptible to a related-key attack which requires 223 chosen plaintexts under a related-key pair, with 232 time complexity.[1] Because of these weaknesses, the XTEA cipher was designed.

Plain English, It.... has..... Weaknesses. And you don't need to be a government agency to exploit them.
[SUB](Unless you think government agency's are the ones that hacked the Xbox and not.... hackers?)[/SUB]

The one time pad METHOD has been mathematically proven to be unbreakable.

By "method", I obviously mean the whole process, including the OTK generation. I didn't mean just the algorithm. Or maybe you would prefer the term "theory" instead? This point of being mathematically unbreakable would be in contrast to something like the AES method/theory, which can be mathematically proven to be very breakable... Provided you don't have any problems waiting till time beyond the end of the universe to get your plain text.

Humans are incapable of deriving their own OTK without maths. There is the weakness.

The universe is incapable of deriving a OTK without maths. So that statement is very one sided. And it's obviously not even the point. I would write a whole explanation of what is and isn't cryptographically achievable by man right about here, but it would be wasted time.... Here, this is the point I was [obviously] trying to make. https://en.wikipedia.org/wiki/One-time_pad#Perfect_secrecy

Conclusion
Man currently cannot achieve "encryption" better than properly implementing the OTP method/theory. Anything spoken to the contrary is false.

The one thing you were saying though that I strongly agree with, is that the best encryption in the world can't stop someone from using it wrong. That's information security 101. But none of us here need that pointed out to us I don't think.

 

[misterT]

Mr RB. I can buy a SiLabs 100Mips 8051 core processor for £3 and implement 128AES that can work on a 100Kbits stream in stream mode.

True, but I think this is more like an "academic discussion" about the encryption method proposed by Mr RB. If you have problems implementing 128AES to your £3 SiLabs 100Mips 8051 core processor, start a new thread.