drevil at sidereal.kz
Wed Aug 29 23:30:01 CEST 2001
> > all your users. You don't. I could list a dozen reasons why, in some
> > cases, DES might be a better choice than AES, for instance. Can you
> > think of some?
> There are no technical reasons. If there is a organization which has
> a need for weak encryption, they should write their own or stripp
> GnuPG down to that.
No one can argue that DES is as secure as AES, but I can think of some
great technical reasons for sometimes using DES in a cryptosystem.
Here's my list:
1. An organization has a large installed base of hardware which has
hardware support for DES encryption, and performance is more
important than security for their needs, so they need to take
advantage of the DES hardware.
2. An organization needs to interoperate with existing systems which
can't be upgraded or modified. As an example, there is a
classified military installation on the moon, which communicates
with a base on the Earth by an encrypted link. It was installed in
the 70s, and the cryptosystem it uses has been broken by amateur
radio guys. Cost to upgrade the cryptosystem which has been
deployed: $1bil, perhaps. So the right thing to do is to stick
with the weak cryptosystem (it's something weaker than DES).
3. A researcher is doing performance comparisons among different
crypto algorithms, and wants to include DES as a reference point.
So far, those are all technical reasons. Now for some non-technical
4. A company is operating in a country or regulatory environment where
DES is mandated by law or by contract for some reason. For
instance, financial regulations require banks to use DES in some
5. A company wants to protect secrets from casual snooping or
subpoenas, but wants to be able to read its employees' email if it
really really needs to.
6. An author wants to protect his work, but wants to make sure he has
a back door in case he loses or forgets his key.
7. A company is protecting data which have only a very short duration
of usefulness (maybe stock market trading orders) and they always
have used DES, and it's still good enough for this use.
8. A company wants to sell it in a product, and they want a long
feature list, such as "includes DES support", even if no one will
9. The value being protected is small, and the rest of the system is
fairly weak, so DES wouldn't be the weakest link. Example: an
on-line chat system where people are exchanging low-value
10. A government wants to buy a lot of crypto tools, but doesn't want
to deploy things which it can't break if it needs to.
11. Archives from the 70s are stored in DES format, and it's not worth
converting them, but they need to be readable.
12. A new cryptoanalysis method is discovered, and DES is more secure
than the alternatives given this attack method (I know, highly
So I've listed a dozen reasons, of which three of them are technical,
why a crypto product might want to support a weaker cryptoalg. In
your mind, you have defined GPG to be "something which people use to
encrypt email in a particular way", and you built-in all kinds of
constraints based on this. This is unfortunate because it could be
defined as "an open implementation of a hybrid cryptosystem and
authentication system", which is very broadly applicable, to email and
many other things, just like SSL is being used to secure websites,
database connections, telnet sessions and everything else.
Actually, I personally use DES for a high security application just
about every day. It's built in to a hardware system which I have to
use: the Cryptocard (www.cryptocard.com). If I were designing this
system myself, I would use AES, but right now I have two choices:
1. Use conventional passwords to access the system.
2. Use one-time passwords generated with DES.
Even though DES is a weak cryptosystem, Option 2 is vastly more secure
than Option 1, in the overall system, and it's secure enough for the
value I'm protecting.
> > ones such as AES and 3DES, low security ones such as DES, very low
> > security ones such as 40 bit DES, and even plaintext (ie, no
> I agree with the FreeS/WAN project that we don't want any weak
> encryption - there are no technical reasons for it (except for some
> very strange protocols). We try to do the best we can.
The choice of algorithm and security levels depends on a whole set of
factors which designers of general-purpose stuff can't possibly know
> > configure my Apache/SSL server to support only 40-bit DES or no
> > encryption at all if I want to. I'm glad to have the choice. The
> And so is the GCHQ
And in some countries (like the US for instance), whatever is the
local equivalent of the GCHQ has enough power to mandate their wishes,
and so the options are: use no crypto, use weak crypto, or go to jail.
Weak crypto may be the best of those three choices.
> > that use. That's what Phil Z was originally thinking of, too. But
> > public key crypto, such as GPG, can and should be used all over the
> > place, for a very broad range of applications. It's unfortunate that
> Just choose the right tool. The GNU project has other tools which
> might better fit for a purpose: Kerberos,LSH, GNUTLS, LIBGCRYPT.
I just want one which will speak OpenPGP format. I have a bunch of
amazing uses for this format, but I need a library unfortunately.
> > resulted in software with needless constraints, and it has resulted in
> > the protocol being used much less than it could be.
> Come on, PGP is still the de-facto standard for email encryption.
That's my point, and unfortunately, when people think PGP, they think
"email encryption". There's no reason for it not to be used for a
hundred other things, but everyone is thinking, "yeah, but it's going
to be used for email!"
More information about the Gnupg-devel