Ahhhh, I know what the misunderstanding is now - I think this came up sometime last year on bugtraq, and I posted a similar reply.
I'll summarise: The pre-shared key one enters has nothing at all to do with the encryption keys actually used by 3DES. In any case, a 32 byte hex key is 256 bits, which is plenty strong enough. I don't consider truncating a 48 byte key to 32 bytes to be a security issue. I suspect that the option to manually enter the pre-shared key is to stop the Netscreen from passing it through a 128 or 160 bit hash before it is used (for those who don't trust, or think they can do better than the hash function). Detail inline. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf Of > [EMAIL PROTECTED] > Sent: Saturday, January 12, 2002 6:19 AM > To: [EMAIL PROTECTED] > Subject: RE: Netscreen 5xp 3Des Keys > > > I believe what the NetScreens do is, by this definition, pre-shared > keying. > The extra wrinkle here is that NetScreen allows you to enter the > key in hexadecimal, or enter a "password" from which it will generate > the necessary key. (It is easier to transmit such a password over > the phone, or memorize it, than to try to duplicate the hexadecimal > value at a remote location. The "pre-shared key" we're talking about here is actually used as part of the authentication process in IKE. The pre-shared key that is selected here is only a tiny part of the actual keying material which is eventually used to provide keys for the selected encryption algorithm (3DES In the case we're talking about). IN THEORY, no matter how weak the "pre-shared key" is, it will NOT affect the integrity of the keying material used for the final encryption algorithm - the 3DES keys will be just as strong if you choose "foo" as if you choose "9D6E6F4C3A4E7C8B0099E84F4E4C4A4". [1] So why use a strong pre-shared key? It's to prevent password guessing attacks against the authentication process itself. In most wide-scale implementations that use pre-shared key, the system will accept any IP address as long as they provide the correct key (this is actually an implementation compromise, but most people make it without thinking). That means that, on an IPSec level, all an attacker needs to do is guess that key. If you enter a key in Hex which is, say, 32 bytes (256 bits) which was derived from a true-random source it will not be guessed. I promise. Let's say that an acceptable level of entropy (randomness) is 112 bits (same as 3DES). For typeable passwords, I guess that means about 30 random characters, but would be impossible to achieve with memorable passwords. In other words, if you're using 3DES then your authentication process is a weak link, and you should consider something stronger (the authentication strength should EXCEED the cipher strength, because it's used more often than any individual cipher key). If you enter "foo" then I believe that the Netscreen will pass it through a hashing algorithm, which is likely to produce at least 128 bits of pretty-much random output. This adds no security, since "foo" will always hash to the same value - someone who guesses "foo" will have your "pre-shared key". As an aside for IPSec VPN archtitects, my recommendation is that 3DES be accompanied by DH group 2, and preferably SHA as the hash algorithm. If DES is strong enough, then use MD5 and group 1 to increase speed. I strongly suggest that implementations that need 3DES use strong authentication - NOT pre-shared keys. Laptop users are a different problem, and it's probably too in-depth to be germaine here. > The password->key generation feature will generate different sizes > of key, depending on the encryption method selected. The poster is > finding that it is generating only 2/3 the key length that he expects > for the selected encryption, 3DES-CBC. > I don't have a NetScreen manual handy, but I suspect that this is > one of the 3DES flavours that re-uses one of the keys, so although > there are three steps, only two keys are used. (Giving an effective > strength of 112 bits instead of 168). 3DES always has an effective strength of 112 bits, since it's vulnerable to a meet-in-the-middle attack. The 3DES that is used in IPSec is "EDE-3" which means that the plaintext is encrypted, decrypted, then encrypted again, with a different key at each step. In terms of re-using keys, this is from the RFC (2451): "For DES-EDE3, there is no known need to reject weak or complementation keys. Any weakness is obviated by the use of multiple keys. However, if the first two or last two independent 64-bit keys are equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the same as DES. Implementers MUST reject keys that exhibit this property." Personally, I don't like the idea of k1 == k3 either, but it all gets complicated, whereas it's quite clear that the two cases mentioned simply reduce to DES. Two-key triple encryption is well discussed in "Applied Cryptography" (Schneier). > I've held off answering, in hopes that someone with a manual or > other hard information would speak up.... > > Dave Gillett [...] Anyone who has a burning curiosity about the guts of IPSec should probably bookmark: http://www.ietf.org/html.charters/ipsec-charter.html In particular, the RFC on IKE will provide lots of background to most of the stuff I'm discussing here. Cheers! [1] This may not be true. If it could be shown that the hashing algorithm used to create the keying material was flawed, it could be shown that a less-random pre-shared key infinitesimally reduces the strength of the final symmetric keys. Since the pre-shared key gets mixed in with other stuff and also gets hashed _twice_, I don't let it concern me. Then again, I'm not a real cryptographer. -- Ben Nagy Network Security Specialist Mb: +61 414 411 520 PGP Key ID: 0x1A86E304 _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
