GnuPG Celebrates 10 Years

Posted Dec 28, 2007 0:24 UTC (Fri) by jd (guest, #26381)
Parent article: GnuPG Celebrates 10 Years

GnuPG is a fine piece of software. My main criticism is not of GnuPG itself but rather the lack of software that makes use of it transparently or semi-transparently. (You won't see secure e-mail, for example, until it is practical to send and receive secure e-mail from the majority of e-mail clients.)

My second criticism only marginally impacts GnuPG and really applies to all cryptographic software. The number of algorithms supported is often a tiny fraction of the number of algorithms out there, and for secret-key encryption, the number of encryption modes supported is a miniscule fraction of the number that exist.

Yes, there are going to be people who point out that many of the algorithms and modes have not undergone anything like the level of peer review as those in common use. To that, I would point out that those have been reviewed precisely because they are in common use, not the other way around.

There are also those who would argue that the increased choice would be more confusing than helpful. Perhaps, but the criteria used to select the AES algorithm was a mix of speed and security. With e-mail, speed is hardly a critical factor and therefore the balance used by NIST might not be appropriate for such cases.

For encryption modes, again, the balance has been speed vs. security, but the needs of e-mail are not general-purpose needs. I can see more people being interested in Authenticated Encryption Modes than in something that is merely fast. For sending images, I imagine that highly specialized encryption modes, such as 2DEM, that are designed to mangle information still extractable even from an encrypted image would again be highly appealing.

Finally, a few rotton tomatos at the users, at corporations and at lawmakers. The value of a technology increases both with use and with standing. Digital signatures and authenticated modes, if suitably strong, should be required on electronic documents wherever a regular signature would be required or expected on a paper document. (To me, this would include all official electronic documents.) Notary services should be able to "stamp" electronic documents produced in their presence by means of a very strong digital signature, giving it equal status to any paper document that had been notarized. (Although arguably it would be far harder to tamper with the electronic document.)

Official corporate e-mails would be included in "official electronic documents", in this. How often have we seen e-mails dragged into court, only for there to be arguments over whether they're genuine, complete, or some other such nonsense? Backups of all e-mails only get you so far, if you can't be sure if what is presented is what was stored, or that what was stored was what was written. It would also make it impossible to land up in debates over whether an e-mail was in an official capacity or not. An official signature means an official e-mail. No official signature means it can't be enforced as corporate policy.

GnuPG Celebrates 10 Years

Posted Dec 28, 2007 9:21 UTC (Fri) by bvdm (guest, #42755) [Link] (7 responses)

The decision to select Rijndael as the AES was certainly not based on a "mix" of criteria
between speed and security. The only consideration was complete resistance to all known
methods of cryptanalysis for the full 128-bit claimed strength. It was only amongst the final
round of peer reviewed candidates that speed was considered an advantage for final selection.

Any break in AES would represent an unprecedented advance in cryptanalytical theory. Given
that one wouldn't know what other ciphers would be susceptible to the new analytical attack,
there is really no point in not using AES. Given that 128 bits represents an unimaginably big
number, any break will probably not result in a practical loss of security.

Designing secure ciphers is a solved problem for the time being. It is much easier to crack
your box or for someone to break your knees than to break AES.

GnuPG Celebrates 10 Years

Posted Dec 28, 2007 17:03 UTC (Fri) by flewellyn (subscriber, #5047) [Link] (6 responses)

I'm sorry, I can't agree that cryptography is a solved problem, except in the purely theoretical sense: sure, we have a mathematically-proven unbreakable cipher, the One-Time Pad, but it's so hard to deploy and use correctly that its applications are extremely limited in the real world.

So in all truth, it's likely that at some point in the future, AES will be cracked. Mind you, I have no idea how; if I knew that, I would be either the world's greatest cryptanalyst or the world's greatest psychic. But given the history of cryptography and cryptanalysis, I feel confident enough in saying that one day, somehow, AES will be broken.

GnuPG Celebrates 10 Years

Posted Dec 28, 2007 20:32 UTC (Fri) by jd (guest, #26381) [Link] (1 responses)

Block cyphers use various methods of data mangling that produces a result that crudely approximates a totally random signal. The better the block cypher, the better the approximation. However, it isn't perfect and can never be perfect - even in theory. The encryption mode helps to improve the pseudo-randomness, but that too can never be perfect.

When (not if) a weakness is found in AES, it is pretty much guaranteed to be a weakness in the nature of the approximation. The 2DEM crowd demonstrated nicely in their initial paper how you could recover some information from encrypted images where there is a poor choice of encryption mode. I have no idea how much is recoverable, how much you can scrape the message for exposed data. Any information, though, must effectively reduce your key search space, with the obvious implication that sufficient information must reduce it to something you can search on a realistic timeframe.

2DEM mode

Posted Dec 29, 2007 5:51 UTC (Sat) by zooko (guest, #2589) [Link]

I just went and had a look at the 2DEM docs that they submitted to NIST.

As far as I could tell from a quick reading of the first couple of sections of their paper, they pointed out that ECB is very weak at confidentiality, and that CBC isn't parallelizable, and then proposed 2DEM mode. These two facts (ECB doesn't offer good confidentiality and CBC isn't parallelizable) were already well understood by other cryptographers. All of modes of operation described in SP 800-38 A (except of course ECB, which shouldn't have been included) offer good confidentiality, and CTR mode offers excellent parallelism. Some of the newfangled modes like OCB and GCM are also parallelizable.

So as far as I can tell, 2DEM mode doesn't offer anything over CTR mode.

Regards,

Zooko

GnuPG Celebrates 10 Years

Posted Dec 29, 2007 16:35 UTC (Sat) by Nelson (subscriber, #21712) [Link] (3 responses)

DES has never been "cracked." AES is at least as strong as DES, it has withstood all of the known attacks against DES.

It's hard to imagine it having a weakness that reduces its strength to something practical to process but I guess it's possible. You have to also understand that the ciphers that have been developed by actual cryptographers in the last 10 or so years that have been "cracked" the crack is almost never actually possible to do, it's just calculatably more efficient than brute force. It usually takes an intractable amount of processing power or storage to perform these "cracks" and the actual crack. Being paranoid, once a cipher has shown one of these weaknesses, it's usually abandoned and considered untrusted. I can't think of a legitimate cipher that has been developed in a long time that could actually be cracked in any practical manner, maybe FEAL or REDOC but those are pretty old.

GnuPG Celebrates 10 Years

Posted Dec 30, 2007 9:12 UTC (Sun) by flewellyn (subscriber, #5047) [Link] (2 responses)

DES has never been "cracked."

As a matter of fact, yes, it has.

You have to also understand that the ciphers that have been developed by actual cryptographers in the last 10 or so years that have been "cracked" the crack is almost never actually possible to do, it's just calculatably more efficient than brute force. It usually takes an intractable amount of processing power or storage to perform these "cracks" and the actual crack.

GnuPG Celebrates 10 Years

Posted Dec 30, 2007 17:13 UTC (Sun) by dmaxwell (guest, #14010) [Link]

See the above link. 22 hours using a distributed network is not infeasible. And this was in 1999, almost 9 years ago! Computers are much more powerful now, and massive parallel clusters are much more widespread. It's conceivable today that DES could be broken in a matter of hours.

The OP is correct. DES has not been cracked in a cryptoanalytic sense. It has been brute forced because trying every key in a 56 bit keyspace is now practical. Any true crack to a cypher algorithm reduces the keyspace enough to make a brute force search practical. DES is simply weak in the keyspace dept. The math behind it is good.

GnuPG Celebrates 10 Years

Posted Dec 30, 2007 19:30 UTC (Sun) by Nelson (subscriber, #21712) [Link]

Brute force isn't a "crack."

Do the math on AES then, if that's the best way to "crack" it then AES potentially be secure for centuries. And then there is EDE "Triple-AES" if we actually need something better.

GnuPG Celebrates 10 Years

Posted Dec 28, 2007 18:41 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Official corporate e-mails would be included in "official electronic documents", in this. How often have we seen e-mails dragged into court, only for there to be arguments over whether they're genuine, complete, or some other such nonsense? Backups of all e-mails only get you so far, if you can't be sure if what is presented is what was stored, or that what was stored was what was written. It would also make it impossible to land up in debates over whether an e-mail was in an official capacity or not. An official signature means an official e-mail. No official signature means it can't be enforced as corporate policy.

Here are some reasons why some companies don't necessarily agree with your assessment.

That would seem to open up the company to all sorts of potential liability with very little benefit. Retaining email for long periods of time can open up your organization to legal fishing expeditions where your IT and legal team spends its time answering subpoenas and going through old backup tapes rather than their actual work. This can be especially onerous for an organization like an ISP which is storing and processing data on behalf of third parties, you might end up in the middle of a lawsuit that doesn't even involve you.

One of the answers to this problem is aggressive data deletion policies, as soon as the data isn't needed purge it. It's easy to respond to discovery requests when you can show that you don't have the data in question any more. It is also more secure in that if your system is compromised the attackers can't make off with customer data you don't have anymore.

The other issue is that signing documents can have other implications, especially if you make any claims to non-repudiation. Any offhand comment by an employee to a customer can become legally binding in some locations. Non-repudiation claims are especially a problem because someone could install a trojan on a workstation or simply leave their computer unlocked and unattended allowing others to sign or encrypt messages as them. Poor private key management is also standard practice at most organizations. Problems such as this can be time consuming and expensive to clear up and are just liability for the company.

In the specific case of PGP style key management escrow is an issue. In the common use case every user generates their own private key which is not necessarily shared with the company officers. If an employee moves on to another job, the company may lose access to any emails and documents they've received or encrypted for themselves. Of course this risk exists in any event, any person can install GPG and digitally shred their system and the risk can be migrated if the GPG deployment is thought through and managed properly but there are additional risks in jumping into proper forethought of these and other issues.

I hope I'm not too much of a killjoy but I wanted to provide some counterbalancing information as to why this can be difficult or perceived to be difficult at some companies. These are concerns that I've heard when proposing a similar email encryption deployment.