Salt is always public: for example, in non-shadowed /etc/passwd files, the
first two characters (if crypt() is used) of the password field represent
the salt. Of course Eve and Mallory can try to guess, but salting makes it
impossible to speed up the cracking using large tables of precomputed values
(such as dbm files indexed by encrypted passphrase).
Enzo
----- Original Message -----
From: "Ray Dillinger" <[EMAIL PROTECTED]>
To: "Enzo Michelangeli" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, December 11, 2000 10:44 AM
Subject: Re: migration paradigm (was: Is PGP broken?)
>
>
> On Mon, 11 Dec 2000, Enzo Michelangeli wrote:
>
> >--Ray Dillinger wrote:
> >
> >> There are times and places where you can use salt, and times and places
> >> where you can't. In order to use salt with a passphrase, you have to
> >> store it somewhere. And that means that a person who has only the
> >> ciphertext and the passphrase cannot decrypt. If you use salt, then
> >> the ciphertext can be decrypted only in an environment where that
> >> particular salt is available. That makes it nearly useless for
> >> networks or backups.
> >
> >Yes, but we were discussing about ways of getting rid of the secret
keyring,
> >not the public one. The salt can (and should) be stored with the public
key.
> >If the decrypting agent in your scenario has to keep something stored, it
> >will be easier to operate safely with a piece of public data than with a
> >secret one.
>
> Scuse me, but this doesn't help. If the salt is stored with the
> public keyring, then it is public, n'est-ce-pas? To make it otherwise
> would require either treating the public key as secret, thus eliminating
> the advantages of public-key cryptography, or handling public keys and
> secret salt completely differently even though stored in the same place,
> which would be a key management nightmare.
>
> Therefore, Eve and Mallory can be assumed to be in posession of the
> salt and they're right back to being able to guess passphrases. No
> security has been gained, only obfuscation.
>
> Bear
>
>
