3 ms·

> PBKDF2 is worse than bcrypt. You seem to be speaking only to its compute time -- what do you say to the article's claim that bcrypt has a higher probability

> PBKDF2 is worse than bcrypt. You seem to be speaking only to its compute time -- what do you say to the article's claim that bcrypt has a higher probability of having an unexpected attack that mitigates its computational complexity? Also, since all of these algorithms have adjustable work factors, what does it even mean to say that one is stronger than another? Couldn't you just calibrate the work factors so that they are equivalently strong? Though naturally scrypt has strength in another dimension also (memory).

tptacek 15y ago
It's nonsensical. It essentially argues that SHA2 is less likely to have cryptographic results relevant to hashing in the next 5 years than Blowfish. It's also an argument the post doesn't support with any actual evidence. But that's not my issue with the article. My issue with the article is that it takes a simple security issue with no "real" wrong answers and turns it into a tribal conflict, which has the net effect of reducing the number of people who will use adaptive hashing at all. I'm familiar with Tony Arcieri's work and generally think highly of him; this article, though, is inexplicable and smacks of hipsterism. "I liked Nirvana but then they got popular and sold out, so now I listen to Sleater Kinney". Well, that's going to sound dumb in 10 years. Let me say yet again that if you use PBKDF2, bcrypt, or scrypt, you are going to look smarter than the average webdev, no matter which one you pick. Do whichever is easiest.
- bascule 15y ago
  I fully admit the title is linkbait. My goal was to get people interested in the alternatives to bcrypt.
  - JoachimSchipper 15y ago
    Why? "Use bcrypt" is boring from a crypto-nerd point of view, but it's a really useful meme.
    - bascule 15y ago
      I thought I explained that in my blog post. scrypt is superior to bcrypt in every regard. At the very least, I'd rather the meme be: Use bcrypt, scrypt, or PBKDF2.
      - drivebyacct2 15y ago
        Which is fine, but you've clearly dressed it up as flamebait "don't use bcrypt" outright.
      - tptacek 15y ago
        The problem is that PBKDF2 isn't superior to bcrypt in every regard: * It has marginally worse library support and is built out of universally available primitives, which increases the odds that generalist devs will DIY it. * It is actually faster than bcrypt (see Colin's paper); in other words, even without waiting for a hypothetical research result against bcrypt, PBKDF2 is already "vulnerable". * PBKDF2 deployments virtually all use SHA2 as their PRF, and PBKDF2/SHA2 is a construction that depends entirely on the security of hash functions; hash functions are more poorly studied than block ciphers. * Attacker tools are (mostly, but not entirely) built out of preexisting infrastructure and not by cryptographers; of the three functions, the best accelerated brute force support is available for PBKDF2/SHA2. For instance, is there a widely-available GPU implementation of bcrypt? * The standards process that ran for PBKDF2 did not include the extensive peer review that (say) AES went through, and isn't a significant asset for PBKDF2. Meanwhile, bcrypt had broad deployment long before PBKDF2 was widely deployed, and on higher-value target systems. You'd rather the meme be "Use bcrypt, scrypt, or PBKDF2". I'm fine with that meme! But that's not what you said. You said "please don't use bcrypt". PBKDF2 isn't bad. It has one significant asset: you can point to a PKCS standard to convince pointy-haired product managers to accept it into systems. But given the choice between an HN cargo cult and "technology made palatable to enterprise-grade engineering managers", I'll take the cargo cult in this instance. (Another strength of PBKDF2 that it shares with scrypt but not bcrypt: you can use it as a proper KDF for your AES keys... but note that if you need to generate your own AES keys, you're very likely in trouble for other reasons).
        15y ago

tptacek 15y ago

It's nonsensical. It essentially argues that SHA2 is less likely to have cryptographic results relevant to hashing in the next 5 years than Blowfish. It's also an argument the post doesn't support with any actual evidence. But that's not my issue with the article. My issue with the article is that it takes a simple security issue with no "real" wrong answers and turns it into a tribal conflict, which has the net effect of reducing the number of people who will use adaptive hashing at all. I'm familiar with Tony Arcieri's work and generally think highly of him; this article, though, is inexplicable and smacks of hipsterism. "I liked Nirvana but then they got popular and sold out, so now I listen to Sleater Kinney". Well, that's going to sound dumb in 10 years. Let me say yet again that if you use PBKDF2, bcrypt, or scrypt, you are going to look smarter than the average webdev, no matter which one you pick. Do whichever is easiest.

bascule 15y ago
I fully admit the title is linkbait. My goal was to get people interested in the alternatives to bcrypt.
- JoachimSchipper 15y ago
  Why? "Use bcrypt" is boring from a crypto-nerd point of view, but it's a really useful meme.
  - bascule 15y ago
    I thought I explained that in my blog post. scrypt is superior to bcrypt in every regard. At the very least, I'd rather the meme be: Use bcrypt, scrypt, or PBKDF2.
    - drivebyacct2 15y ago
      Which is fine, but you've clearly dressed it up as flamebait "don't use bcrypt" outright.
    - tptacek 15y ago
      The problem is that PBKDF2 isn't superior to bcrypt in every regard: * It has marginally worse library support and is built out of universally available primitives, which increases the odds that generalist devs will DIY it. * It is actually faster than bcrypt (see Colin's paper); in other words, even without waiting for a hypothetical research result against bcrypt, PBKDF2 is already "vulnerable". * PBKDF2 deployments virtually all use SHA2 as their PRF, and PBKDF2/SHA2 is a construction that depends entirely on the security of hash functions; hash functions are more poorly studied than block ciphers. * Attacker tools are (mostly, but not entirely) built out of preexisting infrastructure and not by cryptographers; of the three functions, the best accelerated brute force support is available for PBKDF2/SHA2. For instance, is there a widely-available GPU implementation of bcrypt? * The standards process that ran for PBKDF2 did not include the extensive peer review that (say) AES went through, and isn't a significant asset for PBKDF2. Meanwhile, bcrypt had broad deployment long before PBKDF2 was widely deployed, and on higher-value target systems. You'd rather the meme be "Use bcrypt, scrypt, or PBKDF2". I'm fine with that meme! But that's not what you said. You said "please don't use bcrypt". PBKDF2 isn't bad. It has one significant asset: you can point to a PKCS standard to convince pointy-haired product managers to accept it into systems. But given the choice between an HN cargo cult and "technology made palatable to enterprise-grade engineering managers", I'll take the cargo cult in this instance. (Another strength of PBKDF2 that it shares with scrypt but not bcrypt: you can use it as a proper KDF for your AES keys... but note that if you need to generate your own AES keys, you're very likely in trouble for other reasons).
      - 15y ago