4 ms·

Not if you use a permutation like a block cipher with a fixed key, rather than an arbitrary function.

dchest 14y ago
Not what? That you've suggested a completely different scheme (single algorithm with a key) to the one described in the comment I replied to (combining multiple algorithms)? :) (Note that even using a standard block cipher requires a separate evaluation for different purposes -- you can't claim that your hash function/MAC/mode of operation is as secure as AES only because it's based on AES.) If you read my replies in this thread, I emphasize the point that if you really need a custom function with secret parameters, use a single algorithm with a secret key (I even gave a link to one such scheme with HMAC.)
- EthanHeilman 14y ago
  You missed my point. I was saying that this scheme AES(key, SHA256(password|salt)) is at least as secure as this scheme SHA256(password|salt).
  - marshray 14y ago
    No, it can be worse. If 'key' must be kept secret in order to achieve its stated security properties now the system is much more unwieldy for the defender. He now has a key distribution problem that he didn't have before. If the defender can reliably solve the key distribution problem then the attacker wouldn't have gotten a copy of the password key database. On the other hand, if 'key' is public, then the incremental computational cost added with AES raises the cost for the defender, but not the attacker. The attacker can just un-AES a password hash once and remember the result whereas the defender must perform the AES on every password validation.
    - EthanHeilman 14y ago
      Consider the possibilities: (1) if the key is captured by the attacker the system is just as strong as SHA256, (2) If the key is not captured by the attacker then the system is as unbreakable as AES. Many of the attacks that lead to password hash exposure involve a SQL injection that dumps the password table. If you store the password in the source code an attacker must then capture both the source code and the hashes. Furthermore, if they leak your key, you learn that they have gained access to your source code. I agree that this is a less than ideal system. My point was not to design a better system, but to point out that composing permutations with a secure hash function is at least as strong as that secure hash function. If you disagree consider the identity permutation. Really you'd want to implement it like SHA256(AES(key,SHA256(password|salt)). If I wanted to design a better system this is what I would do. Put the hashing system on a dedicated box that maps passwords to hashes. To compromise the hash key an attacker must compromise your hashing box and your database. Locking-down a box that performs only one action, hashing, is significantly easier than locking down a complex web application.
      - marshray 14y ago
        > (1) if the key is captured by the attacker the system is just as strong as SHA256 This is the part that I think is subtly invalid. Coincidentally, I was having this mailing list discussion the other day: http://lists.randombit.net/pipermail/cryptography/2012-May/002953.html http://lists.randombit.net/pipermail/cryptography/2012-May/0... It has to do with the fact that the defender is obligated to pay the cost of the AES every time (because he follows the rules of the algorithm by definition). But the attacker is free to bend the rules however he can and one thing he can do is perform the AES once on the entire data file, a negligible amount of computation. So even though AES is an identity transformation, it makes the function more costly for the defender than for the attacker. Wncrypting one's database may be an acceptable tradeoff for other reasons, but when we're considering the work factor for cracking passwords this is worse. Think about if instead of just one iteration of AES it were iterated a zillion times in order to make it expensive. That would be a complete failure.
        EthanHeilman 14y ago

Not what? That you've suggested a completely different scheme (single algorithm with a key) to the one described in the comment I replied to (combining multiple algorithms)? :) (Note that even using a standard block cipher requires a separate evaluation for different purposes -- you can't claim that your hash function/MAC/mode of operation is as secure as AES only because it's based on AES.) If you read my replies in this thread, I emphasize the point that if you really need a custom function with secret parameters, use a single algorithm with a secret key (I even gave a link to one such scheme with HMAC.)

EthanHeilman 14y ago
You missed my point. I was saying that this scheme AES(key, SHA256(password|salt)) is at least as secure as this scheme SHA256(password|salt).
- marshray 14y ago
  No, it can be worse. If 'key' must be kept secret in order to achieve its stated security properties now the system is much more unwieldy for the defender. He now has a key distribution problem that he didn't have before. If the defender can reliably solve the key distribution problem then the attacker wouldn't have gotten a copy of the password key database. On the other hand, if 'key' is public, then the incremental computational cost added with AES raises the cost for the defender, but not the attacker. The attacker can just un-AES a password hash once and remember the result whereas the defender must perform the AES on every password validation.
  - EthanHeilman 14y ago
    Consider the possibilities: (1) if the key is captured by the attacker the system is just as strong as SHA256, (2) If the key is not captured by the attacker then the system is as unbreakable as AES. Many of the attacks that lead to password hash exposure involve a SQL injection that dumps the password table. If you store the password in the source code an attacker must then capture both the source code and the hashes. Furthermore, if they leak your key, you learn that they have gained access to your source code. I agree that this is a less than ideal system. My point was not to design a better system, but to point out that composing permutations with a secure hash function is at least as strong as that secure hash function. If you disagree consider the identity permutation. Really you'd want to implement it like SHA256(AES(key,SHA256(password|salt)). If I wanted to design a better system this is what I would do. Put the hashing system on a dedicated box that maps passwords to hashes. To compromise the hash key an attacker must compromise your hashing box and your database. Locking-down a box that performs only one action, hashing, is significantly easier than locking down a complex web application.
    - marshray 14y ago
      > (1) if the key is captured by the attacker the system is just as strong as SHA256 This is the part that I think is subtly invalid. Coincidentally, I was having this mailing list discussion the other day: http://lists.randombit.net/pipermail/cryptography/2012-May/002953.html http://lists.randombit.net/pipermail/cryptography/2012-May/0... It has to do with the fact that the defender is obligated to pay the cost of the AES every time (because he follows the rules of the algorithm by definition). But the attacker is free to bend the rules however he can and one thing he can do is perform the AES once on the entire data file, a negligible amount of computation. So even though AES is an identity transformation, it makes the function more costly for the defender than for the attacker. Wncrypting one's database may be an acceptable tradeoff for other reasons, but when we're considering the work factor for cracking passwords this is worse. Think about if instead of just one iteration of AES it were iterated a zillion times in order to make it expensive. That would be a complete failure.
      - EthanHeilman 14y ago