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?

[amcdiarmid]

PS: The PCIXCC meets or exceeds all NIST requirements for a secure encryption device. Buy one

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

Re:What?

[TCM]

Did you try to ROT13 them?

Re:What?

[Mohamed W. Bush]

It's because they are encrypted...

Re:What?

[jonadab]

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

It's more than this. The language most "real" people speak has neither the vocabulary nor the precision to express the kinds of concepts needed to discuss cryptography. Even if you could describe (e.g.) DES without using any strange words that a third-grader wouldn't know, you would nevertheless be using the words in strange *ways* that said third-grader would nevertheless not recognise or instantly comprehend without explanation.

Re:What?

[Heian-794]

OP: I don't know about you, but the complicated vocabulary in cryptography articles has given me more word power. Admit it, you couldn't use the phrase "squeamish ossifrage" with confidence before you began studying cryptography!

Re:What?

[Knetzar]

You forgot to include the Cryptography ("C"), but otherwise, it's pretty simple.

Re:What?

[Ohreally_factor]

I have much better luck with ROT26, which is what I used to encrypt this message.

All I need is ROT13 !

[Artie_Effim]

it works just fine, who needs your special AES crap. Come-on, if it is ok for Cisco IOS password, LM hashes and my luggage password (13..14..15..16..17) I'm sure it is ok for everything else.

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?

[djtrialprice]

If we're just talking about encryption (and not security) then as long as factoring large numbers remains computationally hard, RSA will always be secure enough for any practical purpose. Just keep on increasing the size of your initial key generating primes.

No?

Re:Why a few years down the road?

[Anonymous Coward]

No.

-Microsoft

Re:Why a few years down the road?

[Anonymous Coward]

but as is so often the case, you get what you pay for

Pay peanuts, get monkeys.

Wonder what that means for the engineers from Asian geographies being put forward as a cost-saving option to IT departments?

Seriouslly, back on topic, that is certainly true with encryption, but you need something of a calculation to really know cost/benifit. It isn't just what you have to pay now, but to consider to possibly degrading level of security provided over the lifetime of the security requirement to really know the true value you are getting.

Re:Why a few years down the road?

[Crixus]

Yes, of course that's true.

I suspect all current encryption schemes have weaknesses that will be epxloitable in the future. It's just a question of when. Is the NSA still 10 years ahead of the state of the art?

    Civilian crypto has come a long way and that's a good thing.

  Rich...

Re:Why a few years down the road?

[Anonymous Coward]

Time for a vocabulary lesson.
This is known as the "cover time".
If I send a message that you will decrypt and act on immediately a cipher that takes a week to break may be sufficient. (To late for the 'snoop' to do anything of consequence with the info.)
If I send a message that I want to keep secret for 10 years and the 'snoop' can decrypt it in 5 years then the cipher has insufficient 'cover time' for its purpose.

Re:Why a few years down the road?

[StarvingSE]

As computers get faster and hardware is improved, it will be easier and more feasible to brute force current encryption schemes in the future. I am assuming that this is what TFA means about holes.

Re:Why a few years down the road?

[Anonymous Coward]

no, full of potholes ;)

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.

Re:Why a few years down the road?

[Anonymous Coward]

What open source programs implement OTP encryption as an option for encypting files?

I see some stuff on sourceforge without any releases files, and this: http://hcsoftware.sourceforge.net/HardEncrypt/Hard Encrypt.html but do any of the major crypto packages (gpg) let you use a OTP?

Re:Why a few years down the road?

[Phred T. Magnificent]

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

Yes, but whether that's immediately important depends on what kind of hole it is. There are several possibilities:

• 
     
• Brute Force Cryptanalysis: or, just try every possible key until you find one that works. This is a known (and unpreventable) hole in every cryptosystem except the one-time pad. However, the feasibility of exploiting the "hole" depends on Moore's law and the length of the key. 56-bit DES was very secure a few years ago, but it's trivial to brute-force today.
• 
     
• Holes depending on mathematical tricks: These may exist in whatever cryptosystem you pick. However, there may or may not be anyone who knows the trick. Until it's discovered, the hole will go undetected and unexploited.
• 
     
• Key management holes. This is entirely independent of the strength of the cipher itself. The biggest problem with the one-time pad is the key management problem (essentially, if you have a secure method for transporting and storing the key, then you have a secure method for transporting and storing the message, so why do you need to encrypt it at all?) Weak key management, and the related holes of human weakness, are often the easiest holes to exploit, regardless of the cryptosystem involved. (See also the Jargon File entry entitled "Rubber-hose cryptanalysis")
  

Re:Why a few years down the road?

[Anonymous Coward]

Excellent turn of phrase!

Well said, sir. (Or ma'am?)

Re:Why a few years down the road?

[cryptoz]

Brute force is certainly not the weakness. Our cryptography schemes these days can last millions of years against a flat-out brute force attack. My guess is that TFA is more referring to attacks that figure out sensitive information about the PRNG, or using a noise attack, or something. Not brute force.

Re:Why a few years down the road?

[Stone Cold Troll]

If the answer is "forever", then go for one time pad and it'll be secure until doomsday.

If you're going to do that, you might as well leave it in cleartext and save yourself some trouble. One time pads are useful in very specific circumstances, and permanent protection of stored material is not one of them. Remember that OTP requires a key of the same length as the message, so if you encrypt you message of length n with an OTP, you then have to store securely a key of length n. If your key is compromised, so is your message. This being the case, just apply whatever security you would use to keep the key secret to the message itself and save yourself the trouble of having to store both the ciphertext and key (basically, treat the message itself as the key).

A more appropriate use of OTPs is to timeshift the exchange of a secret. For example, when sending covert operatives into the field, the handlers will issue them a set of OTP keys to be used to encrypt any secret communications between them. This is quite different from the way cryptography is generally used in the real world, which is to turn a big secret into a smaller one (i.e. instead of having to transmit a 5k message securely, we only have to exchange a 256 bit key, and the ciphertext of the message can be sent in the clear).

Now, if you wanted to publish the ciphertext in a public forum, but ensure that only certain individuals would ever be able to decrypt it, an OTP might be a good way to do that, depending on your key exchange and management scheme.

Re:Why a few years down the road?

[Anonymous Coward]

Its not open source but there is a commercial OTP package available. Check out Alpha Cipher from Vadium Technologies.

Related earlier slashdot story

[karvind]

U.S. Army Guide to Code Breaking.

Re:Related earlier slashdot story

[Keeper_to_late]

Actually its a 4 month course to understand that manual. Quite a good course I might add :)

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?

[bfree]

So what sort of encryption would you place on a multicast stream? It is the job of the applications involved to determine if encryption is required, not the networks.

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?

[j-tull]

TCP streams are not encrypted by default because, contrary to your claims, the potential performance degradation caused by mass ad-hoc encryption is far from negligible. Not everyone is running the latest-and-greatest hardware. My Grandma (who will come back later in this rant) is still using a P333. Do we really want to lock out traffic from people who don't care if you can read their email or listen to their VoIP conversations?

Speaking of VoIP, I'm pretty sure this was well covered several weeks ago here.

As for required hardware encryption, are you freaking kidding? First, certain classes of cryptography are better suited to certain problem domains (key exchange comes to mind). Second, think of the fallout if/when a major flaw is found in this "required encryption." A software vender can push updates with a fair amount of ease, but hardware updates are a bit trickier. (Maybe not for the Slashdot crowd, but surely for my Grandma).

Re:why no encryption by default?

[heatdeath]

Not only that, but encrypted traffic is harder to compress, since you encrypt away the patterns in, say, HTML files.

For 99% of the information you request, encryption is useless. The problem isn't TCP, the problem is people who don't use encrypted protocols for private data.

Re:why no encryption by default?

[nkh]

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

Isn't IPv6 supposed to have some kind of embedded encryption scheme? I remember reading about it somewhere.

Re:why no encryption by default?

[__aamcgs2220]

TCP is not used for transmitting voice in most applications. Why would you want retransmissions during a conversation? There is no TCP stream, and therefore no "negligible-load" encryption. Do you want to ask about encryption of UDP streams now? Nice try. Come back in a few years when you actually know something about networks.

Re:why no encryption by default?

[Anonymous Coward]

This is why it iss usually feasable to compress, then encrypt.

Re:why no encryption by default?

[fbjon]

Generally, one compresses output before encryption, not after.

Re:why no encryption by default?

[Calyth]

Well Phil Zimmermann is working on the encryption on VoIP, I think...
Back when the Internet was still ARPANET, there was little need to encrypt anything, and as you can see the whole TCP/IP model have been overly trusting.
IPSec could be use to secure things, but the load isn't negligable. My friend had complained that using encrypted Jabber was kinda slow for him on a P3 laptop, and although I was using a 4096-bit key (yes I have my tin foil hat on), the session key couldn't be that bad, and the session is encrypted symetrically - I was using my GPG key, and the key couldn't nearly be as bad of 4096 bits of asym encryption.

Re:why no encryption by default?

[william_w_bush]

err, yes but your assumption assumes that people believe voip and similar apps are secure now? haven't heard vonage blast on it's latest marketing campaign "oh yeah, btw don't do banking by phone on this, because you can get screwed."

if nobody knows how is it more secure than bad encryption?

otherwise i'd agree.

Re:why no encryption by default?

[Fnord666]

Not to mention the new CALEA requirements that the FCC has imposed on VOIP systems. A hardware solution would have ended up being costly to replace or modify at this point.

Re:why no encryption by default?

[Detritus]

Your Grandmother's PC has more than enough CPU cycles to encrypt all of her network traffic. A 333 MHz Celeron can encrypt 7.771E6 bytes/second with DES. See Efficient Implementation of the Data Encryption Standard.

Re:why no encryption by default?

[j-tull]

Interesting link. Too bad it doesn't solve the problem.

DES, first and foremost, is not secure in the incarnation described above. Jim Bidzos, president of RSA Data Security, Inc. observed in 1999 that

It has been widely known that... the government's DES standard, offer[s] only marginal protection against a committed adversary

Not to mention that DES alone is insufficient to handle complex problems such as key exchange and replay attacks.

For a fun history lesson, you might enjoy reading Cracking DES (that is, if you can find it). It's worth noting that this book was first published in 1998. That's about it for the Dead Encryption Standard.

Re:why no encryption by default?

[Detritus]

DES may be relatively insecure, but it is also the "worst case" for speed of encryption via software. That is why it is a useful choice for benchmarks.

I've read "Cracking DES". DES is still useful for many applications.

Re:why no encryption by default?

[j-tull]

I must be misunderstanding what you mean by "worst case." RSA, for example, is MUCH MUCH MUCH slower than DES. In fact, I was under the impression that DES was one of the fastest mainstream encryption algorithms. hmmm....

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.

Re:why no encryption by default?

[swillden]

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.

It takes far, far less time to encrypt and decrypt data than it does to encode and decode the audio stream. Stream ciphers like RC4 are so fast that their overhead is utterly negligible on PCs today -- and even PCs of ten years ago. Heck, the tiny, low-powered processors in the typical WiFi access point can encrypt data with RC4 at at least six megabits per second, and *that* includes a computationally expensive rekeying operation on every packet. Sure, it would cost something to use some public key technology to establish the session key, but that only needs to be done once per connection. A few extra data bits would also be needed to allow keystream resynchronization when things got out of whack, but that's negligible compared to the overhead of IP, UDP and link layer headers that are there anyway.

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

[fishbowl]

"to imagine that the history of DES means we'll be breaking open 256-bit AES-encrypted messages in a few years is delusion."

Yes, I wonder if the successes of the past will lead to some sort of overconfidence that codes will always be broken, in the manner of Enigma.

Re:Premise is nonsense

[swelke]

A good point. The (/.) description is wrong in that it implies that there is some recently discovered type of vulnerability. The truth is that if you have paid any attention to cryptography stories in the last decade, this article is just rehashing old news. Besides that, it goes out of its way to tell us just how wonderful IBM is. (Hardly surprising, as it's on ibm.com)

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

[baywulf]

What does DES has to do with paired-primes btw? From my basic understanding of DES, there is nothing other than XOR and bit twiddling in the DES algorithm and I don't see the connection with prime numbers.

Re:Premise is nonsense

[JUSTONEMORELATTE]

Sorry that I don't have a citation -- I wasn't at the conference -- she told the story to me and other students of her 'Special Topics in Computer Networking' class in 1991, maybe 1992.
I googled a bit, and found several pages with the same short bio text about her:

... Nemeth is best known for originally identifying inadequacies in and breaking the "Diffie-Hellman trap," the mathematical basis for a large portion of modern network cryptography.

Hopefully that helps you in your googling.

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

[Fnord666]

The article also states that in 1998 the EFF cracked DES in 3 hours, but according to the reference they cite, it took an average of 4.5 days, and the fastest result was 56 hours. This was using dedicated hardware.

From the cited article:

"Fast forward to 1998. Under the direction of John Gilmore of the EFF, a team spent $220,000 and built a machine that can go through the entire 56-bit DES key space in an average of 4.5 days. On July 17, 1998, they announced they had cracked a 56-bit key in 56 hours. The computer, called Deep Crack, uses 27 boards each containing 64 chips, and is capable of testing 90 billion keys a second. "

Re:Premise is nonsense

[quasi_steller]

Yeah, I was thinking the same thing. I remember learning in my Cryptography class back in school that DES wasn't considered very secure by many cryptographers back in the 80's and how surprising it really is that it took so long to come up with another standard. In fact, the known insecurity of DES is the reason that people started doing DES multiple times: 3DES. Here is some more information on 3DES: http://en.wikipedia.org/wiki/3DES and http://kingkong.me.berkeley.edu/~kenneth/courses/s ims250/des.html

Re:Premise is nonsense

[Pope]

OT: Good fucking christ. All I see is a mush of lower-case letters, strung together with no sense of structure. I'd like to beat idiots who write like that with a tire iron until they get the point that *other* people who do not share their idiocy have to read their messages. Gah.

Re:Premise is nonsense

[ComputerSlicer23]

Sorry, I didn't take the time to format it like it was in the e-mail archive. It had slightly more sturcture there. (I probably should have used "ecode" or "pre" tags). Although, it looks like I only missed one paragraph break now that I go back and check it. It was more readable as an e-mail then mine was.

I'm not taking credit for the lowercase letters however.

She seems like a really nice and smart person. She co-wrote what I've heard is one of the Best UNIX administration books ever. So use a foam tire iron or something... *grin*.

Kirby

Re:Premise is nonsense

[patchvonbraun]

Indeed, solving the discrete log problem for a field of order 2**127 would have been considered "big news" in the mid 1980s, which is apparently when this attack against *Diffie-Hellman* was announced. The fact that the keys derived from the D-H exchange were then used to key DES is irrelevant to the cracking DES problem. In the mid 1980s, brute-forcing DES itself was considered a very hard problem (which translates to very expensive), but Evi sidestepped the issue by breaking the underlying D-H based key exchange, using a brute-force technique based on the discrete log problem. Today, we know more about how big the field needs to be for good security (modulii for D-H on the order of 1500-2000 bits, with exponents roughly twice as large as the keys that are to be derived from the exchange). AES is known to be resistant to attack based on the the symmetric-cipher attack techniques that were in existence at the time that AES was designed. That doesn't mean that new techniques won't come to light tommorow, or next year, or next century. With asymmetric schemes like D-H for key exchange, and RSA/DSA for signatures and public-key encryption, there's more mathematical "theory" behind their design. The strength of D-H, for example, is based purely on the still-difficult discrete logarithm problem. While RSA is based on the difficulty of the factoring problem for very large prime composites. Symmetric ciphers like AES are generally "ad-hoc", from a mathematical perspective. They can only be shown to be secure against known attacks, and they can be shown to have several properties that are known to be necessary (but not necessarily sufficient). It's entirely possible that next week, a 12yo will invent a devastating new attack technique against Fiestel or SPN ciphers. Then we'd all be up against a very smelly wall. Similarly, quantum computing could advance to the point that ciphers based on highly structured problems, like discrete logarithm or factorying, could fall. Having both quantum computing, and our purported 12yo cryptanalyst tear the crypto universe assunder at the same time would be bad...

Re:Premise is nonsense

[scovetta]

I'm trying to track down the paper, but not having much luck. It looks like you're going to be looking for a paper:

Mullin, R., Nemeth, E. and Weidenhofer, N., "Will Public Key Crypto Systems Live up to Their Expectations? HEP Implementation of the Discrete Log Codebreaker", Proc. of the 1984 Intl Conf on Parallel Processing, Aug. 21-24, 1984, pp. 193-196.


This information from Evi Nemeth's bio page. Evi appears to have an e-mail address (on the same page)--you could try contacting her directly.

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.

Re:Premise is nonsense

[Anonymous Coward]

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

I'm not sure about the above premise.

crypt(), the unix implementation of password mangling (in my opinion, encryption) essentially takes an 8 character input password - it truncates the password if it exceeds 8 characters in length. Thats 8 x 8 = 64 bits input. Lets assume we're using a single salt, since all that salts do is expand the possible encrypted-password space.

The output of crypt() is 11 bytes long. Each byte is an index into a 64 character array {"A-Za-z0-9./"} ignoring the braces and quotes. Thats 11 x 6 bits (2 power 6 = 64) = 66 bits. 2 bits of these aren't used - check the crypt() specs or Solar Designer's John the Ripper docs for corroboration of that. So thats 64 bits that we have here. So we essentially have a function thats taking 64 bits to 64 bits. Of course, that doesn't automatically make it a non lossy function (if it were lossy, it would have to fall into the hash function category, since there would be collisions for sure).

Now crypt essentially uses a series of applications of DES, using the 64 bit input password as the key to encrypt a blank plaintext. There is *no* reason OR need for crypt to become lossy! Hash functions are used because of the necessity to reduce something large to a manageable hash - and large effort is put into minimizing collisions/making them difficult to create in the first place.

I don't see where the creators of crypt() would have wanted to make it lossy when they could have just made it a like a block cipher as described by Schneier - a 64 bit permutation.

Any enlightenment? Or does what I say make sense?

Re:Premise is nonsense

[AlephNot]

"Any code is crackable if you have enough time to generate every single possible key."

That's not quite true. In the case of a one-time pad (OTP), properly-encrypted plaintext will remain hidden forever as long as certain requirements are met (the pad is never used twice, the media containing the pad is not physically captured by the enemy, the pad was sufficiently random to begin with, etc.).

Now, I know some lamer is going to come up and say, "That's not true! Given enough time, SOMEONE will eventually come up with the pad!" But therein lies the beauty of OTP: Every possible pad has an equal likelihood of being used, and every pad yields different plaintext when reverse-applied to the cyphertext.

Let's say you do find the right pad to decrypt something encrypted with OTP. How do you know it's the right pad? How do you know it's not some other pad yielding an equally plausible plaintext? You don't--as long as you don't have physical access to the pad's media, as long as the pad was random enough, etc.

Obligatory OTP Wikipedia link here.

Re:Premise is nonsense

[Paul Crowley]

DES is also broken in that sense, with linear cryptanalysis and the improved Davies attack.

Re:Premise is nonsense

[Paul Crowley]

OK. Promise you'll familiarize yourself with this work in more detail before citing it again? The first demonstrated break against DES was (IIRC) Mitsuru Matsui's linear cryptanalyis in 1993.

Re:Premise is nonsense

[hcdejong]

Only if the 'plaintext' is not something that can be checked with a dictionary.

If the plaintext really is plain text, IIRC the probability of a random key producing a plausible plaintext decreases with the length of the message. If the message is long enough (a few hundred characters), there's only one key that'll yield a plausible plaintext. I'd have to check the source (Simon Singh, 'The code book') though.

Re:Premise is nonsense

[hcdejong]

Huh. Disregard parent, my brain was out for lunch.

Re:Premise is nonsense

[psamuels]

Only if the 'plaintext' is not something that can be checked with a dictionary.

You still don't understand OTP. Every possible plaintext of the same length is equally likely. Every possible plaintext, from "Pick up the bomb Tuesday at the safe house outside Tokyo" to "Mission compromised, abort and meet Charles in Edinburgh". There is literally no way to tell which of the zillions of grammatically and contextually valid messages of that length is correct.

And if you pad the message randomly with a bit of whitespace, the attacker gets only a vague upper bound on the length. Oh and you can also do traffic analysis based on the existence and timing of the transmission itself. (That is, you can surmise that there was a message worth sending, of approximately this length, between these parties, at this time.)

If the plaintext really is plain text, IIRC the probability of a random key producing a plausible plaintext decreases with the length of the message.

Actually the ratio of key length to message length. The whole point of OTP is that the message is exactly as short as the key -- or, as one usually thinks of it, the key is exactly as long as the message.

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

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:AES Far from Secure

[Anonymous Coward]

Rubber hose cryptanalysis can get you the key and/or passphrase to any encryption system, even a one time pad, in minutes to hours depending on how resistant the person is to physical persuasion.

Re:AES Far from Secure

[duffbeer703]

Think about the typical document in an office. You have letterheads, standard formats, etc that make it possible to deduce some of the content of encyrpted text.

why your apps need to be ready for change

[xxxJonBoyxxx]

"why your apps need to be ready for change"

Hmmm...I didn't see that part, just another Crypto 101 thing with a pitch for some harware gizmo at the end. Is there another article that should be linked in?

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

[crimethinker]

Holy factual errors, Batman!

In addition to the errors you rightly point out, TFA repeatedly mischaracterizes the machine the EFF built to crack DES. In the sidebar, the author refers to an "accelerator card used in a standard PC." Later on in the article, he refers to the system as using FPGA's to crack DES in 3 hours. The EFF's machine, described in their very good book, was comprised of several racks of custom-built boards with ASIC's, not FPGA's, controlled by one PC. Though that PC was certainly "a standard PC," the accelerator cardS were not "in" the PC.

The author makes it sound like you can plug a single card into a PCI slot and break DES in 3 hours. Even though that isn't true, I still wouldn't trust my data to DES anyway, but the point is to be precise and correct in a widely-published article, and this author was neither. And this from the company that proposed Lucifer, the precursor to DES. Shame.

-paul

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

[Anonymous Coward]

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

They told you that you will trust what when you took the job? Presumably the key that they gave you, right? So how does PKI solve the key distribution problem where PGP's web of trust does not? You do realise that people can sign each other's keys with PGP as well, don't you? The exact scenario you gave works fine with PGP too.

I was under the impression PGP's web of trust is a type of PKI (Public Key Infrastructure) anyway. So how can one be better than the other?

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.

Re:Author appears ignorant about cryptography

[Martin Blank]

PKI in an effective trust architecture is much harder to do. Sure, you can create your own structure for free using OpenSSL, but why should I trust you? More importantly, why should I trust your brother's uncle's cousin's son's former roommate's key, which has a trust relationship all the way back through that chain with you?

Compare this with the trust architecture built with assistance from a VeriSign or an Entrust. They have a known trust level based on established practices which filter down through their customers, who are required to pass audits to continue the trust relationships. Maintaining this architecture costs money, and they pass it on (I mean they really pass it on) to their customers, but the customers get the benefit of having that trust relationship not only for their own use, but for the use of their customers, who can if they so choose see that the key is ultimately traceable back to this trusted entity. (Note that I'm referring more to larger-scale organizations here, and not so much to the low-level things that require little or no identity verification.)

Re:Author appears ignorant about cryptography

[cryptoguy]

> Actually, reading on, it looks like the author
> really doesn't have a clue.

Indeed. He says:

> This Diffie-Hellman key exchange protocol is
> used, for example, by RSA and PGP.

RSA and DH key exchange are two different animals. The formulas involved have a certain similarity but the principles are different. RSA is an asymmetric encryption scheme based on the hard problem of factoring, and provides authentication. DH key exchange is a "key exchange" protocol based on the hard problem of discrete logs, and is non-authenticating (meaning it is vulnerable to a man in the middle attack).

Also, the article states:
> By the late 1990s, security researchers had been
> able to break the 56-bit DES algorithms in as
> little as three hours.

But the 1998 break by EFF in combination with distributed.net took over 23 hours. Details, details... see

http://www.distributed.net/des/

This article is an embarrasment to IBM. They have people who know better!

Re:Author appears ignorant about cryptography

[pclminion]

PKI in an effective trust architecture is much harder to do. Sure, you can create your own structure for free using OpenSSL, but why should I trust you? More importantly, why should I trust your brother's uncle's cousin's son's former roommate's key, which has a trust relationship all the way back through that chain with you?

That wasn't at all the sort of model I was suggesting. Imagine a group of family and friends who want to securely email each other. They select one individual, probably the most responsible and technically savvy among them, to be the TA. This TA then hands out certificates to the members of the group. Do it in person if you're paranoid.

I'm not talking about letting just anybody sign anybody else's certificate.

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:Is /. getting astroturfed again?

[Anonymous Coward]

you have a good point. the article itself seems upfront enough -- it cheerfully announces its focus in the title ("the right processor can help with encryption"). but the blurb submitted to the slashdot editors leaves a bit to be desired.

Break down

[cmdrTacyo]

Let me break it down for ya'll
From RSA to USA I'm ready to ball
No matter how complex encryption might fail
No matter if it's created at MIT, Harvard or Yale
So it's only temporary encryption
Uncrackable crap is only fiction
Cause security is only a vixen

New CD /. Pimp in stores soon

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.

Re:HA!

[Anonymous Coward]

ROFL.. good one thanks you made my day

Re:HA!

[maxwell demon]

he obviously didn't do too much testing. Otherwise he would not have missed the great compression rates of the following code:

#! /bin/sh
rm -f $1 $1.compressed
touch $1.compressed

Try it, the compressed files are all of size 0!
And even better: If you replace -f by -rf, you even can compress whole directories in one go!

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!

Re:Lal!!

[MrHanky]

Ah, nothing encrypts like a bottle of fine single malt whisky.

Re:Lal!!

[Kyojin]

    Ah, nothing encrypts like a bottle of fine single malt whisky.

What, like this?

b cpuumf pg gjof tjohmf nbmu xijtlz.

--

main(i){putchar((unsigned long long)0xA44D81BB9F22B423>>(i-1)*5&31|!!(i&lt;13)<<6 )&&main(++i);}
With thanks to David for the original idea. I've lost your Slashdot UID, sorry.

Re:Lal!!

[MrHanky]

znagh5" And thatgfer juewst bweegtr. Whiseknea prwidv betger!

Re:Lal!!

[myowntrueself]

"Ah, nothing encrypts like a bottle of fine single malt whisky."

And nothing decrypts like hookers and weed in an underground carpark.

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

Re:What happened to IDEA encryption method?

[freqmod]

Idea is not much used because it is patented, (see the stance of e.g. Gnu privacy guard ).

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:IDEA is patented

[RouterSlayer]

so as I thought, it's still unbroken.

I still like it, even with the patent nonsense.

although I truly believe nothing is really unbreakable, in a sense. i mean, even quantum cryptography, key stealing and brute-force are still there.

social engineering, getting access to the source or destination, keyboard loggers, spyware. there are many other ways.

mind-boggling encryption with unbreakable properties, with stupid human frailties like everything else.

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

[Surt]

OTP and (modern) algorithmic encryption are actually pretty close in quality: the weakest known point for both is transmission of the key (that is in both cases, a well funded attacker will find it easier to steal your key than to break your encryption).

It might be that that could change for algorithmic though.

But on the other hand, OTP is typically so much more vulnerable to key stealing that you might really be better off using algorithmic.

There's also quantum encryption for unbreakable secure transfer of information.

It all depends on who you are, how much data you have, your transmission methods and profiles, the funding and types of your opponents. No one choice of encryption suits every user or situation, and in fact those factors have a clear impact on the effectiveness of the various options.

Re:Anything other than OTP is weak encryption

[UnknowingFool]

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

Properly used that is true. The Russians used this system during the cold war. Unfortunately, every now and then, a cryptographer would re-use a pad even though procedures dictated never to do so. It wasn't until after Russian spies in the US government reported this to the KGB did they enforce the procedures. It goes to show that sometimes the weakest link involves the humans.

Re:Anything other than OTP is weak encryption

[Anonymous Coward]

There are other 'holes' in OTP and that is how the pad is constructed. Ideally the pad is constructed in a completely random manner. Like drawing cards from a shuffled deck, or balls from an urn (with eyes tight shut). But its possible that non random factors can creep in making the pad (from one-time to next-time) correlate. This can eventually allow it to be broken.

Re:Anything other than OTP is weak encryption

[pclminion]

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 problem with OTP, is that if you need to encrypt a gig of data, you need a gig of key bytes. A human cannot remember a gig of key bytes, so it must be stored on some media somewhere. So now, the key has a physical existence and can be stolen.

OTP is more secure in a theoretical sense but has many practical problems.

Re:Anything other than OTP is weak encryption

[Anonymous Coward]

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

Or to intercept the transmission of the key. OTP is not unbreakable without a secure (e.g. quantum) key exchange scheme. It's not practical in either case.
Quit mainlining wikipedia. It blurs the lines between "encryption algorithm" "encryption scheme" and "key exchange method".

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.

Re:Anything other than OTP is weak encryption

[Maximum Prophet]

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?

You distribute the key chained to a courier's arm. If the courier shows up at the end site missing an arm, you've just lost some random data, and you resend the key. If, on the other hand, you just try to send the data, you've lost the data. (and an arm)

Re:Anything other than OTP is weak encryption

[grikdog]

Actually, there are any number of ways of jumping into the far distant future output of any PNG -- Mersenne Twister is especially amenable to this, since it can be initialized with a very large internal table -- then simply use 256-bit AES in counter mode. The result is "weak" encryption only in the sense that the universe may not actually expire through proton decay before a single such message is cracked. It is certainly comparable to OTP in real universes.

Re:Anything other than OTP is weak encryption

[blair1q]

That was VENONA.

They were using the same pad (literally a pad with key grids printed on each sheet, one sheet to be used per message) on Naval and Merchant vessels, presuming that nobody'd notice.

We got hold of a nearly complete version of the pad from a Merchant vessel and spent several decades cross-checking intercepted Naval traffic against it. It may have been a bigger deal than breaking the Japanese PURPLE code or stealing the ENIGMA.

Re:Anything other than OTP is weak encryption

[blair1q]

What in "physically access the encryption or decryption pads" is different from "intercept the transmission of the key"?

Wikipedia's smarter than you.

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

[Stauf]

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

Consider though; there's nothing obscure about a guard with a gun standing by a door, and most people would agree that that door is pretty secure. Imagine if behind that door was a key to unlock a vault someplace that contained a whole lot of money - the fact that the key shape is 'obscure' is secondary to the fact that to discover the key shape you're likely to risk being shot at.

My understanding was that the Navajo code talkers were all assigned a handler whos sole job was to keep them out of enemy hands. The Japanese, for example, knew how to break the code - just catch one of these code talkers and make them talk. The code worked because of the overt security measures in place to keep them from being captured.

I wouldn't call the code itself the security - any similar system would have worked in the place of the Navajo language - the fact that the method of breaking the code was tightly controlled by men with guns made it work.

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

[dereference]

I almost hope this was a troll, rather than a sadly misinformed opinion. I think maybe I understand what you were trying to say, but I still feel compelled to answer a few (mis-)leading questions.

Why should I have to register with Verisign to send an encrypted email to my girlfriend, co-workers etc.

You don't. The third-party CA is not at all a requirement for encrypting and signing your email.

Why can't I just click a button and generate a random 128 bit key set and use PGP?

You can, although I think the minimum key length might be 1024 bits.

why can I send a MIME encoded attachement anywhere, but not a PGP encoded plain text email?

You can. See Enigmail for example. Anybody with PGP and a key can receive, verify, and decrypt, even if they don't happen to use Enigmail on their end.

I think (and hope) your point was that this isn't built-in and/or integrated into every email client by default, which is absolutely true. But I'd suggest you download GPG and install Enigmail as a plugin to Mozilla or Thunderbird, and actually see that there is a point-and-click solution. You literally click a little key icon in the message as you compose to encrypt, or a pen icon to sign. You can even encrypt and/or sign everything by default.

Re:All this shows is

[pclminion]

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?

What, pray tell, is wrong with the S/MIME standard? Nobody says your certificate has to be signed by Verisign. Jeez, set up your own Trusted Authority for you own group of friends and contacts, and self-sign your certificates.

Who the hell would use PGP...

Re:All this shows is

[Requiem Aristos]

PGP Freeware has been widely available for years. You can also use GnuPG, in many ways a defacto replacement. (There do exist GUI front-ends for it, even in Windows.)

Verisign deals in x.509 certs, not PGP keys. You can generate your own if you like, but it's much more awkward. Personally, I dislike x.509 certs, not so much because of the technology (it's fundamentally not much different from PGP) but because every implementation I've seen is a pain to work with (e.g. doesn't let you change email addresses). Zimmerman has nothing to do with Verisign.

So, yes, we have the technology, it's freely available, and some of us are using it.

Re:All this shows is

[Tony Hoyle]

The third-party CA is not at all a requirement for encrypting and signing your email.

Except if you don't have a common CA, you can't verify that the message you received is actually the one that was sent.. it's trivial to fake a key without verification.

Even PGP has a CA of sorts (the public key repositories).

Re:All this shows is

[dereference]

Except if you don't have a common CA, you can't verify that the message you received is actually the one that was sent.. it's trivial to fake a key without verification.

Well, a common third-party CA does certainly make this easier, but it's not that you can't do it otherwise. You can always take it upon yourself to verify the key, or at least the key figerprint, via some out-of-band communications method (usually telephone). You could also establish your own web of trust, by trusting your own arbitrary set of third party agents to establish the links between the keys and their owners. Note that the CA does nothing more than sign the public key anyway; lack of such a signature does not necessarily imply the key is invalid.

Even PGP has a CA of sorts (the public key repositories).

Not really; the CA is a specific third-party authentication service that certifies a link between a key and its owner. The repositories are just places where you can publish your public key for easy distribution; this actually doesn't help solve the problem of unverified keys at all.

Re:All this shows is

[RAMMS EIN]

Alright, don't take this as an insult, but your post is very uninformed. I don't know what's wrong with mods these days that they modded it up so high, whereas more deserving posts have been modded flamebait and offtopic.

Anyway, you had one good point:

``how useless popular comms software is.''

I fully agree with you there. PGP has existed for a loooong time. Spam filters have existed for a long time, too. Both can easily be used with mutt. I also believe the Mozilla mail client does a good job here. How long is it going to take mainstream mail clients to catch on?

As for the rest of your points:

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

The idea of registering with some authority is that the authority can check the identity of those who register. Users of the service place their trust in Verisign, and thus trust that other users are who they say they are when their identity has been verified by Verisign.

Of course, many people actually don't trust Verisign, much less want to pay money to them for a service they don't perform well. Therefore, people have come up with alternatives. GnuPG uses a trust network, where you verify your friends' identities, they verify their friends', etc. Hopefully, this verifies the identity of anybody who ever contacts you. And you don't have to pay anybody for it.

The way this works is pretty much exactly how you describe: you generate a key (make it a bit larger than 128 bits though!) and start using PGP. The whole identity verification is optional; you can sign and encrypt communication just fine without it. The only thing is that people will have no way to verify that the key you used actually is yours; it could have been a malicious user generating a key with your name and email address.

``why can I send a MIME encoded attachement anywhere, but not a PGP encoded plain text email?''

You're seriously confusing the terminology here. MIME-encoding is a standard used by mail clients, so that they can understand each other and decode the messages they send each other, with attachments and all that. There is no such thing as "PGP encoded"; PGP can be used for generating signatures (some tag that only be created with your private key, but anyone with your public key can verify), or to encrypt data (encode it in a way that everyone with the recipient's public key can do, but only someone with the recipient's private key can decrypt). The former assures that the message really comes from you, the latter ensures that only the intended recipient can read it.

Re:All this shows is

[peterzen]

Problem is, security always adds some complexity to things (which means it's harder to use). In the PGP case, even if in quite a lot of email clients there are 'Sign' and 'Encrypt' buttons, authentication and encryption add complexity. Exchanging public keys, managing how you trust them and how you roll them over when they expire is not something my mother would want to do, she's happy to have memorized her credit card PIN code. Then there's the obligatory (secure) passphrase prompt popping up every time she sends an email. And what about the heart of all this; keeping her secret keys secret after the first secret key stealing worm gets released in the wild?

It's not the tools in general that are too complicated (some are indeed though), it's doing 'good' security itself.

It's probably not Zimmerman being greedy (you've got gnupg anyway).

Re:All this shows is

[el_womble]

I'm sorry to pick on your reply, but it seemed to be the one the aggravated me the most.

I understand the point of a trusted third party. What I also understand is that, as you proved to yourself, you just don't need one. As long as you generated the keys yourself, for a large enough key space, the chances of anyone having, or calculating your key pair approaches 0. This is about the same as someone intercepting the transmission of my private key to a trusted third party, but much, much lower than the chance of some black hat breaking into the single point of failure that is a trusted third party.

If at any point I suspect that a nefarious third party has intercepted my emails, asking my girlfriend if she's fed the cat, or if she'll please TiVo Smallville for me, I simply generate a new key set, and tell my contacts. I'll take my chances. PGP does exactly what it says on the tin.

As for the MIME encoded attachment, I'm confusing nothing. The processes are very, very similar.And yes, I understand, that the application is greatly different, but the point was this: we can agree on a standard to encode attachments, why can't we agree on a standard for encryption?

If M$ had wanted to balls up email they could have decided to use they're own algorythm to do attachements. Why can't they centre on an encryption technology that is free and open source, just like MIME? It makes my inner conspiracy theorists blood boil, but the truth is probably that Verisign saw an opportunity to get into bed with Microsoft. They took it, and took free, easy email encryption with them.

It can't be that nobody else thinks it as important as attachements. Every company I've spoken to has, at some point, asked how they can encrypt their emails. What do I tell them? Yes, you can buy a key pair from verisign, but that will mean that only a selected number of your clients can actually read that email, or they have to buy Outlook and a versign key pair. Yes, you can encrypt your email, but you have to abandon the training and money you have invested in Outlook... oh and btw, the replacement won't have half the functionality, and won't work - but it will be free, and it doesn't work with Outlook! Or do I say: No. We've got the technology, but for some unknown reason, we just don't use it, even though it could massively reduce the need for spam filters, virus checkers and provides at the very least, a small amount of authentication. Its a sad situation to be in, don't you think?

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?

Re:All this shows is

[el_womble]

I'm aware that there are tools, but my post was about popular tools. If I send any kind of encrypted mail to friends / family / coworkers they are not going to read it, because the run Mail.app, Outlook, Thunderbird. Even then, its not that these applications don't offer encryption services, its that they either involve handing over a cheque to Verisign, or the other clients can't read it.

I tried out one of the free certificates from one of the trusted companies. What it proved is that even the paid for solutions are rubbish. Its not that the system isn't secure, its that its unusable.It is complicated to get the certificate. Its easy to install the certifcate, but you then get all your friends and relatives asking you to resend the message because there is a "whole lotta garbage" at the bottom of it (public key).

GPG is all fine and good, but with a LGPL Microsoft, Apple, Sun et al will implement it when hell freezes over. If it was BSD, they'd just claim they invented it and be done with it. Which is a real shame.

Why can't encrypted email be as easy as SSH?

Re:All this shows is

[RAMMS EIN]

Ok, maybe I misjudged your post and you understand very well, but that's not the impression I get.

``I understand the point of a trusted third party. What I also understand is that, as you proved to yourself, you just don't need one. As long as you generated the keys yourself, for a large enough key space, the chances of anyone having, or calculating your key pair approaches 0.''

The issue is not whether someone can or can't generate a key pair identical to yours. The issue is that when you receive a message from a person unknown to you, can you trust that that person is who he claims to be? If his key is signed by a party you trust, you can. This is the service that Verisign provides, and, indirectly, what GnuPG's network of trust provides.

``As for the MIME encoded attachment, I'm confusing nothing. The processes are very, very similar.''

Which process? You mean that PGP encryption is similar to quoted-printable? In the sense that both of them process the whole content and apply some transformations to it, you're right.

``the point was this: we can agree on a standard to encode attachments, why can't we agree on a standard for encryption?''

A quick search yielded at least two RFCs related to PGP (1991 and 2440). Also, I've seen PGP in a few mail clients, but never anything else. So it seems to me that PGP is both an RFC and a de-facto standard. That puts it in the same league as pretty much all the Internet protocols...seems pretty standardized to me. That few people implement it is another issue; apparently, there is not enough demand.

``Every company I've spoken to has, at some point, asked how they can encrypt their emails. What do I tell them?''

Is it really that bad? Are you really telling me that there is no way to get PGP on Windows without paying to Verisign? What about Mozilla Thunderbird?

I'll go out on a limb and say that I think the problem is not that it's difficult for you to get the capability to send PGP encrypted emails, but rather that the receiver won't be able to read them, without getting PGP capability, too. However, it can be assumed that both sides benefit from the encryption of the email, so I don't see why it should be hard to convince them to get PGP-capabilities.

If, indeed, the problem is being locked into software that won't support PGP, surely the messages can be encrypted and decrypted with a separate program. I'm sure such programs are available, having written them myself. GnuPG can also be used to this end, although it may not have a WIMP interface available.

Re:All this shows is

[GenSolo]

I've found that it's trivial to mail a CD containing a public key with a handwritten note signed with my physical signature. In the few cases where I wouldn't consider this adequate, I've found hand delivering said CD to be sufficient.

Re:All this shows is

[Anonymous Coward]

Free crypto, ya. It's all about the entitlement. Hey, pick me up a beer tree, too? One with real beer, not dregs or lite beer, eh.

Re:All this shows is

[tricorn]

You also don't need a CA if you're trying to establish an identity - I may not know who you are, but I know you're the same person who sent the previous message. I don't know that you're NOT the same person who sent a different message, so it's easy for you to establish multiple identities. You can disguise yourself much more easily than in real life. A CA attempts to prevent that by linking a certificate to a supposedly one-to-one mapping of "person" to "identity".

Given history and consensus, you can establish a "web of trust" without ever physically meeting anyone, indeed without any contact except through encrypted/signed e-mail. Your reputation is built by your behavior, just as it is in real life.

OpenSSH has problems right now

[Anonymous Coward]

The big problem with OpenSSH right now is that it doesn't protect against brute force password attacks good enough.
To protect against brute force, they tell you to go use a program called "bfd" and that must use a firewall called "APF".
It modifies your firewall on the fly, not a good thing to be doing to a remotely located server.
If you have a server at a colo and it already has a firewall setup, you really don't want to change it *after* you already have customers using your server because it's easy to lock them and you out.
So it's a patch at best.
And how many server owners are really good enough to install a new firewall and this bfd thing?
Installing a new updated version of OpenSSH would be easier. In most cases it's just a simple RPM install.
The OpenSSH people suggest that you force your users to go against human nature and pick better passwords. We all know that doesn't work because the more complicated the password, the more people forget and the more calls you get in the middle of the night.
So do you think the OpenSSH people would be more human related and start using passphrases? NOPE!
There's some real concerns for OpenSSH, it's developers intentions towards *real* security with human nature factored in.
There are a lot of servers using it as their main defense.
So what will make the developers wake up?

Re:OpenSSH has problems right now

[Anonymous Coward]

This is without a doubt on of the most incomprehensible trolls that I have ever seen.

Ignoring the ridiculous sections about modifying the firewall on the fly. OpenSSH has nothing to do with "passphrases" Password length support depends on your system if you accept password authentication and passphrases for public keys aren't related to openssh server, thats handled by the client.

Re:OpenSSH has problems right now

[Anonymous Coward]

OpenSSH is an example of monopoly leveraging. In this case the OpenSSH developers are trying to convince users to switch to their operating system: OpenBSD.

Ofcourse it is a weak monopoly as anyone can fork the OpenSSH code.

Re:OpenSSH has problems right now

[doon]

The big problem with OpenSSH right now is that it doesn't protect against brute force password attacks good enough.

You still use passwords? Any publicly accessible server that I use ssh on doesn't allow password authentication anymore. Kinda hard to brute force a password that way. All of us just use our keys for authentication. Then again I don't have to support tons of users doing this as we don't provide shell accounts any more. I only have to support myself and a set of friends who have accounts.

Re:OpenSSH has problems right now

[Anonymous Coward]

He's probably talking about the typical default Red Hat server setup, which most of these server farm places rent as a Linux server. A lot of people just rent these and use them as is.

Researching a little on the lists it seems like there are a lot of good suggestions such as "exponential backoff" and keeping track of misbehaving IP addresses but no action on the part of developers for a year or more, and no good reasons given to not put them into use (except what seems like lazyness because it looks like more work).

And it looks like the new sshd_config's "MaxStartups" and other like directives won't help with the brute force issue either.

The strange twist is that if you delay a login for a particular user then an attacker could almost lock out that valid user by keeping his retry delay high. So basing it on the users ID is a bad idea, it looks like tracking abusive IPs is a good way to do it, and it should work even with multible connections, so it has to be multi thread compatible which is more complicated work and that's probably why the developers are so against any changes.

Mailing lists for OpenSSH:
http://www.mindrot.org/mailman/listinfo/openssh-un ix-dev
openssh-unix-dev@mindrot.org
http://msgs.securepoint.com/cgi-bin/get/openssh-un ix-dev-previous.html

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:OpenSSH has problems right now

[Anonymous Coward]

Using keys, how do you get into your box the first time?

Not over SSH? If its your box you can login on the console or using a remote console, which would require a password but we can assume that you're using another box on the same lan that you've accessed with a key. If its not yours then have the sysadmin drop your public key in you .ssh for you.

What if your keys get lost on your home computer, or you have a HD crash or fire at home?

Backup. Multiple copies and offsite. A private key isn't that big. See below as well.

What if you are out of town and want to access your system from a friend's computer?

How about bringing your key (locked with a secure passphrase of course) on a USB thumbdrive. If the drive is lost or compromised than you can just stop using that key and remove it from all your authorized_keys

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.

Ah well heres the tradeoff. But if you can't deal with the headache then use allow password on certain insecure systems and then deal with the brute force attempts. Use long secure passwords and set up some iptables rules to block abusive hosts if it really gets to be that much of a problem.

Re:Pet Peeve

[ajs318]

Hell, I wanted to take a Ph.D. just so I wouldn't have to let people know, just from looking at my name, what was between my legs. Unfortunately I made a mess of my B.Eng. Looking back, it wasn't much harm done as it just meant I had less unlearning to do when I started work.

Or how about this quote?

[Beryllium Sphere(tm)]

Whitfield Diffie and Martin Hellman devised a scheme to safely transport a public key with a message, allowing this public key to be paired with a private key and then used to decrypt private data. This Diffie-Hellman key exchange protocol is used, for example, by RSA and PGP.

That's close to being so bad that it's not even wrong.

The linked article is of negative value and you're better off skipping it.

DES at launch

[Beryllium Sphere(tm)]

Not only did academic cryptographers criticize the key length, the US government forbade using DES to protect classified information.

Re:DES at launch

[Detritus]

DES was approved for use in encrypting sensitive, but unclassified, information like personnel records. NSA's policy at the time was that only algorithms designed by the NSA were approved for use in encrypting classified information, and only when implemented in an NSA approved device. Skipjack was the first public algorithm that was approved for protecting (lower level) classified information.

Re:What happened to IDEA encryption method?

[VolciMaster]

Form Bruce Schneier's website, the paper about Blowfish: "Many of the other unbroken algorithms in the literature--Khufu [11,12], REDOC II [2,23, 20], and IDEA [7,8,9]--are protected by patents." From the Wikipedia article, Bruce Schneier is again quoted, "In my opinion, it is the best and most secure block algorithm available to the public at this time." (Applied Cryptography, 2nd ed.) However, by 1999 he was no longer recommending IDEA due to the availability of faster algorithms, some progress in its cryptanalysis, and the issue of patents"

I don't really get the whole idea (no pun intended) of patenting a mathematical algorithm. It would be like patenting the recipe for Oreos. You can trademark it, and copyright it, but patenting it doens't make sense to me. Then again, IANAL.

unbroken != unbreakable

[crimethinker]

so as I thought, it's still unbroken.

Careful with that logic. While it's true that no-one has published a "break" for IDEA, that doesn't prove that such a break doesn't exist, waiting to be discovered. It's quite possible that, with other ciphers being much more popular, cryptanalysis is being focused on the "bigger targets," by both black and white hats.

My copy of Applied Cryptography is in storage right now, so I can't look up the details of IDEA (is it a Feistel network? what size are the S-boxes? how many rounds?) and even if I had that information handy, I'm not a cryptanalyst, so my opinion probably doesn't count for much.

And yes, attacking the human element of crypto is going to be much more likely to succeed in the face of ever-larger keys. Ever hear of "rubber hose cryptanalysis"? (Hint: it's something that the U.S. government wants us to believe is done only by other countries.)

-paul

Re:unbroken != unbreakable

[Jester99]

IDEA was very simple; just a series of shifts and adds (and maybe XORs, I believe), repeated for a bunch of rounds.

No SBoxen or anything 'magic' like that.

Re:unbroken != unbreakable

[Paul Crowley]

No shifts. XOR, 16-bit add, and a special multiply operation mod 2^16 + 1 (where 0 is treated as 2^16). Sadly it's very hard to do the multiply without opening yourself up to timing attacks. It's not a Feistel network; it's a network of its own kind.

Re:Recommended reading for those with an interest.

[Widowwolf]

rereading this for the 5th time right now..still a great damn book! 3 thumbs up!

No algorithm is unbreakable

[Gandul]

All algorithms are crackable; its just a matter of time. And that's the key word, when you use encryption you are just delaying the time that it will take un-authorized people to access the info. The trick is to extend that time long enough that the information has become unusable or useless. It will be cracked but by the time you do, you have invested 100 times more money in resources that the information is worth.

humans are better

[digitalderbs]

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

Re:humans are better

[cheezus_es_lard]

bbecbaubse bbibilbbob bagbbginbs bnebebdsb bab bbobobbjbobb

It is an advert for their co-processors

[Tangurena]

His series of articles are an attempt to sell cryptographic co-processors.

If one were interested in the history of cryptography, one would read The Code Breakers, by David Kahn (very thick book, yet very interesting). Or, if one were interested in how to utilize cryptography into business processes, one would probably have read Secrets and Lies, by Bruce Schneier.

...when you use RSA for encryption, you use it in conjunction with a symmetric encryption algorithm.

One does that only because public-key algorithms are very slow compared to symmetric-key algoritms. Slower by factors like 100 to 1000. PGP uses both: the body of the message is encoded with a symmetric key, randomly generated for that session, and that key is encrypted with the public key of the recipient. If one were to purchase the co-processors his department sells, one could speed up the public-key encryption to where it would be practical for everyday use.

Down the road?

[Anonymous Coward]

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

It may *ALREADY* be full of holes in the NSA's basement. They just keep that to themselves.

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:Simon Singh's Codebook

[grassy_knoll]

I'll second that recomendation. The Code Book is a good read, not only explaining the basics of cryptography but also cryptanalysis.

Very interesting, even to this layman.

Re:Pet Peeve

[ReidMaynard]

the bottom of both, the author "Dr. Sam Siewert"

To respond to the other comments, I guess it's my being raised amongst MD's and the like.

I was not saying they (Phd's) were not Doctors, again "my pet peeve".

PGP history and OpenPGP

[davidwr]

Wikipedia has a good article on PGP including the GNU-licensed implimentations of the OpenPGP standard.

Feel free to edit the article if you have anything to add.

Re:I just encrypt disks full of white noise nowada

[pclminion]

Since the results are going to be random, what's the point? You might as well flip coins to decide who has to drink. Or even simpler, everybody could just drink.

It's like the kids game "Chutes and Ladders." You have no opportunity to do anything that will affect the outcome. You might as well not be playing it.

One Time Pad

[cesarbremer]

The One Time Pad algorithm have a hight administration cost, mainly because the problems related with the random file generation, deployment and the process of destroying the random data.
My company sell a cellular GSM-CSD voice encryption product, and i developed an One Time Pad version for this product.
Currently i see problems using only One Time Pad, and i prefer using OTP with symmetric encryption in our product, creating a two protection layers, because the weakness is with the human being.
The end user wants to use the best security and wants to have a secure phone like a common cellular phone, and i think this can't be done.
The OTP can be used only by people who understand the OTP problems, this technology can't be used by the common people.

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.

Re:I just encrypt disks full of white noise nowada

[johnjaydk]

I think it'd be fun to try to compress white noise files, and see how well it compresses.

This is actually a pretty good measurement of how random your input is. If it's sufficient close to random then you can't compress it at all.

Re:I just encrypt disks full of white noise nowada

[ChairmanMeow]

If it's sufficient close to random then you can't compress it at all.

True. In fact, in some cases, using compression on a random file will increase the size of the file rather than decrease it.

You don't understand, that's not geeky enough (nt)

[Anonymous Coward]

I said n/t

Re:Recommended reading for those with an interest.

[chris macura]

For the record, you're suggesting reading some 3000 pages... ;-)

Re:Pet Peeve

[Anonymous Coward]

There are those that don;t consider MD a "real" doctoral degree. With no dissertation requirement, it's (academicaly) at most equivalent to a Master's ;-)

Re:Recommended reading for those with an interest.

[CdBee]

Slashdot by its nature attracts literate, intelligent people - yes, the 4 books together represent a lot of reading but equally, a tremendous reward locked in paper and yours to take for yourself and pass on.

nagravision 2

[jownz]

Forget about DES, MD5, Blowfish, and all those 'old' crypto techniques. People need to start focusing on what really matters... getting me free satellite TV! :)
 
  jownz

Re:Recommended reading for those with an interest.

[Widowwolf]

well I will tell you one thing..this set of books is well worth it! I have read the whole set 4 times, working on my 5th..and still am amazed in how well stephenson writes..(insert captn crunch reference, or the playboy phreaking story here for everyone who has read the book)

Re:I just encrypt disks full of white noise nowada

[Just Some Guy]

dd if=/dev/urandom of=./noise.txt bs=1 count=1

Drink.

TIMEFMT='%E'; time /home > /tmp/du.out

Adjust to suit if using an older shell. You're welcome.

Re:CMDRTACO SHOWED ME HIS O FACE LAST NIGHT

[Anonymous Coward]

Mr. arothstein, nice to have you back sir! Your classic Goatse trolls are always a treat.

It is also worth noting...

[jd]

...NIST seems to be currently doing a lot of work on encryption modes (how the blocks are linked together). A lot of current modes (ECB, for example) are weak and make it easy to extract some information from encrypted files.

(At least, they were in the middle of doing studies on modes the last time I looked, and I've not heard anything on new mode standards since.)

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.

I'm fond of Rabin

[Paul Crowley]

The thing that should really kill RSA is that it has no advantages whatsoever over Rabin besides being slightly simpler, and it has several important disadvantages, particularly the absence of a provable relationship with factoring.

Re:I'm fond of Rabin

[Mocenigo]

The thing that should really kill RSA is that it has no advantages whatsoever over Rabin besides being slightly simpler, and it has several important disadvantages, particularly the absence of a provable relationship with factoring.

There's also a bit more investment in RSA, there are more fielded products with RSA built-in, and most importantly of all, the patents expired. Did not check the patent situation on Rabin.

I also prefer Rabin over RSA, but both suffer from the same problem: the subexponentiality of solving algorithms.

There are other techiques, ECC is not that complicated, and also codes are not that difficult to implement. I am fond of HECC because it is the main object of my research in crypto at the moment.

But people still stick to technologies that are similar to the old, known ones. For example, just to stick to the discrete logarithm in finite fields, now egregious colleagues are researching algebraic tori a lot. Still, they will suffer from the same problem as RSA or Rabin or the DL in prime fields: subexponentiality of solving the underlying problem will lead to key explosion sooner or later with respect to ECC.

On the other hand Arjen Lenstra made a good analysis that the field element compression techniques will provide a good method for the next few decades. Of course, until there are no new breakthroughs in breaking such schemes (and it seems more likely that people will make a bigger advancement in this area than in the algebraic curve setting).

Let us not forget that ine of the aspects that keeps RSA afloat is the usage of short public exponents. These guarantee that RSA encryption can be done in time quadratic in the key size, whereas ECC and other methods are cubic (RSA decryption is cubic time). You might like this or not, but this is not that bad, even though, as you mentioned, why use an asymmetric system to encipher a large amount of data? You just use it to agree on a key (or to encrypt it) for symmetric method.

Roberto

Re:I'm fond of Rabin

[Paul Crowley]

There are no outstanding patents against Rabin, I believe. I imagine that fielded RSA hardware could probably also use Rabin. Of course many standards don't support Rabin, but that's a different question.

ECC is probably appropriate in a lot more circumstances than it is used, but I can see reasons why one might choose to use Rabin instead - if one needs the PK operation to be very fast (eg signature verification, see Bernstein's trick for insanely fast Rabin signature verification) or if you are more confident of the hardness of integer factorization than of the EC-DH problem. In other words, both have their advantages and disadvantages and there's reasons to choose either. (Note that I'm characterizing a huge range of possibilities under the one term "ECC" here).

However, there is absolutely no inherent reason why one would choose RSA over Rabin, and those who do so when they have a choice (ie when the choice is not dictated by standards or suchlike) thereby demonstrate their ignorance of cryptography.

You have no reason to believe that

[Paul Crowley]

You seem very sure of that for someone who doesn't know what they're talking about.

We have every reason to believe, for example, that factoring large semiprimes is hard. If it is, then the Blum-Blum-Shub RNG is strong. In which case, if you use BBS to encrypt your message with a sufficiently large key, it won't be broken. Not with being "clued to the nature of the algorithm". Not with "knowledge of a secret constant" (where on Earth did you get that notion from?). It might simply be the case that the algorithm that breaks BBS in reasonable time does not exist.

Contrariwise, P might even be equal to NP. We don't know - these are all big, unsolved problems in computer science and cryptography. But we have no reason to believe that every encryption algorithm has a corresponding cryptanalysis algorithm, and to blithely assert that it does just shows your ignorance.

OTPs may be perfect in theory, but in practice, for ordinary users, they are one of the least secure forms of encryption. You are trusting your security to the security of the channel through which you move your key material, and I don't think that channel is ever going to be as strong as (say) 256-bit AES. Of course, if you're setting up the red telephone between Washington and Moscow, you can use *both* a strong cipher *and* a one-time-pad.

Re:You have no reason to believe that

[blair1q]

You sound pretty sure that I don't know what I'm talking about, then prove you don't understand what you're talking about.

"Hard" and "strong" are relative terms, not absolute ones, for a reason. There's something harder and stronger.

Further, prime-factorization keys still need to be transmitted by some channel.

Their security is therefore less than or equal to OTP's.

And since BBS is based on the mathematics of factoring primes, which so far has been shown to be doable, and in every instance someone called that prime "unbreakable", it is less secure than OTP.

Saying "we have no reason to believe" something proves you're willing to rest on the assumption that its opposite is true.

That's how every now-denigrated encryption scheme stuck around long enough to be broken, costing more than it would have cost to just use OTP from the beginning.

But thanks for the laugh. Now put your ego back in its box and get back to studying. Some day you'll actually be as smart as you t

Re:You have no reason to believe that

[blair1q]

You sound pretty sure that I don't know what I'm talking about, then prove you don't understand what you're talking about.

"Hard" and "strong" are relative terms, not absolute ones, for a reason. There's something harder and stronger.

Further, prime-factorization keys still need to be transmitted by some channel.

Their security is therefore less than or equal to OTP's.

And since BBS is based on the mathematics of factoring primes, which so far has been shown to be doable, and in every instance someone called that prime "unbreakable", it is less secure than OTP.

Saying "we have no reason to believe" something proves you're willing to rest on the assumption that its opposite is true.

That's how every now-denigrated encryption scheme stuck around long enough to be broken, costing more than it would have cost to just use OTP from the beginning.

But thanks for the laugh. Now put your ego back in its box and get back to studying. Some day you'll actually be as smart as you think you are.

(I wish /. was a little smarter and didn't chop the ends off of messages and then make you go through flood-prevention hoops just to post a correction...)

Re:You have no reason to believe that

[Paul Crowley]

You might be interested to look at the crypto content on my website.

http://www.ciphergoth.org/crypto/

Your picture of the history of crypto is a little weird. I recommend Steven Levy's "Crypto" for a clearer idea. Sadly he doesn't cover the AES process, but it's a fun read all the same. If you decide you want to understand the topic in more depth, "Handbook of Applied Cryptography" is a good direction to go next. Wikipedia's cover of crypto is sadly quite patchy; I've tried to address it in places, and clear up egregious errors, but it's a big job.

Also, factoring primes is pretty straightforward. It's the composite numbers that give us the trouble.

IDEA has weak keys

[0ptix]

AFAIR there is a problem with weak keys with IDEA. i.e. there is a subset in the keyspace for which the algorithm is alot weaker then it should be.

Re:IDEA has weak keys

[Paul Crowley]

The space of weak keys is so small that the chances of picking one at random are minuscule; it's not really a big problem. On the other hand, no weak keys are known for AES and many other well-studied ciphers, so IDEA can no longer claim to be in the front rank of security.

Re:I just encrypt disks full of white noise nowada

[Anonymous Coward]

It's like the kids game "Chutes and Ladders." You have no opportunity to do anything that will affect the outcome. You might as well not be playing it.

You could say that about a lot of things. But playing games like Candyland, Chutes and Ladders, or other random-based games is more about the journey (a.k.a. having fun with friends) then it is about the end result of who wins.

Frankly lad... you've got some emotional issues if your worldview on a game like Chutes and Ladders is such that you think "you might as well not be playing it".

Re:Pet Peeve

[ReidMaynard]

Thank you for the civil response.

Since I'm not an MD and never claimed to be I don't know what to make of the rest of your post.

Re:Pet Peeve

[ReidMaynard]

After a little web research I discover you are in the right. Aparently original doctors were teachers, of a religous-legal nature and were considered doctors after they passed examinations.

Snake oil (sort of)

[Ernesto Alvarez]

I've been looking at the site linked from the parent post, and it's worth noting that it's not secure, because they provide the pads.

The problem with this approach is that you do not know how they are generated (you do not know if they keep copies, or sell the same pad to someone else). Even if they are honest, you should never import random pads from an unknown party.

Even assuming they are not doing anything wrong with them, these pads have to be transmitted and could be intercepted. Once intercepted and copied, the game is over. Even if they were encrypted, an attacker just has to crack the encryption used for transporting the key, copy it and your message's compromised (sure, cracking RSA-2048 or AES-256 is a lot of work, but it's less than uncrackeable, you could have just used AES in your message).

If you lease a RNG, then it might be secure (implementation matters), but in that case just pipe the random bits into a XOR and save on software costs.

The page also contains too much technobabble (probably just market drone speak, but better safe than sorry).

I thought this might be obvious, but I'd better mention that it's not safe to use fourmilab's hotbits for the same reason, it you want a secure pad, you should build (or buy and check) your own hotbits (or other good) generator.

They should just model it after males...

[unlabeledchick]

Males are impossible to understand... Why don't they just say what they think? I don't think I can stand them anymore...