7 ms·
The password hash Argon2, winner of PHC
- abhv 11y agoI just saw the talk by Dmitry today on Argon2 at RealWorldCrypto. I was impressed by the ideas there; in particular, the ideas in Argon2 can be extended to transform any protocol into one that includes memory-hard steps. This re-balances the potential adversary advantage. Very neat concept.
- mintplant 11y ago> There are two main versions of Argon2, Argon2i and Argon2d. Argon2i is the safest against side-channel attacks, while Argon2d provides the highest resistance against GPU cracking attacks. Does this mean that one has to choose between protection against side-channel attacks and protection against GPU cracking? While not the "safest", how safe is Argon2d against side-channel attacks, and vice-versa? Any advice on making this choice? (It's late here so I haven't read the paper yet. Apologies if this is all covered in there.)
- jph 11y agoQuick answer: use Argon2i, unless you have very special needs. "Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation. Argon2i is slower as it makes more passes over the memory to protect from tradeoff attacks." "Argon2d is faster and uses data-depending memory access, which makes it suitable for cryptocurrencies and applications with no threats from side-channel timing attacks." The IETF draft is here: https://tools.ietf.org/html/draft-josefsson-argon2-00 https://tools.ietf.org/html/draft-josefsson-argon2-00
- nightcracker 11y ago> Does this mean that one has to choose between protection against side-channel attacks and protection against GPU cracking? Yes. Argon2i is still resistant against GPU cracking, however with advanced techniques some speedup might be acquired. Argon2d is really GPU unfriendly. The paper explains: > Should the memory addressing (indexing functions) be input-independent or input-dependent, or hybrid? The first type of schemes, where the memory read location are known in advance, is immediately vulnerable to time-space tradeoff attacks, since an adversary can precompute the missing block by the time it is needed [5]. In turn, the input-dependent schemes are vulnerable to side-channel attacks [14], as the timing information allows for much faster password search. And the recommendation from the paper: > Argon2 has two variants: Argon2d and Argon2i. Argon2d is faster and uses data-depending memory access, which makes it suitable for cryptocurrencies and applications with no threats from side-channel timing attacks. Argon2i uses data-independent memory access, which is preferred for password hashing and password-based key derivation.
- fryguy 11y agoBasically, use Argon2d for proof-of-work, and Argon2i for everything else.
- tromp 11y agoA memory intensive proof-of-work should be much faster to verify than to attempt a proof.
- khovratovich 11y agoIt is always safe to use Argon2i with smallest possible t=1 unless ASIC-equipped attackers is a viable threat to you.
- jph 11y agoArgon2 is an improvement over bcrypt, scrypt, etc. For typical needs, such as passwords and keys, you'll want to use the Argon2i variant, which is slower and provides more protections. For atypical needs, when you're certain there are no side-channel risks, you may want to use the Argon2d variant, which is faster. Argon2 has introduction slides here: https://www.cryptolux.org/images/c/c5/Rwc-slides.pdf https://www.cryptolux.org/images/c/c5/Rwc-slides.pdf
- tryp 11y agoToward the end of that slide deck, in the "Slowing Brute Force" section, there the following slide: > Argon2 ensures that both defenders and attackers hash passwords on the same platform (x86) Do they simply mean that currently the most cost effective platform to deliver the necessary computation and memory is x86? I'm having trouble believing that it is either achievable or desirable to design a password hash that's only efficient on one architecture.
- sbierwagen 11y agoI'm having trouble believing that it is [...] desirable To make it less useful to build a NSA-style ASIC hash cracking cluster, like https://en.wikipedia.org/wiki/EFF_DES_cracker https://en.wikipedia.org/wiki/EFF_DES_cracker I'm having trouble believing that it is [...] achievable The point is not to write an algorithm that is only fast on x86, rather than ARM, POWER, whatever; it's to write an algorithm that uses so much memory that it's not orders-of-magnitude faster to use an ASIC that's just a bunch of compute cores connected to fast buses, rather than a general-purpose processor with megabytes of on-chip cache.
- nanofortnight 11y agoThe entire point of "memory-hardness" and "anti-parallelisation" and other such properties is to make it such that the CPU is the most desireable platform to for the password stretching function to run. Why is this desireable? This is desireable because your server has a CPU. Your attacker has a CPU, a GPU, perhaps an FPGA, and could possibly manufacture a custom ASIC. You do not want the attacker to be able to cost-effectively bruteforce on any of these platforms any more efficiently than a single CPU core can. This makes password cracking difficult, and it also means we do not need to have absurd CPU runtimes for our hash, a handful of milliseconds is sufficient. (More is of course better, and for a single user system a delay of half a second isn't noticeable.) What would occur if we did not design password stretching functions that had this property? We would end up in the situation we have now, where nonstandard hardware computes hashes faster than we can, and thus instead of taking (a few miliseconds * number of possibilities) it takes (smaller amount of time * number of possibilities). This is undesireable. This is also why you should never use a typical fast cryptographic hash function like SHA256, SHA3 or RIPEMD160 to hash passwords. This is also why PBKDF2 is considered less secure than say scrypt.
- jedisct1 11y agoArgon2i was recently merged into libsodium, and will be part of the next release, as the default password hashing function.
- deleted 11y ago[deleted]
- onlydnaq 11y agoAwesome, good work. I was just going to ask you if you had any roadmap for adding Argon2i.
- jbb555 11y agoI thought this looked interesting until I read the page :- "A memory cost, which defines the memory usage, given in kibibytes " Kibibytes? Really? Can't read any more. I'll find something else.
- spuz 11y agoWhat's your objection? It should be mibibytes?
- reinhardt1053 11y agomebibytes
- Robin_Message 11y agoI am quite happy that something as important as password hashing uses precisely defined technical language to describe its operation. The evaluation of which password-hashing function to use probably should not be based on the simplicity of language used in their description.
- Johnny_Brahms 11y agoDon't blame argon2, blame computer storage makers. They were the ones to go metric.
- mc808 11y agoThe problem is that people feel ridiculous trying to pronounce "kibibyte", "mebibyte", etc. Probably the same reason "jiggabyte" never took hold except among grey old engineers. But no, I don't have a better replacement.
- ybx 11y agoYou're angry because they properly measure base 2 data? Even if you disagree on how proper it is, that seems like an extremely small and unimportant qualm.
- 11y ago
- lelf 11y agoSome discussion here: https://news.ycombinator.com/item?id=10857771 https://news.ycombinator.com/item?id=10857771 (less than a day ago)
- wereHamster 11y agoWhy was scrypt/bcrypt not part of the competition?
- creshal 11y agobcrypt is just obsolete – this was to find a successor to it. yescrypt, one of the recommended finalists, is an improved/fixed version of scrypt.
- themartorana 11y agoWhat's the best way to move a huge database from one scheme to the next? It's hard to keep up...
- saulr 11y agoOn your `User` table you have a column such as `hashing_scheme`. If you don't have one of these columns already, create it with the default value of your current scheme (e.g., `bcrypt`) When a user attempts to log in, you hash the password they submitted with whatever's in that user's `hashing_scheme`. If the password was incorrect, fail early. If the password was correct, and this user's `hashing_scheme` value is different to the application's `current_hashing_scheme`, you rehash the user's password (that you got via the POST request or otherwise) with the new scheme, update the `password_hash` and `hashing_scheme` value in the database. This is just one way to do it, which is how Django performs hashing scheme migrations IIRC.
- artursapek 11y agoAlternatively, you can update the entire user db at once by hashing their existing password hashes. You'll end up using a double-hash: new_hashing_scheme(old_hashing_scheme(password)) Not as elegant, but the benefit is you can immediately move everyone to a new scheme if you need to for some reason.
- esnard 11y ago
- ocharles 11y agoHaskell bindings are here: https://hackage.haskell.org/package/argon2-1.0.0/docs/Crypto-Argon2.html https://hackage.haskell.org/package/argon2-1.0.0/docs/Crypto...
- jnoland 11y agoIs there a pure Python version of Argon2?
- sbierwagen 11y agoI'm guessing it would be hard to eliminate timing side-channels in pure python, so no.
- bwesterb 11y agoI am writing one. You should use the C one, if you can. https://github.com/bwesterb/argon2pure https://github.com/bwesterb/argon2pure