Slashdot Mirror
Modern History of Cryptography Techniques
Heather writes "The encryption scheme you rely on today might be full of holes just a few years down the road. Learn how far we've come in the last few decades, and why your apps need to be ready for change. This article builds on a previous article about Enigma, Germany's WWII-era encryption system."
U.S. Army Guide to Code Breaking.
DES was *not* considered "uncrackable" when it was launched. In fact, cryptographers such as Michael Weiner warned that the key was too short and described the dangers of a hardware-based key cracker practically as soon as it was announced.
The history of cryptography is not simply one of algorithms thought uncrackable being cracked. It is one of consistent refinement of our understanding and technique, but to imagine that the history of DES means we'll be breaking open 256-bit AES-encrypted messages in a few years is delusion.
Xenu loves you!
As has been mentioned, it's the job of the application to determine whether or not encryption is necessary and what type. There is no one size fits all solution that could be implemented at the network layer without creating more problems than it solves. If you're sending financial transaction information, the additional time to encrypt and sign is worthwhile. It takes time to encrypt and decrypt data. For VOIP, that may be considered an unnecessary and unacceptable inconvenience. However, from an application development standpoint, not offerring the user that choice is pretty lame.
Another reason for not having a default level of encryption at the network layer is that it takes a long time to get everyone to upgrade. Poor encryption can be worse than none in the sense that non-security-geeks don't know the difference and may assume that their connections are secure. It's better to start with the assumption that they are insecure and if that is not acceptable, mitigate against that risk with an appropriate level of encryption in the application.
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
``so... great, but why aren't most tcp streams encrypted by default?''
Because there is really no need to. I don't need to have all the public webpages I request to be sent to me over an encrypted link. Nor the publicly accessible ISO images I download. Nor the files I access over NFS. Etc. Encryption is there when I need it, but I don't need to burden myself, my computer, and the whole network infrastructure with it when I don't need it.
``the client side load is negligable''
I really don't agree with that. The process of key negotiation alone can take up to multiple seconds in many cases. On my local network, transfers are notably slower with than without SSL. Even when transmitting over the Internet, there's a noticable difference in CPU usage between transfers with and without encryption.
And don't forget that an encryption mechanism that can be decoded quicker can typically also be cracked quicker. If the decoding cost is "negligable" on a single desktop system, maybe that tells bad things about the feasability of cracking the encryption with a little botnet or campus cluster?
Please correct me if I got my facts wrong.
Simon Singh's Code Book covers history of encryption pretty extensively starting from Caesar's time. Enigma and others are covered very well.
The encryption methods are covered in layman's terms(I think!).
I can guarantee you that the Polish would have been just as stymied by the Navajo "Code-talkers" as the Japanese were.
PKI just means "public key infrastructure" and can refer to any method for managing and exchanging public keys. X.509 certificates and the entire framework of trusted authorities surrounding them are just one implementation of a PKI. PGP is another, more simplistic implementation.
So you can't really compare PGP, which is a specific application, to PKI, which is just a broad term for key management infrastructures.
And what about "PKI" (in the sense you seem to mean it) isn't free? OpenSSL can do everything with certificates that you'd ever want to do.
Implementing a program that encrypts with an OTP is a no-brainer. Any program capable of doing a bitwise XOR can do it (basically because the algoriths IS a XOR).
There are two BIG problems with OTP:
1) You need a lot of random bits (the good stuff, like this, not your cheap pseudo random numbers). You need exactly as many as your plaintext.
2) You need to securely send a copy to the intended receiver, and make sure the pads are destroyed once used.
Basically, no one does it because it's a real bitch to implement correctly (pad creation) and it's not worth the effort (unless you're using them in a hotline from Washington to Moscow or something like that).
You probably don't want a OTP. If you want something to encrypt your files and recover them with a password, you CERTAINLY don't want a OTP (in fact, you can't have one because the pad is not random, it's pseudo random, generated from the password and thus lacks the important properties of an OTP).
And very important: most companies that sell "One time pad" software usually sell snake oil, so be very careful.
And if you think you can get away with a pseudo random pad, the soviets spent some big time making pads for diplomatic and espionage messages, and made the little mistake of using the pads more than once, you can see the results here.
GPG 0x1B479C78
The most effective attacks on DES are brute force, linear cryptanalysis, and the improved davies attack (a form of differential cryptanalysis). This talk of paired primes is confused nonsense, probably to do with some sort of dictionary-based attack on Unix passwords, which is a different but related problem. It sounds like she might be using Hellman's time/space tradeoff.
Xenu loves you!