# Is concatenated data hashed with scrypt vulunarable to a length extension attack?

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?

-
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 '14 at 16:51

## 1 Answer

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.

-
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 '14 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 '14 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 '14 at 16:19
@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 '14 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 '14 at 17:32