# Tag Info

26

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 ...

26

The algorithms themselves just output binary (i.e. bytes) if you read their specifications. It's the implementation in API's and applications that output the hexadecimals and/or base64. Sometimes there are also ad hoc standards / common practice that specifies a certain output format. This is for instance the case for the output of the bcrypt password ...

25

Using Base64/HEX has nothing to do with security of a hash algorithm. Base64 and HEX are ways to represent binary data, which is the actual output of a hash algorithm. Base64 is shorter simple because it uses a larger charset than HEX. (64 characters vs 16 characters) Besides, algorithms like SHA-256 and SHA-512 are only "unsafe" when used for password ...

17

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 ...

14

Actually, it turned out that scrypt was not as good as initially advertised under all conditions. Scrypt was designed to support the specific case of password-based key derivation for full harddisk encryption. Basically, you type your password when the machine boots up (or awakes from hibernation). This is a context where the following apply: The password ...

13

$r$ determines the sequential read size. This should only be changed if you have custom hardware that has a memory subsystem with different characteristics. It takes time to pull data from main memory, and the sequential read size allows the memory latency and CPU processing to be well-balanced on your system. Treat it like a constant unless you know what ...

12

This home-made construction is pointless and unnecessarily complex, Complexity is often the source of vulnerabilities. In this case, for example, I’ll wager you’re not securely handling the intermediate variables as you chain the multiple password hashes together. Simply use argon2 only and increase the work factors. “Double scrypt” is fairly meaningless as ...

9

Note that Blake2's security goals are a superset of those of SHA-256: SHA-256 is conjectured to be collision resistant, preimage resistant and second preimage resistant. Blake2 is conjectured to be random oracle indifferentiable, a stronger property that SHA-256 doesn't have, and which implies the three classic hash function properties. So yes, this ...

7

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 and ...

7

As far as I read, scrypt can be used for some time/memory tradeoffs where you save memory but take more computations, which may truly be an annoying thing. Argon2d uses data dependent on the input (i.e. the password), which makes it a lot stronger against these tradeoff attacks but opens side-channels (which IIRC is only a problem if you have an attacker ...

7

There's no point in using either an ASIC or a GPU to calculate a single password hash. That's true whether you use PBKDF2 or scrypt or Argon2 or whatever. What massively parallel devices like GPUs or ASICs are good for is hashing millions or billions of passwords at the same time. That's useful if you're mining a cryptocurrency or trying to crack a hash ...

7

You are using the KDF wrong. The only purpose of Argon2 and scrypt (and related constructions like bcrypt and PBKDF2) is to slow down dictionary and brute force attacks against passwords created by humans. Using it on a randomly generated key exchanged using ECC is improper as the key is strong. You are using salts wrong. The purpose of a salt is to ...

7

CTR is insecure if you reuse a key/iv pair. Since the salt is random, a different encryption key will be derived every time you encrypt something. Therefore it is safe even if it always uses the zero IV. Of course, the password must be strong enough to resist brute force attacks.

6

Salsa20/8 is used not to enhance cryptographic strength, but to make random-ordered requests to the RAM (and to slower FPGA/ASIC implementation of scrypt). The scrypt uses PBKDF2-HMAC-SHA-256 (PBKDF2 of HMAC-SHA256) to provide such strength. There is simple variant of scrypt, with parameters p=1 (Parallelization parameter), N=16384, r=8, taken from linked ...

6

The threat model of password storage is that of server compromision, where the attacker gain access to the database and server code. The attacker can then run the code to test password candidates, possibly making modifications, porting to faster platform, etc. The attacker will not bother computing the fake hash and fake salt. So this scheme is twice as ...

6

Probably because a simple cascade would only be stronger against some attacks, while opening the door to more implementation bugs. While bcrypt and scrypt are password-hashing functions, much of what is in the answers to this question about combining hash functions applies here. Different constructions give preimage resistance and PRF-ness, and which is ...

6

The question correctly finds that In the case of PBKDF2, you will need to buy an ASIC to be ideal and proceeds assuming the legitimate server does that; or at least, uses a GPU as substitute. Which, in practice, does not happen. That's where the question's reasoning drifts from reality. When we compare PBKDF2 to Scrypt, and conclude the later is vastly ...

6

The combined strength of two key stretching algorithms is not greater than the sum of its parts. It is at best equal to the sum of its parts. If you budget $x$ amount of CPU time to password stretching then you have to decide, do you give 100% of $x$ to scrypt? 100% to bcrypt? 50-50? You can't give both 100% of $x$ to both scrypt and bcrypt because that's ...

5

The operation: X[16] & (N-1) is really, mathematically speaking: $$X[16] \mathrm{\ mod\ } N$$ With a generic $N$, this operation must be done with an actual division, which is expensive; some CPU types don't provide it, and for CPU which do provide it (e.g. x86), it is quite slow (for instance, for 32-bit operands on an Intel Core2, division latency ...

5

Scrypt is most certainly a password-based-key-derivation-function. So is PBKDF2, although it can be confusing since PBKDF2 is an eponym. To add to the confusion, Scrypt uses PBKDF2 internally (which may be the hashing function you refer to), as well as the Salsa20/8 Core function (which may be the encryption function you refer to). Further reading here.

5

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 ...

5

All looks pretty secure except for your auth key derivation. You should use a better key derivation method like HKDF instead of just SHA-512. I don't think your random nonce is doing anything in this scenario - an attacker who wants to brute-force a weak password wouldn't be slowed down by a nonce transmitted in the clear. Why not just use a randomly-...

5

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 ...

5

Yes, this is secure, even though scrypt uses PBKDF2 inside. PBKDF2 has the issue that it the work factor is required $n$ times where $n$ is the number hash outputs concatenated to create the final PBKDF2 output. That means that if you can check the validity of PBKDF2 using only the initial bits (in your case used for the key if the hash was SHA-256, for ...

5

I guess the honest answer is nobody can know for sure, however: There's a general rule of thumb in cryptography, that once there was been wide rewards for breaking an algorithm (be it a hash function, a cipher or in this case a key deviation function) but nobody has come to close the breaking it, then we are in the "safest period". Scrypt is almost ...

4

Salsa20 core is not a collision resistant hash function, see DJB's own webpage: http://cr.yp.to/salsa20.html For example, Salsa20core(x) = Salsa20core(x + c) for c = "0000000800000008...", thus demonstrating trivial collisions. To be concrete, try computing Salsa20core for the the following two inputs: 00000000000000000000000000000000 ...

4

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 was ...

4

The scrypt function is specifically designed to hinder such attempts by raising the resource demands of the algorithm. Specifically, the algorithm is designed to use a large amount of memory compared to other password-based KDFs, making the size and the cost of a hardware implementation much more expensive, and therefore limiting the amount of paralleling an ...

4

Can formulae for equivalent year cost be constructed to determine the parameters as functions of time since those tests were performed? Yes, but you have to make a lot of assumptions. First, though, note that the paper says: We caution again that these values are very approximate [...] Nevertheless, we believe that the estimates presented here are useful ...

4

I don't think it is a good idea, for two main reasons. Firstly, you are basing your security on the obscurity of a parameter that was not designed initially for being secret, which is a risky practice. It is similar to hiding the salt. Secondly, following your example, you may in principle think that a random number of iterations between 10 and 100,000 is ...

Only top voted, non community-wiki answers of a minimum length are eligible