| 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
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
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
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
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
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
