Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You're correct - the scrypt functions those two links are playing with are the scrypt file encryption utility, not the underlying kdf. I've been slowly working on creating a standalone scrypt-based password hash for python, and ran into this issue myself. </p> <p>The scrypt file utility does the following: picks scrypt's n/r/p parameters specific to your system &amp; the "min time" parameter. It then generates a 32 byte salt, and then calls <code>scrypt(n,r,p,salt,pwd)</code> to create a 64 bytes key. The binary string the tool returns is composed of: 1) a header containing n, r, p values, and the salt encoded in binary; 2) an sha256 checksum of the header; and 3) a hmac-sha256 signed copy of the checksum, using the first 32 bytes of the key. Following that, it uses the remaining 32 bytes of the key to AES encrypt the input data.</p> <p>There are a couple of implications of this that I can see: </p> <ol> <li><p>the input data is meaningless, since it doesn't actually affect the salt being used, and encrypt() generates a new salt each time. </p></li> <li><p>you can't configure the n,r,p workload manually, or any other way but the awkward min-time parameter. this isn't insecure, but is a rather awkward way to control the work factor. </p></li> <li><p>after the decrypt call regenerates the key and compares it against the hmac, it will reject everything right there if your password is wrong - but if it's right, it'll proceed to <em>also</em> decrypt the data package. This is a lot of extra work the attacker won't have to perform - they don't even have to derive 64 bytes, just the 32 needed to check the signature. This issue doesn't make it <em>insecure</em> exactly, but doing work your attacker doesn't is never desirable.</p></li> <li><p>there is no way to configure salt key, derived key size, etc. the current values aren't that bad, but still, it's not ideal.</p></li> <li><p>the decrypt utility's "max time" limitation is wrong for password hashing - each time decrypt is called, it estimates your system's speed, and does some "guessing" as to whether it can calculate the key within max time - which is <em>more</em> overhead your attacker doesn't have to do (see #3), but it also means decrypt could start rejecting passwords under heavy system load. </p></li> <li><p>I'm not sure <em>why</em> Colin Percival didn't make the kdf &amp; parameter-choosing code part of the public api, but it's infact explicitly marked "private" inside the source code - not even exported for linking. This makes me hesitant to just access it straight without a lot more study. </p></li> </ol> <p>All in all, what is needed is a nice hash format that can store scrypt, and an implementation that exposes the underlying kdf and parameter-choosing algorithm. I'm currently working on this myself for <a href="http://pypi.python.org/pypi/passlib">passlib</a>, but it hasn't seen much attention :( </p> <p><em>Just to bottom line things though - those site's instructions are 'ok', I'd just use an empty string as the file content, and be aware of the extra overhead and issues.</em></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload