Hot answers tagged

28

The current Argon2 draft RFC, I think, provides a good, reasonably brief answers to this question. TL;DR: most people will indeed want to use Argon2id and not the "pure" variants. The introduction summarizes the issues quite well: Argon2 has one primary variant: Argon2id, and two supplementary variants: Argon2d and Argon2i. Argon2d uses data-depending ...


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


24

First, following the "next big thing" is not generally a good idea in the world of cryptography. You should strongly prefer battle-tested code and algorithms over new ones. In this particular case, consensus is mostly that Argon2 is highly unlikely to fall victim to attacks that make it worse in practice than scrypt, bcrypt, or PBKDF2, so you're not ...


23

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


23

Coming up with a specific number is hard. Realistically, all three options take you well out of the realm of ever having more than the absolute worst passwords brute-forced by an attacker. The primary gain of scrypt and argon2 over bcrypt is a hit to parallelism due to the addition of memory requirements. GPUs with thousands of cores will need (but don't ...


19

I'm wondering what the recommended number of iterations would be? Unlike bcrypt or traditional crypt, argon2 does not have a single iteration count, but three parameters affecting the computational cost: Number of iterations $t$, affecting the time cost. Size of memory used $m$, affecting the memory cost. Number of threads $h$, affecting the degree of ...


17

You need to consider the weakest link property: a security system is never stronger than its weakest link. Since Argon2 is a password-based function, the weak link here is going to be the strength of your users' passwords. Choosing a longer output length doesn't help if the passwords' entropy is lower than that. Think of it this way: if the hash function ...


16

Does the recent Balloon hashing paper and the included attack on Argon2 effectively negate the result of the Password Hashing Competition? No. The main result of the PHC was not a single new fancy password hashing function (i.e. Argon2), but a massive advancement in the research of password hashing. We understand password hashing and how to do it much ...


15

I have been part of several cryptographic competitions (AES, eSTREAM, SHA-3, PHC). In every single one of them, some people worded bitter reproaches and wailed and whined about the unfairness of the selection process. It's just that people are like that, and being very good at cryptography does not prevent smart cryptographers from being basically people. ...


13

If you take a look at the Password Hashing Competiton, you can see, that most of the schemes use Blake2b, some of them uses SHA-512, none of them uses SHA-256. Blake2b is optimized for 64-bit platforms and this property fits exactly the requirement of a password hashing scheme. SHA-512 would also be OK, but SHA-256 would be much slower in software and the ...


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


12

If you are unsure, then always choose Argon2id. Only choose Argon2d if you need maximum security at the expense of side-channel risk, and only choose Argon2i if side-channel attacks are the primary threat. The number of passes just increases resistance to time-memory tradeoff attacks (TMTO). What you are probably remembering is that Argon2i is more ...


10

I agree with Thomas Pornins answer, but there was one remarkable criticism on the panel. Round two of the competition actually allowed only minor tweaks. Argon switched to Argon2, which was more a new scheme and not a tweak. I welcome the unbureaucratic decision of the panel to accept Argon2, but formally this is objectionable. The answer for the second ...


9

It has been implemented, of course. In addition to the reference implementation, there are some crypto libraries with it like libsodium. It has not yet seen much use in applications or protocols, because it is relatively new and security people tend to be conservative. (And two years simply is not that long.) Stronger, at least in theory. The resistance to ...


9

The entire point of a key-derivation function like Argon2 is to increase the time (difficulty) it takes to create a key, and as a side effect, increase the resources required to attack the key. The problem with other key functions like PBKDF2 is that you can only set the total iterations required, while this is fine for many applications, it isn't ideal for ...


8

TL;DR: You want to use Argon2d here. Even though Argon2 was standardized only somewhat recently, it is the result of the Password-Hashing Competition (2013-2015) and was a late re-design of Argon which also picked up ideas from a few other finalists. Since then there have been attacks on it, which caused the scheme to be tweaked to counter them better, this ...


8

As @sejpm already hinted in his comment: both scale the same when it comes to the parameters. You might still want to read the RFC to get the complete picture, but the general differences can be quickly summarized: Argon2i Argon2i is invulnerable to side-channel timing attacks, but is weaker against time-memory trade-off (TMTO) attacks. Argon2i uses data-...


8

Should the secret data be encrypted with Alice's raw password? As a general rule of thumb: A password should only ever be fed into a password hashing scheme (PHS) such as Argon2, scrypt or bcrypt, never into anything else! There are multiple reasons for this: Passwords need special processing in the form of complexity parameters. Passwords need external (...


7

Some resources: The Argon2: paper and GitHub repo Catena: paper, a good thesis and GitHub repo Makwa: paper Yescrypt: paper Lyra2: paper and GitHub repo A GitHub repository with round 1 submissions A GitHub repository with round 2 performance analysis (not the official one though, iirc). Comparison of the candidates: Forler et al, Biryukov and Khovratovich, ...


6

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


6

The theory of password hashing assumes that the attacker knows the function used to hash every single password entry. The function is designed to slow down an attacker who knows the parameters. So they're not required to be secret; it's perfectly fine to store them in the same output string as the hash, and the official Argon2 reference implementation ...


5

The key idea of memory-hard functions like scrypt and Argon2, as I understand them, is to analyze the cost to the attacker in terms of a time-area product. Time is how much time the attacker spends. Area is how much silicon they use for the attack. The attacker is going to allocate a given area, but once that amount is fixed: More cores means less memory ...


5

This function returns a string that the verification function will consider valid when given the same password. You shouldn't have to care about what the string actually contains. If only because the default algorithm and parameters can change. But the guarantee above will always be true. But indeed, the string will be different if given the same password ...


5

Comparing hashes of strings does not fully defeat timing attacks. For example, if we try to find a password by timing attack of if (strcmp(sha256str(input),sha256str("honey7dew"))) ... where sha256str outputs the SHA-256 hash of its input as a 64-char C string in hexadecimal (4 bits per char), and we initially do not know "honey7dew" but suspect that ...


5

The first thing to note is that KeePass uses Argon2d which is the Argon2-variant with data-dependent memory access. Now it's best to (roughly) follow the guidelines lined out in the Argon2 specification (RFC draft): Figure out the maximum number h of threads that can be initiated by each call to Argon2._ This means you should set the parallelism value to ...


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

As of today, the resource I've found most useful for getting a quick, practical sense of how pick parameters for Argon2 is the (still draft) RFC, in particular section 9, which gives this guidance (in 9.2): The best attacks on the 1-pass and 2-pass Argon2i is the low-storage attack described in [CBS16], which reduces the time-area product (using the peak ...


4

ArgonHashString calls the libsodium function crypto_pwhash_str which automatically generates a salt value that is part of the result.


4

There is nothing fundamentally wrong about using fewer threads. It does mean you may not be able to make use of all the memory bandwidth you have, resulting in memory being filled a bit more slowly, but it will not damage the memory-hardness of Argon2. This is not ideal for you as the defender because parallelism is not meant to increase the number of ...


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


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