Re: password strengthening: salt vs. IVs

2007-11-01 Thread silky
On Oct 30, 2007 6:24 AM,  [EMAIL PROTECTED] wrote:
 So back in the bad old days when hashing was DES encryption of the
 zero vector with a fixed key, someone came up with salt as a password
 strengthening mechanism.

 I'm not quite sure why it was called salt.

 It perturbed the S-boxes in DES IIRC, but essentially it was a known
 bit of text that was an input to the algorithm that varied between
 entries, like an IV does with encryption.

 If there isn't already a term for this, I'm going to call this
 general concept individuation, or possibly uniquification.

 Nowadays with strong hash algorithms, but rainbow tables and
 low-entropy passwords as the threat, I'm wondering what the best
 practice is.

 I was thinking of simply prepending a block of text to each passphrase
 prior to hashing, and storing it with the hash - similar to salts in
 passwd entries.

well what you're describing is quite classically a salt, imho.


 It should have at least as much entropy as the hash output, maybe a
 little more in case there's collisions.  If it were uniformly random,
 you could simply XOR it with the passphrase prior to hashing and save
 yourself some cycles, right?

well no. i mean to xor it (or probably what you mean: to otp it)
you'll need to have a salt who's length is equal to the input. that
would then mean that short inputs would result in short salts. i.e. a
password of a may result in the salt of x. hash(a ^ x) is
hardly secure against a rainbow table.

so you're better off maintaining the salt in a separate location
(after all, the threat model is that someone takes the db and has a
list of all the hashes, and then calculates out the passwords) and
still prepend it on before the main passphase.

you may consider, however, that if this salt is as long as one block
of the input to the hash algorithm, it effectively becomes a new iv.
but what that has to do with anything; i don't know ...


 Would it be appropriate to call this salt, an IV, or some new term?

 --
 Life would be so much easier if it was open-source.
 URL:http://www.subspacefield.org/~travis/ Eff the ineffable!
 For a good time on my UBE blacklist, email [EMAIL PROTECTED]


-- 
mike
http://lets.coozi.com.au/

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Hushmail in U.S. v. Tyler Stumbo

2007-11-01 Thread Jon Callas


On Nov 1, 2007, at 10:49 AM, John Levine wrote:


Since email between hushmail accounts is generally PGPed.  (That is
the point, right?)


Hushmail is actually kind of a scam.  In its normal configuration,
it's in effect just webmail with an HTTPS connection and a long
password.  It will generate and verify PGP signatures and encryption
for mail it sends and receives, but they generate and maintain their
users' PGP keys.

There's a Java applet that's supposed to do end to end encryption, but
since it's with the same key that Hushmail knows, what's the point?



I'm sorry, but that's a slur. Hushmail is not a scam. They do a very  
good job of explaining what they do, what they cannot do, and against  
which threats they protect. You may quibble all you want with its  
*effectiveness* but they are not a scam. A scam is being dishonest.


You also mischaracterize the Hushmail system. The classic Hushmail  
does not generate the keys, and while it holds them, they're  
encrypted. The secrets Hushmail holds are as secure as the end user's  
operational security.


I know what you're going to say next. People pick bad passphrases,  
etc. Yes, you're right. That is not being a scam.


They have another system that is more web-service oriented, and they  
explain it on their web site far better than I could. It has further  
limitations in security but with increased usability. It is also not  
a scam.


Jon

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]