Re: deriving multiple keys from one passphrase

2007-02-05 Thread Leichter, Jerry
| Hey, quick question.
| 
| If one wants to have multiple keys, but for ease-of-use considerations
| want to only have the user enter one, is there a preferred way to
| derive multiple keys that, while not independent, are computationally
| independent?
| 
| I was thinking of hashing the passphrase with a unique string for each
| one; is this sufficient?  If sufficient, is a cryptographically strong
| hash necessary?
The property you presumably want is that knowing n generated keys gives
you no information about the n+1'st generated key.  The usual way
that's proposed to do this is to take the master secret, concatenate
some identifying data - say k encoded in 32 bits for the k'th secret -
and run the result though a cryptographic one-way function.  This
*seems* like it ought to work - you can't invert the function, etc.,
etc. - but even if the one-way function has all the usual properties,
it's not clear they really give you the property you need.  (In fact,
the arguments have the flavor of older arguments that you can easily
construct a keyed checksum from a hash by just prepending, or
appending, secret keying material.  In fact, you need to use something
more clever, like HMAC.   Using HMAC here looks like a good try, but
it's no clear that it does the trick either.)

Of course, there is a primitive that does have the right property,
namely an encryption function.  Suppose we took k and decrypted it
with the secret master key.  Any good encryption function will
certainly have, as part of its assumed properties, that seeing the
decryption of n blocks gives you no information about the decryption
of any other block (at least as long as n is small compared to the
2^(block size), which it certainly will be).
 
| I got a clarification about the use CRCs to process passphrase idea
| someone mentioned.  The salient bit is that he was using several CRCs
| (not sure if it's random or carefully chosen), and each one is run on
| the passphrase, and the output of all of them concatenated to
| initialize a PRNG seed.  The passphrase and seed are both secret, so
| according to him there's no need to use a cryptographically strong
| hash, and CRCs have a well-understood mathematical basis.
|
| I presume this would be insufficient for deriving independent keys,
| but perhaps there is a way to do that with careful selection of the
| CRC polys?
He's perhaps relying Rabin's fingerprinting using random polynomials
results.  What it basically says is that, even though it's easy to
attack a CRC any *known* polynomial, if I choose a polynomial *at
random* and keep it secret, your chance of modifying something I
checksum with that CRC and getting away with it is essentially just
1 in 2^n (for an n-bit checksum).  Of course, I have to keep both
the polynomial and the checksum secret; and there is some math involved
to pick a primitive polynomial randomly.

However, coupling all this with seeding a PRNG makes it highly likely
that he's cross the line from obviously no vulnerabilities to no
obvious vulnerabilities.
-- Jerry

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


deriving multiple keys from one passphrase

2007-02-03 Thread Travis H.
Hey, quick question.

If one wants to have multiple keys, but for ease-of-use considerations
want to only have the user enter one, is there a preferred way to
derive multiple keys that, while not independent, are computationally
independent?

I was thinking of hashing the passphrase with a unique string for each
one; is this sufficient?  If sufficient, is a cryptographically strong
hash necessary?

I got a clarification about the use CRCs to process passphrase idea
someone mentioned.  The salient bit is that he was using several CRCs
(not sure if it's random or carefully chosen), and each one is run on
the passphrase, and the output of all of them concatenated to
initialize a PRNG seed.  The passphrase and seed are both secret, so
according to him there's no need to use a cryptographically strong
hash, and CRCs have a well-understood mathematical basis.

I presume this would be insufficient for deriving independent keys,
but perhaps there is a way to do that with careful selection of the
CRC polys?

-- 
The driving force behind innovation is sublimation.
-- URL:http://www.subspacefield.org/~travis/
For a good time on my UBE blacklist, email [EMAIL PROTECTED]


pgpgxzMEc4EYQ.pgp
Description: PGP signature


Re: deriving multiple keys from one passphrase

2006-10-13 Thread Thomas
Am Dienstag 10 Oktober 2006 01:35 schrieb Travis H.:
 What is the accepted way to derive several keys from a user-supplied input?

Maybe RFC289.

AFAIK it also describes the reason why it protects against dictionary attacks.

Bye,
Thomas

-- 
Tom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF

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


Re: deriving multiple keys from one passphrase

2006-10-13 Thread Thomas
Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.:
 On 10/13/06, Thomas [EMAIL PROTECTED] wrote:
  Maybe RFC289.
 
 I assume you mean 2289, which appears to describe the OTP scheme used by 
 S/key.

sorry, it was too early for an copy-n-paste ;)

i meant: 
   
 B. Kaliski; PKCS #5: Password-Based Cryptography Specification Version 2.0;
 RFC289


Bye,
Thomas

-- 
Tom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF

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


Re: deriving multiple keys from one passphrase

2006-10-13 Thread Thomas
Am Freitag 13 Oktober 2006 12:26 schrieb Thomas:
 Am Freitag 13 Oktober 2006 12:05 schrieb Travis H.:
  On 10/13/06, Thomas [EMAIL PROTECTED] wrote:
   Maybe RFC289.
  
  I assume you mean 2289, which appears to describe the OTP scheme used by 
  S/key.
 
 sorry, it was too early for an copy-n-paste ;)
 
 i meant: 

  B. Kaliski; PKCS #5: Password-Based Cryptography Specification Version 2.0;
  RFC289

hm, the last 8 is missing again. rfc2898

t.



-- 
Tom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF

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


deriving multiple keys from one passphrase

2006-10-10 Thread Travis H.

What is the accepted way to derive several keys from a user-supplied input?

Or, can you see anything wrong by prepending a counter to the passphrase
and hashing it to create derived keys?

k_n = hash(n || passphrase)

I suppose a faster system would involve using hash(passphrase) as the
key and encrypting a counter (assuming that hashes are slower than
block ciphers).

k_n = E(hash(passphrase), n)

Both seem vulnerable to dictionary attacks, and it's not immediately clear
to me how I could prevent them, or if that's even possible.

Terry Ritter suggested using CRCs over the passphrase, but I haven't really
analyzed that method at all.

Any opinions?
--
Enhance your calm, fellow citizen; it's just ones and zeroes.
Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

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