4

I want a key stretching system that's as strong as the stronger of scrypt and PBKDF2. The consensus now is that scrypt is by far the better system, but that might change if in the future, a weakness is found in Salsa20. Here is a proposed system that I dreamed up, does it seem like a good idea?

First run scrypt and produce twice as much key material as needed. Use $N$, $r$ and $p$ parameters as normal.

$k_0 = \mathrm{scrypt}(\mathrm{key},\mathrm{salt},2 \cdot \mathrm{len},N,r,p)$

Then split the key $k_0$ into to equal pieces, $k_1$, and $k_2$. Now run PBKDF2, picking a sizable $c$ parameter:

$k_3 = \mathrm{PBKDF2}(k_2, \mathrm{salt}, \mathrm{len}, c)$

Finally, output $k_1 \oplus k_3$.

I was thinking that advantage of this construction over a more naive one (or just turning up the $c$ parameter in the PBKDF2 final round of scrypt) is that the original key isn't used as an input to the weaker PBKDF2, and that the output of PBKDF2 can't weaken the output of scrypt. However, if scrypt turns out to be easier than expected due to a Salsa20 weakness, then it still is necessary to brute-force PBKDF2.

Max Krohn
  • 231
  • 1
  • 4

1 Answers1

2

scrypt uses PBKDF2 internally, so it's absolutely crucial to prevent nasty interactions. My suggestion would be a simpler scheme (using simplified syntax):

$k = \mathrm{scrypt}(\text{key}, \text{salt} \mathbin\| 0x0) \oplus \mathrm{PBKDF2}(\text{key}, \text{salt} \mathbin\| 0x1)$

This does exactly what you want - that is, the output key has exactly the strength of the stronger of the two, without nasty interactions. Your construction may or may not have the same property, but the close relationship of scrypt and PBKDF2 makes me rather nervous.

forest
  • 15,626
  • 2
  • 49
  • 103
orlp
  • 4,355
  • 21
  • 31