-----BEGIN PGP SIGNED MESSAGE-----
[ To: Perry's Crypto List, Arnold Reinhold ## Date:05/28/99 ##
Subject: Re: ICSA certifies weak crypto as secure ]
>Date: Fri, 28 May 1999 11:42:03 -0400
>From: "Arnold G. Reinhold" <[EMAIL PROTECTED]>
>Subject: Re: ICSA certifies weak crypto as secure
>At 1:36 PM -0400 5/27/99, Kawika Daguio wrote:
>>What I would like to know from you is whether you and others
>>have been able to construct a "duh" list of typical, but
>>unacceptable current practices that can easily be
>>remediated.
>Here are my top 10 candidates for a "duh" list:
[ Some good stuff deleted.]
>2. Poor quality random number generation. Random quantities
>are needed at many places in the operation of a modern
>cryptographic security system. If the source of randomness
>is weak, the entire system can be compromised.
Yes. One problem with this is that its really very hard to
test. Do they have a hardware random number generator?
Will they show you the specs, and let you have it
independently evaluated? (Do you have the money to do
this?) Are they using a software PRNG? What are their
entropy sources? How do they perform in worst case
situations (e.g., machine fresh out of the box with the same
configuration as thousands of other machines, no user input,
etc.)?
>3. Use of short passwords or weak passphrases to protect
>private keys or, worse, using them to generate symmetric
>keys. Bad passphrase advice abounds. For example, both
>Netscape and Microsoft advise using short passwords to
>protect private keys stored by their browsers. The simple
>fix is to use randomly generated passphrases of sufficient
>length. See http://www.hayom.com/diceware.html.
Right. There are three additional things to look for:
a. Make the passphrase hash expensive. There are lots of
ways to do this. Users shouldn't mind a half-second delay
for hashing their passphrase, but this will make dictionary
attacks much harder to mount.
b. Use a unique per-passphrase salt of at least 32 bits.
c. For some communications applications, you can use EKE
or SPEKE to use a passphrase without exposing it to
dictionary attack.
>4. Re-use of the same key with a stream cipher. I have seen
>this done many times with RC4. Even Microsoft appears to
>have gotten this wrong with their VPN (I do not know if it
>has been fixed). There are simple techniques to avoid this
>problem but they are often ignored. See
>http://ciphersaber.gurus.com for one method. The potential
>for slipping up in stream cipher implimentation makes a
>strong case for using modern block ciphers wherever
>possible.
There are a bunch of related things to worry about. Here
are some quick rules:
a. Stream ciphers must have a different key for each
different encryption they do.
b. Block ciphers should have a different key for each
encryption they do. If they don't have a different key,
they must have a different IV for each encryption.
c. Block ciphers must be used in a chaining mode. For most
applications, they ought to be used in either CBC- or
CFB-mode. (OFB- and counter-modes just turn the block
cipher into a stream cipher.) Bulk data encryption should
never use ECB-mode.
d. Encrypting data doesn't guarantee its integrity. If
it's important that encrypted data not be altered, then you
have to use a MAC or signature of some kind. This is
especially important for stream ciphers like RC4, but it's a
big deal all around.
e. In exportable systems, you have to use the salt
correctly. If you just use a 40-bit key, you end up
vulnerable to various kinds of precomputation attack.
f. In exportable systems, you have to separate the keys
used for data integrity from the keys used for data
encryption. The encryption keys have to be weakened, but
the integrity keys (for MACs or signatures) need to be kept
at full strength.
g. If your system encrypts cryptographic keys, it is
crucial that you protect those keys' integrity as well as
their privacy.
There is a bunch of other stuff.
[ Other good stuff deleted. ]
>Arnold Reinhold
- --John Kelsey, Counterpane Systems, [EMAIL PROTECTED]
NEW PGP print = 5D91 6F57 2646 83F9 6D7F 9C87 886D 88AF
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>
iQCVAwUBN07hByZv+/Ry/LrBAQHaAgP/fL06VgvBQB5+2aUKNiC921bJ8kiBreND
ohL9hrMk2dOwSMekLuP+9czKexYbr04TiKgR+3IEVewcKy+KdmM9qRh2mXdlXTD3
i/1A5BZFQmBMGebGqd7BWhc9GcljFqnV96tLa1SMmLkbPG7O3gn8rpYZh+c56wjH
x2JV+r6S2CU=
=734R
-----END PGP SIGNATURE-----
