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

What?

[Anonymous Coward]

Why can I never undestand articles about cryptography?

They always seem to be written in a way that makes them incomprehensible.

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.

Re:What?

[Anonymous Coward]

OK, let me be clear.
Alice ("A") writes a story about Cryptography ("C") to the IBM Developerworks site ("D"). Bob ("B") is watching over her shoulder, essentially intercepting the photons ("-->P")
Bob, then submits the story to the Slashdot ("S")
Anonymous Coward Reader ("R") is confused because they are written in a way (encrypted "+*+") to make them incomprehensible.

So essentially, you are saying you don't understand:
R ?= A(D)--->P(B)+*+"--->S
What could be simpler than that???

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?

[rholliday]

I suppose technically that's correct. But, "The encryption schem you use today has holes in it, and the tools will get small enough to go through those holes just a few years down the road." just doesn't quite roll off the tongue. :)

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:Why a few years down the road?

[squoozer]

No no. Encryption is like a pair of socks. Just like socks over time encryption wears out and develops holes. The holes can be fixed by darning er patching but they aren't ever as comfy as before.

Related earlier slashdot story

[karvind]

U.S. Army Guide to Code Breaking.

I just encrypt disks full of white noise nowadays

[mikeophile]

At some point, decryption techniques will evolve to translate it to something cool.

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.

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.

Re:why no encryption by default?

[RAMMS EIN]

``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?

Re:why no encryption by default?

[Detritus]

RSA is normally only used for encrypting a private key for a symmetric encryption algorithm like DES or AES. In the group of symmetric encryption algorithms, DES is one of the slowest algorithms. It has many operations that are easy to do in hardware but awkward to do in software. AES is much faster.

Mod parent up

[utopianfiat]

That is really awesome.
Now I just need the US Army Guide To Understanding The US 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:Premise is nonsense

[ComputerSlicer23]

Any chance you can cite that? I've good looking (primarily because I wanted to know when). The closet thing I've found is this

The email I'm referring to is down a little ways.

the break is in the diffie hellman key exchange for des based on 127 bits. it was done quite a while ago, solving the discrete log problem for the field 2 ** 127 -1. the work was with ron mullin at the university of waterloo. the actual implementation of the algorithms was done on the denelcor hep supercomputer (since defunct) in 1984. there were several technical papers by mullin and by coppersmith at ibm yorktown on the method of attack. our paper on the implementation which includes a description of the algorithm but not the gory details, was in the proceedings of the international conference on parallel processing in the summer of 1984. i can send you a copy if you dont have access to the proceedings. the paper actually won the best paper award at that conference, no $$, but i got a plaque for my wall and denelcor sold a machine to nsa. the reason i mentioned it to van was that sun has now done two talks at meetings about their security on the network that is based on des using the diffie hellman key exchange in exactly the field that we broke. both times the talk was given by the programmer who is implementing it not the mathematician who decided what to be implemented. i pointed them again to the papers on it; hope a number theorist there actually reads them.

Which doesn't clearly state if she did the implementation. It sure reads like she implemented someone from IBM's concept, or she wrote a paper about someone's implementation. I can't really tell from what she wrote.

However, whatever you are referring to appears to be reasonable hard to find on Google. I put in her name, DES, Boulder and encryption and various subsets. Whatever she did appears to be relatively lost to the sands of times as far as Google is concerned.

Kirby

Re:Premise is nonsense

[Anonymous Coward]

This does not make sense. Using paired primes to attack DES? DES isn't based on primes, it is based on shuffling bits around iteratively (a Feistel network.) Decrypting password files from an /etc/passwd file? For that context, DES is used in hash mode, and password *doesn't* decrypt - because multiple passwords end up with the *same* hash.

Also, searching reveals Evi Nemeth talking about implementing a break of a DES keyexchange using Diffie-Hellmann: Date: Fri, 30 Oct 87 19:32:32 MST From: evi@boulder.Colorado.EDU (Evi Nemeth) To: Eric.Cooper@SPICE.CS.CMU.EDU Subject: Re: DES breakthroughs? the break is in the diffie hellman key exchange for des based on 127 bits. it was done quite a while ago, solving the discrete log problem for the field 2 ** 127 -1. the work was with ron mullin at the university of waterloo. the actual implementation of the algorithms was done on the denelcor hep supercomputer (since defunct) in 1984. there were several technical papers by mullin and by coppersmith at ibm yorktown on the method of attack. our paper on the implementation which includes a description of the algorithm but not the gory details, was in the proceedings of the international conference on parallel processing in the summer of 1984. i can send you a copy if you dont have access to the proceedings. the paper actually won the best paper award at that conference, no $$, but i got a plaque for my wall and denelcor sold a machine to nsa. the reason i mentioned it to van was that sun has now done two talks at meetings about their security on the network that is based on des using the diffie hellman key exchange in exactly the field that we broke. both times the talk was given by the programmer who is implementing it not the mathematician who decided what to be implemented. i pointed them again to the papers on it; hope a number theorist there actually reads them. evi This seems likely as having been misunderstood as a break of DES itself. A Diffie-Hellman break would match with the database generation and with using primes.

Eivind.

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.

AES Far from Secure

[generationxyu]

TFA mentions using AES, TDES, or RSA as alternatives to DES. He also says, "...the final AES standard is estimated to require a current cryptanalysis system 149 trillion years to decrypt." That may be true for direct-channel cryptanalysis, but side-channel attacks such as cache timings against most implementations of AES can guess the key given known plaintext, known ciphertext, and at least estimated timings for encryption.

Read more: http://cr.yp.to/antiforgery/cachetiming-20050414.p df

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.

Re:Author appears ignorant about cryptography

[Mocenigo]

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.

Exactly, and this because the asymmetric part (RSA) is very slow compared to a symmetric algorithm. So we use the asymmetric part only to perform a key agreement protocol, in other words to agree on a new key to be used in the following symmetric part.

In fact, RSA is starting to age quickly, and there are far better alternatives.
Since there are subexponential algorithms to solve the factoring problem, RSA key sizes will increase a lot in the next years, and will soon be in the thousands of bits.

There are many other choices for asymmetric schemes, and there are groups for which no subexponential attacks in the key or block size are known. These should be used in conjunction with a symmetric scheme such as AES.

Very attractive today are elliptic curves (ECC endorsed also by the NSA, no less [*]) and low genus hyperelliptic curves (HECC). a 140 bit ECC or HECC key offers security equivalent to 1024 bit RSA. The bandwidth advantages are evident, and at this level speed is of the same orged of magnitude, with an advantage of ECC and HECC over RSA.

Arjen Klaas Lenstra wrote a nice contribution in Key Lengths to The Handbook of Information Security. If you cross-reference with the paper he wrote with Erik Verheul on Selecting Key lengths, you will see that 200 bit ECC and HECC should be equivalent to about 4000 bit RSA security, which should be a good estimate for a good security level for the year 2050 - the NSA is proposing to use 571 bit ECC, which provides security equivalent to about 15,000 bit RSA. Now, creating good istances of RSA moduli of that size is lengthy, and at the same time the cryptographic operations become extremely slow. ECC and HECC mantain good speed though.

Multivariate quadratic systems can be used to construct both secure and efficient public key schemes. Their main problem is the key size, which can easily go to several hundreds of kilobytes. But, the attacks are exponential in the block size, which, for the so-called oil-and-vinegar schemes, remain well bounded. They are very fast and are nice for exchanging keys for the symmetric scheme following the asymmetric part.

Lattice-based systems, NTRU (which can be interpreted as a special lattice based system) are also nice alternatives, but it is difficult to construct secure instances. Code-based systems are vey nice, but the main advantages are short signatures, hence their main application is outside the scenario considered here.

[*] The E.U. is endorsing elliptic curves, too. A strategic project, AREHCC, did extensive Advanced Research on Elliptic and Hyperelliptic Curve Cryptography. The web site of the project, now ended, is still up (http://www.arehcc.com/) and there is a bit of interesting material. A book has been just published on the subject, by authors that worked for AREHCC:

R. Avanzi, H. Cohen, C. Doche, G. Frey, T. Lange, K. Nguyen, and F. Vercauteren.
Handbook of Elliptic and Hyperelliptic Curve Cryptography.
Chapman & Hall - CRC Press. 2005.

This is a mammoth book, and for a leaner introduction, with less theory but perhaps better for practitioners one can get

D. Hankerson, A. J. Menezes, and S. A. Vanstone.
Guide to elliptic curve cryptography.
Springer-Verlag, Berlin, 2003.

a very well written introduction. Then there are the two books edited by Blake, Seroussi, and Smart, on ECC. The latter titles however lack a treatment of HECC.

A follow-up project to AREHCC (and NESSIE), called ECRYPT (http://www.ecrypt.eu.org/), has also considerable resources devoted to alternatives to RSA - including ECC, HECC, and all the other alternatives mention

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.

What happened to IDEA encryption method?

[RouterSlayer]

I see tons of articles, but no one talks about "IDEA" any more.

from my research so far it hasn't been cracked. it was a european standard, so I guess it's not favorable in the US or north america.

it's still my favorite. and maybe it enjoys a bit of "security through obscurity" these days. But I'd really like to know.

and oh, if you're going to say it was cracked, please provide reliable references with links.

Seriously, I'd really like to know.

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

Re:I just encrypt disks full of white noise nowada

[utopianfiat]

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

HA!

[MosesJones]

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.

Re:HA!

[utopianfiat]

"Oh my god, MD5 ate the files!"
"WHAT?"
"It just finished digesting!"

Thank you, I'll be here all week.

And if it gets cracked...

[Overzeetop]

you can just send the justice department after them for a DMCA violation. Worked for Adobe :-)

Lal!!

[Datamonstar]

Jrr! V whfg YBIR pelcgbtencul!

Recommended reading for those with an interest...

[CdBee]

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

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

Anything other than OTP is weak encryption

[blair1q]

One-time pad (OTP) is the only "unbreakable" encryption.

The rest are algorithmic, and therefore susceptible to decryption by algorithmic attacks. Decryption of them is a matter of being clued to the nature of the algorithm, and perhaps in possession of the knowledge of a secret constant with which the decryption algorithm can be generated. And once the constant is guessed, all messages based on it are decrypted.

The only ways to decipher OTP-encrypted messages are to physically access the encryption or decryption pads, or steal the cleartext before it's encrypted or after it's decrypted.

(Note: since VENONA was not used only once, it's not actually OTP.)

Re:Anything other than OTP is weak encryption

[Jerry Coffin]

One-time pad (OTP) is the only "unbreakable" encryption.

True, but incomplete -- under the right circumstances, even an OTP can be broken.

To ensure that an OTP is unbreakable, you not only have to ensure that the key is used only once, but you also have to ensure that the key is completely unpredictable. This means starting with a truly random source, and ensuring against introducing bias in sampling that random source.

The problem with this is that most random sources have relatively low bandwidth. Those who really care may want to visit David Wagner's links page at: http://www.cs.berkeley.edu/~daw/rnd/. About halfway down the page is a section on random number generation hardware.

Most of these aren't very useful to provide key material for OTPs though -- they just don't provide enough random bits fast enough to provide much bandwidth.

That, of course, brings us back to the Achille's heel of OTP: the key is just as large as the message. If you can distribute the key securely, why don't you just send the original message by that secure route and be done with it? Clearly there are situations in which this doesn't apply, but it renders the OTP useless for most.

On a more or less unrelated aside, I was a bit disappointed -- if there's been any mention of elliptical curve cryptograpy, I've missed it...

--
The universe is a figment of its own imagination.

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:World War II encryption tech

[Anonymous Coward]

The success of using Navajo wasn't so much due to Japan being a closed society; it was because there were no Navajo speakers outside the US at all, and the language had no alphabet and had never been written down. On top of all that, they spoke in coded ways that didn't even make sense to untrained Navajo speakers.

I can guarantee you that the Polish would have been just as stymied by the Navajo "Code-talkers" as the Japanese were.

Re:World War II encryption tech

[Trurl's Machine]

The success of using Navajo wasn't so much due to Japan being a closed society; it was because there were no Navajo speakers outside the US at all, .

But there were anthropologists, researchers, people who studied Navajo language etc. Japan "closedness" resulted in comparatively low interest in anthropology in general - while in pre-WWII European countries, including Poland, there were people studying alien cultures just for sake of interest in otherness as such. There are no native Nambikwara speakers outside Brasil but in case of war between Brasil and France, French code breakers could break the "Nambikwara code" thanks to works done on Nambikwara by Claude Levi-Strauss. The point is that there were no Levi-Strausses in Japan.

Re:World War II encryption tech

[imsabbel]

Its called security by obscurity and is generally considered not cool.

Re:I just encrypt disks full of white noise nowada

[dpilot]

I actually HAVE mod points, at the moment. But there's nothing on the pulldown for amusingly, pathetically, distressingly nerdy. Sometimes I wonder how many people get some of Jason's jokes in Foxtrot, and how he manages to get them into a mainstream newspaper comic.

All this shows is

[el_womble]

how useless popular comms software is. Why should I have to register with Verisign to send an encrypted email to my girlfriend, co-workers etc. Why can't I just click a button and generate a random 128 bit key set and use PGP?

Why isn't this standard? A better question is, why can I send a MIME encoded attachement anywhere, but not a PGP encoded plain text email? Imagine the spam you could filter if you had a list of the PGP keys of all your friends and family. Imgaine if they moved email address, but there PGP key stayed the same.

If this is because Zimmerman want his 2 cents (which I can't blame him for) can't it be included in the cost of Windows and Macs, and let the rest of us download it for free? We need authenticatable (if there is such a word) emails, IMs etc yesterday. We have the technology!

Re:All this shows is

[starfishsystems]

We need authenticatable (if there is such a word) emails, IMs etc yesterday.

Sure, fine, we all know that. But the practical question is how do you start up such a communication in the first place? In other words, how do two parties share a secret without communicating it, and thereby risking its exposure?

The answer is not to share a secret, but instead to use an asymmetric key pair and only communicate the public key. But this only solves part of the problem. Now you can communicate in secret, but you can't be sure who is on the other end.

The answer to this second problem is for both parties to register with a trusted third party. This is why organizations such as Verisign exist, and likewise why PGP has the concept of a "ring of trust". Got it?

humans are better

[digitalderbs]

bWbhy blbeave bibt btbo bab bcbomputer bwbhen bab bhbuman bcban bdbo bab bbbetter bjbob?

Simon Singh's Codebook

[SenseOfHumor]

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!).

Re:Pet Peeve

[arkanes]

On behalf of PhDs everywhere: fuck you. Use MD if it's really important for you to flaunt yourself. Or you could just take a hint from *every other* profession in the *entire world*, and not think that your choice of profession entitles you to a special honorific.

Time to increase GPG default keysize?

[akratic]

Is it time to increase the default keysize in GPG?

Currently, the default key generation method in GPG is to create a 1024 bit DSA master key and Elgamal subkeys. The GNU Privacy Handbook admits that a key size of 1024 bits is "not especially good given today's factoring technology."

If the authors of GPG know that 1024 bits is not a good key length for an asymmetric cipher, why not set the default length for the master key at 2048 bits? If that would require switching to RSA as the default signing algorithm, why not do it?

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.

Parent is total bollocks

[Paul Crowley]

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.