Slashdot Mirror
When Pretty Good Privacy Isn't Good Enough
st. augustine writes "Worried that the NSA already knows how to crack
PGP? Someone calling themselves Hardened Criminal
Software has a one-time pad package called HardEncrypt that could be the answer to your paranoia. The sci.crypt Snake Oil FAQ teaches us to beware of one-time pad claims, but it looks like Hardened Criminal has done their homework. No bogus bit-stream algorithms or pseudo-random number generators. And it's open-source, so everyone can bang on it and fix any problems.
I'd try it myself, but I'm outside the US, and the
Bernstein decision doesn't apply in New York. :-)"
None of which matters if you have the key.
The problem with most "uncrackable" schemes is that they do not dedicate the same resources to key management as they do to theoretical power. Key management is *THE* hard problem in cryptographic systems, and the #1 way to break a system. In practice, something like BlowFish with a 128-bit (or if you're paranoid, 256-bit) key is pretty much unbreakable today, and public key encryption methods are used to do the "hard part" (key management to exchange keys for the "real" encryption method), thus reducing the possibility of it being broken by the expedient of reducing the amount of crypto-text available to be attacked.
Of course, there's always the possibility that some quantum leap in mathematical knowledge will make asymetrical (public key) algorithms unsafe. But symmetric algorithms like BlowFish do not share that quality, and it is a LOT easier to distribute keys for BlowFish than to distribute keys for One Time Pads (said keys which must be the same length as the text to be encrypted/decrypted).
-E
Send mail here if you want to reach me.
If you are using /dev/random as a source of "true" randomness,I encourage you to look elsewhere. I wrote a program to give me passwords from /dev/random once (/dev/random %95)+32 type deal. I started to notice that certain characters were not produced as often as others. I then did many "cat /dev/random >>/tmp/randfile", then I did an 8 bit histogram on the resulting data (I collected 300K of /dev/random), I found some *disturbing* results... like for example the standard deviation was .1, and the extreams in the histogram where > 400 standard deviations away from the mean. in fact I could reliably sort the data on its histogram count. this is not good randomness for a OTP situation.
...that to encrypt your hard drive, for example, you would need to retain a decryption key of exactly the same size as the encrypted chunk! While this may be useful for securely encrypting small, highly sensitive files, bulk encryption presents the rather massive problem of managing the key -- which is now as sensitive as the data encrypted.
Geeky modern art T-shirts
You can already go to http://www.replay.com (a Dutch site) and download all the crypto you'd ever want. The problem is that we can't put encryption into the Linux kernel, because the Feds then would shut down all the U.S. Linux kernel mirrors as "illegally exporting armaments" (sheesh).
-E
Send mail here if you want to reach me.
The mark of a good encryption algorithm is that even if the opponent has seized your computer and has the complete source code to the encryption algorithm (perhaps by reverse-engineering the program), he cannot crack your crypto-text without the key.
In other words, security by obscurity does not work in reality, so you might as well use well-tested algorithms that are provably secure (well, secure at today's state-of-the-art anyhow, I make no promises for fifty years from now!). Design of crypto algorithms is HARD. It's very easy to make mistakes. So it's best to use algorithms that are well-known and that have been extensively analyzed, because even experts make mistakes (hmm, was it RC4 that had the weak keys?).
-E
Send mail here if you want to reach me.
Looks like the one time pad strikes again!
/dev/random output and using a simple script to XOR. /dev/random is carefully designed (largely by our own Ted Ts'o). Given what the HardEncrypt people say about sound header files, I find it difficult to believe that anywhere near the same care went into the design.
Yes, OTP's are completely invulnerable when used correctly. This is similar to saying Micros~1 software doesn't crash when it doesn't come across any bugs.
The essence of OTP is almost trivially simple: generate a large random file, distribute it securely to the receiver of the file, then XOR it with the message. The receiver XOR's it back, and voila, the message!
Of course, the trick here is securely conveying the random file to your communications partner. This is almost as hard as getting a secret message across. You can't email it, or even send it encrypted, because that reduces the security to the weakest link. Thus, all OTP gives you is a form of time-arbitrage. If you can do a secure transmission at time A, that gives you a free secure transmission at later time B.
Then you have to worry about only using the pad once. If you use it twice, your message is totally toast. During WWII, a lot of traffic was gathered this way.
Finally, you need to worry about the keying material. If it's recovered (on either side), your messages are also toast. Since you need to store the key between the time of key exchange and the time of message exchange, it's a pretty ripe target for somebody to snatch off your hard drive. And forget about storing it encrypted - the same weakest link problem.
So this is why people don't use OTP's. You get perfect theoretical security, but in practice keeping track of the keying material is a bitch.
Finally, if you really want to do OTP, I recommend grabbing some
Happy ciphering!
LILO boot: linux init=/usr/bin/emacs
I have no faith in the good intentions of my government, but I do have faith in the academic community's ability to successfully analyze mathematical algorithms -- which is all that encryption is.
With symmetrical algorithms 256 bits gets you unbreakable for the next 50 years or so (depends on the algorithm, of course, but I'm thinking a good one like one of the AES finalists). With assymetrical (public key) encryption there is a bit of doubt there -- the public key does include information that could be used to derive the private key, but it would require a quantum leap in our ability to solve certain hard mathematical problems.
In any event, if I'm a national government and I want to ruin your life all I have to do is flash my FBI batch at your local sheriff's office, tell him that you are a drug trafficer, and then said sheriff can immediately burst into your home and sieze your property and all bank accounts. You then must prove that your possessions were not bought with drug money in order to get them back, but how are you going to do that without money to hire a lawyer (because they siezed your bank accounts, remember?). And how are you going to do that without a job, because said deputies burst into your employer's office, told them you were a drug dealer, and seized your computer at work, thus resulting in you being fired? We already have a police state, it just tries to be polite about it except when dealing with what the majority thinks is the "scum of society".
-E
Send mail here if you want to reach me.
For about ten years now, I've been viewing the terms 'PGP' and 'uncrackable' as pretty interchangable. Granted, I'm not the cypherpunk I should be, but I'm pretty sure the only way you're getting into PGP is by some sort of distributed cracking attempt.
Or am I wrong? There's a first time for everything.
In that case the key management problem is even worse, don't you think? That old annoying secure channel paradox: You need a totally secure channel to exchange the key. However, if you have a totally trusted secure channel you don't need encryption at all.
... it certainly will be too long and random to memorize. I'm afraid OTP's are even less useful for secret data exchange than storage encryption.
The exception, of course, is if you have a secure channel at one point in time for key distribution and to establish a protocol for exchange of data at a later time... just don't run out of OTP key data! And, of course, now both the originator and the recipient of the data must securely store the OTP data
Geeky modern art T-shirts
That would be fine, I agree... The key distribution problem restricts what you can do with OTPs to a limited set of problems, but if your problem falls within that domain it's acceptable.
However, if you do this, please for gods sake don't use this program! While the encrypt function is trivial (and bad, still, for reasons I briefly explain later), the GenKeyFile as ATROCIOUS . It makes me physically ill to think that anyone would pass that off as an OTP generation function.
The attack on it is trivial, given physical access to the machine. (I.e. it was seized, etc.) Presuming the GenKeyFile program was used, the key file is generated using rand(), seeking through a seed file and generating the bits for the 'true' key file. Even if you wipe the 'true' key file (that gets generated by this program), but keep your initial seed file around (i.e. you're using \winnt\system32\mfc.dll to generate your random bits), here's what your security comes down to:
32 bits of seed (for rand())
n bits of search where 2^n is the number of files in your filesystem (or the next power of two over it).
The assault on this method is as follows:
For each file in the system, iterate over the 32 bits of rand(seed) space, and test the resultant file for known plaintext. (What's that, you believe that they don't know any plaintext in your document? Not true! Headers, average character counts, etc., all are telltales!) With only 32 bits of seed for your rand() function (or 64 if somehow you have an extended rand()), the keyspace is not sufficient to produce truly random output. Thus the number of matches that will generate a pattern that is similar to the expected pattern (text, images, etc., all have non-random recognizable patterns) is very small, and might be zero.
There are four components to this 'encryption package':
If you keep the seed file OR the keyfile around, then this encryption is 100% useless. The seed file can be found, and the rand() function gives you *LESS* protection than DES, and MUCH less than IDEA, 3DES, etc...
Even if you've erased both your keyfile and your seed file, if the attacker can presume that you ever USED GenKeyFile to make your key data, the resultant ciphertext will be encrypted with patterns that are the result of the patterns in the seed file, mixed with the (reasonably well known) patterns of the rand() function. This patterned data can be identified by a sufficiently dedicated attacker, even w/o the original source file. Do not use GenKeyFile!
You're *far* better off using
Seriously, this is snake oil. Well meaning snake oil, but snake oil nonetheless. Presuming a seized computer, and either the use of GenKeyFile at ALL , or the preservation of your used key file, this gives ABSOLUTELY ZERO PROTECTION FROM A COMPETENT ATTACKER.
Cyberfox!
p.s. While the encrypt program is still useful with an OTP generated from a secure source, it SHOULD be repeatedly wiping the used padbits out of the Psuedo-OTP's filespace as it goes, but it's not... Another example of less-than-stellar competency.
Important related note: You don't use an OTP to encrypt to yourself, because you never ever ever want to keep the OTP bits a millisecond longer than it takes to encrypt it initially.
p.p.s I can't say this enough, but I'll try one more time, please, please, please DO NOT USE GENKEYFILE TO BUILD YOUR KEY FILE!
The very name tells you the one time pad is meant to be used one time, yet the author states:
After you make a key file, you can use it over and over again
and helpfully suggests that
you might want to make a separate key file for each person with whom you want to exchange encrypted files
No no no! You DO NOT re-use one time pads. You DO NOT share one key with multiple people even with "lesser" crypto systems, but ESPECIALLY withone time pads, because that implies re-use.
One time pads are only unbreakable when used just once. Multiple uses leave clues for analysis.
Anyone who knows even a little about crypto knows that the weakest link is managing the keys. That's why PGP's private keys are hidden by that obnoxious pass phrase. If the black bag guys break into your computer and copy your PGP files, they still have to decrypt them because your pass phrase muddles things. With this one time pad, they have the key immediately, no further work required.
This guy seems to imply you should keep your one time key lying aorund the hard disk so you can encrypt and decrypt at will. Good gosh, PGP encrypts the private key with the pass phrase at least. Here you leave your one time key OUT IN THE OPEN, and REUSE it, over and over again. This is NOT secure crypto.
THIS IS LESS SECURE THAN PGP. This is a silly little toy and DOES NOT PROVIDE SECURITY.
He massively understates how easy it is to factor RSA private keys. He says "it is possible", yet he is wrong. Until and unless new algorithms are found, there are not enough atoms in the universe to factor 4096 bit keys before the universe collapses back into the next big bang. Luck does not enter into it. There is only so much theoretical computational power available in the lifetime of the universe; it won't crack even a single key. And if you spread it over multiple keys, then the chances for any single attack drop correspondingly.
--
Infuriate left and right
...that they're almost completely useless for most tasks.
A full discussion of one-time pads can be found in Applied Cryptography, 2nd ed, by Bruce Schneier (page 15).
One time pads have several problems that make them useless for anything but locking individual files (and even then, it's quite a pain).
Onetime pads, while cool in a theoretical sense, are useless to virtually everyone with the exception of diplomats. For diplomatic use, they can solve the key storage/distribution problem via CDROMs/Digital tapes transport via diplomatic courier bags. Everyone else is screwed. Even the millitary doesn't generally use onetime pads because of the key distribution problem.
Stick to high-keylength public key or symetric cyphers. They're far more useful, and the likelihood of them being broken by even the likes of the NSA is not good.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
The first thing that amazes me is that we don't have a good random number generator in hardware. For various reasons you cannot build a perfect one in software - software has to be deterministic. But you can in hardware.
:-)
The trick is that you have to come up with a process that generates a random bit-stream. The classic example is 2 Geiger counters side by side. (Throw away results from both that arrive shortly after the either fires. There is a slight latency and this gets you independence.) There are variations of this that can easily be set up in silicon much more economically.
But, you say, this gives you a biased stream? Yes, but an independent, random one. The next step is to take the output in pairs, drop the pairs that are the same, and then take the first bit. This gives you an independent unbiased bit stream. Well there is a miniscule bias, however it is slight enough that it would not be reliably detectable if the machine operated for several billion years. I consider that acceptable.
This does throw away about 3/4 of the data. Some of this can be recovered and used, after all your "accept, don't accept" is a bit-stream, and so is the set of values from the pairs that agreed. Both are more heavily biased than your original, but a few layers of this will get a lot more information extracted.
Unfortunately no such random number generator done in hardware is widely deployed. If it were then encryption would be a lot better than it is today but...
My other thought was an encryption algorithm that requires lots of random data, but is better than a OTP for transmitting a stream. First of all a common but bad algorithm is to XOR a bit stream with a random block of data, but reuse the block. While a OTP is unbreakable this variation is easy to break. Just XOR the output with itself shifted over, and when you hit the length of the stream you will get a large spike in certain characters. That tells you the length and a good cryptographer can work quickly from there.
A slight variation on this would be to have 2 random blocks of data, of different length, and XOR both of them against the original. This is still breakable but it is harder since each block hides the other.
My idea is to have the 2 random blocks of data, but have the transmitted stream of data be randomly sending the message and replacements for each block. This means that the random blocks of data are each hiding the other and the transmitted changes to the key, while they are themselves getting replaced.
I suspect that if you devote enough of your bitstream to the replacement of the bitstream that this variation is very secure. Unfortunately it needs a large supply of really random bits, and that is not easy to come by...
Regards,
Ben
PS One supply of pretty random data is as follows. Compress some large binaries as much as you can, and then sample the result. A well-compressed file looks a lot like random data...
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht