Hot answers tagged

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


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.


5

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


4

I seem to recall that shared secret keys should be hashed before using as encryption keys (some brief discussion here). If your key is already high-entropy, then hashing with SHA256 is fine. If you plan to generate several keys (ie, encryption and HMAC) from the original shared secret, then HKDF is a good option. This is a key-based KDF. Scrypt and ...


4

No, you cannot assume that no collisions can be found if there is a chance of $1 \over 2^{32}$ per try. That's too high a risk for almost any kind of cryptographic scheme, especially if parallel attacks are possible. This is true by definition for scrypt as you can simply try multiple passwords at the same time. That kind of parallelization cannot be avoided ...


4

The salt is not required to make HKDF secure. Using a static salt doesn't make too much sense - you should be perfectly fine with using an empty salt. Either you can use an empty salt, or a new random salt. This salt could be generated and prefixed per file. If it is large enough (say 128 bytes) then it would make each encryption key unique so you don't have ...


3

15,000,000,000 passwords For a 64-bit hash, the probability that a collision exists is approximately $1 - e^{-(15,000,000,000)^2 / (2^{64} \times 2)} \approx 0.9978$. So whatever the hash algorithm is, it's very likely that there is a collision, the only problem is to find it. If your algorithm is a cryptographic hash, then the only way to find a collision ...


3

The function SHA-1 is defined on a message $m$ that is a sequence of bits. It works as follows—this form is named Merkle–Damgård after the people who suggested it in days of yore: Let $m' = m \mathbin\| 1 \mathbin\| 0^p \mathbin\| \operatorname{length}(m)$ be the result of padding $m$ with a one bit, $p$ zero bits, and a 64-bit message length, so that the ...


3

I would recommend you use Argon2, which is both a slow KDF like PBKDF2, as well as a memory-hard function designed to improve resistance to GPUs and FPGAs like scrypt. You can select both the number of iterations and amount of memory used in Argon2, and they can be changed independently (unlike scrypt, where the memory and time difficulties cannot be ...


2

There is no real reason for the info values to be 512 bits long. The only requirement for them is to be unique, and for that, even 128 bits of randomness is enough (at least assuming that you won't be encrypting more than $2^{64}$ files with the same key). The same goes for the salt, too. Of course, using longer values won't really hurt security, it just ...


2

Generally you should be fine with having a minimum size of 128 bits and a maximum size of 256 bits for parameters such as salts. Although you should halve the security parameter because of the birthday problem, I think most cryptographers would still choose 256 bits salts as maximum. It is unlikely that the birthday problem can be used to enhance the ...


1

If you use the key only once, then there is no danger of reusing a nonce with the same key because you're not even reusing the key! A collision in the salt and password would lead to the same key, but though the probability of such a collision may be nonzero, it is nevertheless negligible for a 32-byte salt—unless, of course, you roll back your VM state and ...


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