4 ms·

Refreshingly honest and clear response from vendor: http://hashcat.net/forum/thread-2238-post-13402.html#pid13402 http://hashcat.net/forum/thread-2238-post-134

by miles 14y ago

Refreshingly honest and clear response from vendor: http://hashcat.net/forum/thread-2238-post-13402.html#pid13402 http://hashcat.net/forum/thread-2238-post-13402.html#pid1340... Here's a taste: This design flaw is certainly real, and is one of the many reasons why we have started migrating to a new design. In short, when the Agile Keychain Format was designed (in 2008), we weren't aware of all of the various problems that come from using unauthenticated CBC mode encryption. I could plead that we were in reasonably good company in making that kind of error, but as I've since learned, research in academic cryptography had been telling people not to use unauthenticated encryption for more than a decade. This is why today we aren't just looking at the kinds of attacks that seem practical, but we are also paying attention to security theorems.

milesf 14y ago
The fact that AgileBit's rep Jeffrey Goldberg is speaking honestly and in plain english about the problem only galvanizes my decision to keep using and recommending their product. It builds trust, as in I trust they will fix the problem and fix it properly.
- StavrosK 14y ago
  To be honest, it really isn't much of a vulnerability either. Without this attack, the speed would be 800 Khash/sec. It just speeds it up by a factor of four. If your passphrase is sufficiently good, you're safe.
  - marshray 14y ago
    No, the attack speeds it up by a factor of two (1 bit). The other factor of two was a known and expected optimization for HMAC that the OCLHashcat developer(s) discovered the hard way. The defenders (1PW's users) may have already been taking advantage of this optimization, so it really doesn't count as an "attack".
    - StavrosK 14y ago
      Hmm, which is the 1-bit attack you're referring to? I only see one. Also, which is the optimization they might be taking? I don't see any.
      - marshray 14y ago
        One of the factors-of-two comes from computing the first input block of the two SHA's in the HMAC calculation and re-using this. This optimization in HMAC was underdocumented, but it ought to have been used by PBKDF2 implementations. The other factor-of-two, i.e., the 1-bit attack, comes from skipping the generation of the CBC mode IV and only generating 1 output block (160 bits) of PBKDF2 output for the key and using a later ciphertext block to check the candidate password. This saves the attacker half of the PBKDF2 work factor. This is a weakness in PBKDF2 when used to generate key material longer than the underlying hash function output length. RFC 2898 explicitly endorses deriving multiple keys in the manner 1Password used it: For instance, one might derive a set of keys with a single application of a key derivation function, rather than derive each key with a separate application of the function. The keys in the set would be obtained as substrings of the output of the key derivation function. This approach might be employed as part of key establishment in a session-oriented protocol. ... without mentioning the fact that some of the derived keys would impose more work factor than others.
        StavrosK 14y ago
        Ah, yes, you are quite right. It seems like gross negligence on the part of the document to not mention that, given that the work factor is basically exactly what PBKDF2 is used for.
        tptacek 14y ago
        I think you mean CBC mode IV, not CTR mode IV. If they'd been using CTR mode, not having the nonce would be a dealbreaker for the attack; no matter what the cracker did, it would never generate the right keystream. (I don't think using CTR mode would have made a lot of sense and am not saying the use of CBC mode is a design weakness; it isn't.)

by miles 14y ago

milesf 14y ago

The fact that AgileBit's rep Jeffrey Goldberg is speaking honestly and in plain english about the problem only galvanizes my decision to keep using and recommending their product. It builds trust, as in I trust they will fix the problem and fix it properly.

StavrosK 14y ago
To be honest, it really isn't much of a vulnerability either. Without this attack, the speed would be 800 Khash/sec. It just speeds it up by a factor of four. If your passphrase is sufficiently good, you're safe.
- marshray 14y ago
  No, the attack speeds it up by a factor of two (1 bit). The other factor of two was a known and expected optimization for HMAC that the OCLHashcat developer(s) discovered the hard way. The defenders (1PW's users) may have already been taking advantage of this optimization, so it really doesn't count as an "attack".
  - StavrosK 14y ago
    Hmm, which is the 1-bit attack you're referring to? I only see one. Also, which is the optimization they might be taking? I don't see any.
    - marshray 14y ago
      One of the factors-of-two comes from computing the first input block of the two SHA's in the HMAC calculation and re-using this. This optimization in HMAC was underdocumented, but it ought to have been used by PBKDF2 implementations. The other factor-of-two, i.e., the 1-bit attack, comes from skipping the generation of the CBC mode IV and only generating 1 output block (160 bits) of PBKDF2 output for the key and using a later ciphertext block to check the candidate password. This saves the attacker half of the PBKDF2 work factor. This is a weakness in PBKDF2 when used to generate key material longer than the underlying hash function output length. RFC 2898 explicitly endorses deriving multiple keys in the manner 1Password used it: For instance, one might derive a set of keys with a single application of a key derivation function, rather than derive each key with a separate application of the function. The keys in the set would be obtained as substrings of the output of the key derivation function. This approach might be employed as part of key establishment in a session-oriented protocol. ... without mentioning the fact that some of the derived keys would impose more work factor than others.
      - StavrosK 14y ago
        Ah, yes, you are quite right. It seems like gross negligence on the part of the document to not mention that, given that the work factor is basically exactly what PBKDF2 is used for.
      - tptacek 14y ago
        I think you mean CBC mode IV, not CTR mode IV. If they'd been using CTR mode, not having the nonce would be a dealbreaker for the attack; no matter what the cracker did, it would never generate the right keystream. (I don't think using CTR mode would have made a lot of sense and am not saying the use of CBC mode is a design weakness; it isn't.)