Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

scrypt takes a salt, and a password plus some cost paramters to generate a key. So say we define it as this:

key = scrypt(password, salt, cost)

I am interested in using it for generating passwords deterministically. E.g. to create a password for amazon or apple I would so something like:

amazonpassword = base64(scrypt("username" + "masterpassword", "amazon", cost))
applepassword  = base64(scrypt("username" + "masterpassword", "apple", cost))

So I wonder if this is suspectable to a length extenson attack. E.g. if an attack found out what:

scrypt("masterpassword", "amazon", cost)

is, could they then use that as a basis for guessing what:

scrypt("username" + "masterpassword", "amazon", cost)

is? If so what is the best approach for avoiding this problem? Should I use a HMAC to generate the masterpassword string?

share|improve this question
    
I think scrypt inherits the zero padding length extension from PBKDF2. scrypt(s, salt) == scrypt(s + \0, salt) for short enough s shorter than 64 bytes. –  CodesInChaos May 16 at 16:51

1 Answer 1

up vote 2 down vote accepted

No, scrypt in not vulnerable to password extension attacks.

Internally, scrypt passes the password to PBKDF2, which uses it as a key for the HMAC function -- hence they've effectively already done the workaround you thought of.

share|improve this answer
    
I assume the hmac in question is doing: hmac(masterpassword, salt). But my case is that masterpassword consists of multiple parts. I want to achieve something like hmac(part1, hmac(part2, hmac(part3, salt))). I don't see how scrypt could be doing this since it doesn't know the parts making up my master password. –  Adam Smith May 16 at 15:11
    
@AdamSmith: if you trust scrypt, then that iterated HMAC is unnecessary; all you need is a collision-free mapping between the parts to the password you actually give scrypt (and concatenation can obviously be collision-free); scrypt's of two different passwords are independent, even given a known relationship between the two passwords. Now, if you don't trust scrypt, you can obviously do the iterated HMAC's as you said -- however, if you didn't trust scrypt, why are you using it? –  poncho May 16 at 15:32
    
I trust scrypt works with correct usage. I am just trying to make sure I understand how it is supposed to be used correctly. So if I understand you correctly if an attacker doesn't know "foobar" but knows its scrypt hash, then he has not advantage in finding "foobar1", "foobar2" etc. That is just as hard as finding the hash for "spamandeggs" e.g. But with MD5 hashing they could guess the hash of "foobar1" if they knew the hash of "foobar". Right? –  Adam Smith May 16 at 16:19
1  
@AdamSmith: actually, with MD5, they couldn't guess the value of MD5("foobar1") given MD5("foobar"). Now, given MD5("foobar"), there is a specific extension that looks something like MD5("foobar\x80\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\‌​0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\6\0\0\0\0\0\0\0More stuff here") (where the "More stuff here" part can be chosen by the attacker arbitrarily) which can be computed as a function of MD5("foobar") -- it counts as a "length extension" attack, however it's not likely to be the sort of thing one would pick as a password normally. –  poncho May 16 at 16:27
    
Okay, I didn't quite understand that. But I at least understand that length extension attacks do not work how I imagined them and need to read up more on it. Anyway you convinced me that scrypt should work for my purposes. –  Adam Smith May 16 at 17:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.