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

Why a few years down the road?

[Raistlin77]

The encryption scheme you rely on today might be full of holes just a few years down the road.

If is will be full of holes just a few years down the road, wouldn't it then be correct to say it's full of holes now?!

Re:Why a few years down the road?

[bentcd]

Not if you only intended for the protection to last a couple of years.
One of the key decisions to make when choosing an encryption scheme is for how long the information is to be protected. If the answer is "until release date", then you can often get away with a very low-end encryption scheme. If the answer is "forever", then go for one time pad and it'll be secure until doomsday. Of course, one time pad is considerably more expensive in terms of administration, but as is so often the case, you get what you pay for :-)

Re:What?

[Anonymous Coward]

Cryptography is pretty heavily math-centric. To truly love cryptography over and above the obvious social factors and coolness level of being able to hide stuff, you really need to be somewhat of an academic math geek. Academia speaks a completely different language than real people. It's a hazard of living in dark hallways and not getting out much to meet the human race.

why no encryption by default?

[william_w_bush]

so... great, but why aren't most tcp streams encrypted by default? the client side load is negligable, and there is a lot of acceleration available server-side. Even relatively simple encryption would make me feel better about those voip calls I'm essentially sending in the clear over a public network.

The net is a very public network considering, and especially considering how many protocols are plaintext cheap encryption (pref in hardware) seems like it should be required. It's past the proof of concept stage, just having it work at all isn't enough anymore.

Re:why no encryption by default?

[Anonymous Coward]

so... great, but why aren't most tcp streams encrypted by default?

Because IPsec is the One True Way of doing IP encryption, and IPsec is basically unusable for opportunistic encryption.

There are lots of encryption options out there if you look for them. Protocols like email (OpenPGP and SMTP over SSL), IM (numerous IM encryption options, ranging from crap to decent), and obviously HTTP have encryption already standard and built into common implementations.

Author appears ignorant about cryptography

[Paul Crowley]

Actually, reading on, it looks like the author really doesn't have a clue. At one point he suggests using RSA in place of DES. Even most Slashdot readers know that in practice, when you use RSA for encryption, you use it in conjunction with a symmetric encryption algorithm.

IBM has considerable cryptographic expertise; it's a shame none of it was brought to bear on this article.

Re:Author appears ignorant about cryptography

[Conare]

Agreed. In addtion I like this from TFA:

New standards are emerging from NIST, including AES (Advanced Encryption Standard) and TDES (Triple DES).

Once again even most Slashdot readers know that TDES is finished emerging from NIST and is in the process of being obsoleted by AES which also emerged from NIST long ago.

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.

PGP is very useful if you have a small group or feel you can rely on out of band mechanisms for key distribution. For example, if I have been talking to you on the phone, and say I am going to email you my public key, you can be pretty sure it came from me when it arrives a little later.

In a large organization though, key distribution is more problematic, and this is where PKI excells. For example if I receive a message that purports to be from the CIO telling me to install a patch how can I be sure it is really him and not some random dude(ette)? Ah! because the certificate that contains his public key is digitally signed by an entity that I trust (because they told me that I will trust it when I took the job ). PGP is good for dealing with people you know personally or have met in some fashion. PKI is good for dealing with both people you have met personally, and people that you have not met, but need to be able to exchange secure communication with anyway.

On the other hand PGP is free.

Is /. getting astroturfed again?

[sixpaw]

The article has no discussion of truly modern encryption schemes (their description stops at RSA/PGP and they don't even go into any details); it has no discussion of why modern schemes are considered more secure than DES, no discussion of what might make them less secure (i.e., no mention of factoring/discrete logs as the root 'hard problems' behind current crypto) and no discussion of what's on the horizon in terms of things like quantum cryptography.

On the other hand, it does go into cheerful detail on why IBM's Exciting New Coprocessor (r) is the right solution for your enterprise encryption needs!

I know IBM are the 'Good Guys' and all, but that doesn't make advertising for them (especially in the form of a front-page slashdot article) any more palatable than advertising for anyone else...

World War II encryption tech

[ScaryMonkey]

The most fascinating thing to me in the history of WWII encryption is not Enigma (which was pretty cool) but what the Americans used in the Pacific war: the Navajo language. By sending messages in Navajo they utterly confounded the Japanese, who have never been slack in the figuring-things-out department. Goes to show how much stranger of a code our own laguage is, when we think about it

Re:World War II encryption tech

[Trurl's Machine]

The most fascinating thing to me in the history of WWII encryption is not Enigma (which was pretty cool) but what the Americans used in the Pacific war: the Navajo language.

There's some interesting parallel here. Pre-WWII Polish cryptography (its less known success was breaking the Soviet codes during the war of 1920 - Polish victory helped to save the entire Western world from communism) was so strong thanks to polyethnic character of Polish culture. It was not really difficult to find bilingual Polish mathematicians - fluently speaking the language of the enemy, be it Russia or Germany. Pre-WWII Japan was - and to some extent, still is - a very closed society, with little interest in the world outside. It was difficult to find anyone with any interest in other cultures or languages - not even truly bilingual, among the Japanese mathematicians. In code breaking, victory belongs to the open - not just open algorithms, but also open minded, open societies. This is also why I think that right now, the Western world needs MORE interest in islamic cultures and MORE attempts to understand them - if not for any better reason, just for better decryption of intercepted messages.

Re:AES Far from Secure

[Anonymous Coward]

if they have the plaintext, and cipher text then they most likely have the key anyway. I mean come on.

Re:OpenSSH has problems right now

[Anonymous Coward]

Using keys, how do you get into your box the first time?
What if your keys get lost on your home computer, or you have a HD crash or fire at home?
What if you are out of town and want to access your system from a friend's computer?
What if you manage this system for a lot of users, do you really want all the headaches of trying to explain how to get keys to work?
Most normal users wouldn't know the first thing about using keys in this way, they barely grasp passwords at this point.

Re:Premise is nonsense

[StephanF]

I think we need to make the point that there's a difference between a flaw in the encryption algorithm and the length of a key. Any code is crackable if you have enough time to generate every single possible key. As time passes, machines get faster and doing a brute-force attack on a 56-bit DES key doesn't look like a massive problem any more. If the algorithm is broken, it's effectively a shortcut to finding the key without having to try every permutation.