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."

Comments

Related earlier slashdot story

[karvind]

U.S. Army Guide to Code Breaking.

Premise is nonsense

[Paul Crowley]

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.

Re:Premise is nonsense

[JUSTONEMORELATTE]

FWIW, DES was effectively broken by Evi Nemeth (at CU Boulder) using a paired-primes database and an all-software solution. There was no hardware-based key cracker, there was an algorithm that took a ton of cylces to generate the db, then a simple bit of lookup code to decrypt the cyphertext.
IIRC, when she demonstrated it, they decrypted something like 5,000 passwords from a nearby /etc/passwd file in less than a minute on a Sun3.
She made a point of telling us that the NSA has a copy of her work and her database.

Re:why no encryption by default?

[qwijibo]

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.

IDEA is patented

[crimethinker]

It is my understanding that IDEA is patented (how this is even possible to patent a sequence of mathematical operations is a topic for another flamewar^Wdiscussion) and the holders of that patent wanted royalties. PGP used IDEA originally, but GnuPG wouldn't touch it for the royalty issue, and it eventually fell out of favour as other ciphers with 128-bit and larger keys became more widely available, e.g. Blowfish, Twofish, Serpent, Rijndael (AES), etc.

-paul

Re:Author appears ignorant about cryptography

[pclminion]

It is also interesting to note the bias they give PGP here. Basically, there are two good asymmetric key distribution schemes in the world: PGP and PKI.

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.

About OTP

[Ernesto Alvarez]

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.