Re: deriving multiple keys from one passphrase
| 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
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. -><- 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
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]
Re: deriving multiple keys from one passphrase
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
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]
deriving multiple keys from one passphrase
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]
