Tag Info

Both PBKDF2 and scrypt are key derivation functions (KDFs) that implement key stretching by being deliberately slow to compute and, in particular, by having an adjustable parameter to control the slowness. The difference is that scrypt is also designed to require a large (and adjustable) amount of memory to compute efficiently. The purpose of this is to ...

Both scrypt and pbkdf2 have variable length outputs, and each bit of the output is effectively independent on every other bit. So, one obvious way would be just to ask for enough output for both keys. For example, if the two keys are each 128 bits, then ask scrypt (or pbkdf2) for 256 bits of output; use the first 128 bits as the first key, and the second ...

Yes, scrypt achieves this. Scrypt has a variable-length output, so just generate as much output as you need. For instance, you can ask it for 256 bits of output, then use the first 128 bits for one key and the second 128 bits for the other key. While PBKDF2 also has a variable-length output, I do not recommend that you use it in the same way. It has a ...

Non-malleability of Scrypt w.r.t. to salt (as well as passphrase) follows from the definition of Scrypt (which simply pass that salt to that input of PBKDF2); the definition of PBKDF2 (which uses the salt followed by a non-malleable encoding of an integer as a massage passed to HMAC_SHA256); the non-malleability of HMAC_SHA256 w.r.t. the message; and perhaps ...

Scrypt depends more on being a "Memory-Hard algorithm" as seen under section 2 here. PBKDF2 relies more on increasing CPU requirements by adding iterations. A good high level explanation of how KDFs like bcrypt/scrypt work is seen here. Also check out this explanation for a little more detail.

No, you don't have to worry about collisions. As long as no pair of users have the same LowEntropy input, they will receive different MasterKeys. If the MasterKey is different, then the AuthKey will be different. Even if you use the same MasterKey to generate multiple AuthKeys, you don't need to worry about collisions: as long as the keynumber values are ...

If you have a high entropy input, then scrypt isn't a good choice. It's purpose is to compensate for the low entropy of a password. Don't ask the user for memory/cpu factors, you don't need them if the input is high entropy. You don't need a salt either. Simply use an input of at least 16 bytes from a secure random number generator. I recommend using one ...

Often I hear the key expansion is the weakest part of AES, but conflictingly that it was designed to prevent the use of "weak keys" which its precedent suffered from. The terms "weak" here mean different things. Some of the best attacks on AES have been oriented at attacking the key schedule. When these attacks were released the cryptographic community ...

The AES key schedule is firstly very fast, and build from a component (the s-box) that is used in the main encryption algorithm, too, so it can be implemented easily, sharing code (in software) or chip area (in hardware). I'm not sure how the AES key schedule avoids "weak keys" – I suppose this is meant to say that every AES key, when expanded, contains ...

What is the main difference of the three? Can I use only one of them for everything (e.g. GPG for SSH authentication) GnuPG is an free and open-source implementation of the OpenPGP standard. Symantec PGP is a proprietary implementation of the OpenPGP standard. The OpenPGP standard defines ways to sign and encrypt information (like mail, other documents ...