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."
Why can I never undestand articles about cryptography?
They always seem to be written in a way that makes them incomprehensible.
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?!
U.S. Army Guide to Code Breaking.
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.
The first rule of USENET is you do not talk about USENET.
That is really awesome.
Now I just need the US Army Guide To Understanding The US Army Guide To Code Breaking
+5, Truth
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!
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.
Xenu loves you!
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...
I think it'd be fun to try to compress white noise files, and see how well it compresses.
WHITE NOISE DRINKING GAME:
Ingredients:
BSD-based systems with random number generators, need to be the same or it's just unfair.
Your favorite method of compression.
Alcohol
Steps:
1) each of you dd if=/dev/urandom of=./noise.txt for however big you want the file to be. Bigger is better, imho.
2) bzip2 noise.txt or your favorite compression algorithm
3) whoever's file size is the highest has to drink.
You can mix it up and write a shell script that does the following:
TIME=`date +%s`
bzip2 $1
TIME=`date +%s`-$TIME
echo $TIME sec. elapsed
+5, Truth
I just used MD5 as my encryption mechanism and the files will NEVER be recovered.
This "joke" such as it is was based on a real world experience where the "smart" IT chap at a company I helped had in his words...
"Tried a number of different compression and encryption approaches and MD5 consistently gave the smallest files"
I asked if they had ever done a recovery, and strangely they had not... it was fun watching them try.
An Eye for an Eye will make the whole world blind - Gandhi
Fiction, but still good:
Neal Stephenson - Cryptonomicon
Then to explain how Enoch Root lives so long, you'll need to read
Neal Stephenson - The Baroque Cycle Trilogy
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
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
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