4 ms·

https://github.com/turtl/js/blob/2ca59900d71284795e278e75585787ca767e9766/library/tcrypt.js#L192-L195 https://github.com/turtl/js/blob/2ca59900d71284795e278e755

https://github.com/turtl/js/blob/2ca59900d71284795e278e75585787ca767e9766/library/tcrypt.js#L192-L195 https://github.com/turtl/js/blob/2ca59900d71284795e278e75585... Nothing says secure like PBKDF2-SHA1 with 50 rounds. https://github.com/turtl/js/blob/2ca59900d71284795e278e75585787ca767e9766/library/tcrypt.js#L577 https://github.com/turtl/js/blob/2ca59900d71284795e278e75585... ...or timing attacks on MAC validation. (Yeah, you switched to GCM, but a downgrade attack could potentially be used to find a valid MAC for a chosen ciphertext without the attacker knowing the key...)

mrmondo 11y ago
"When the standard was written in 2000, the recommended minimum number of iterations was 1000, but the parameter is intended to be increased over time as CPU speeds increase. As of 2005 a Kerberos standard recommended 4096 iterations,[2] Apple iOS 3 used 2000, iOS 4 used 10000,[3] while in 2011 LastPass used 5000 iterations for JavaScript clients and 100000 iterations for server-side hashing" source: https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2 *Edit: Oh.. it's PBKDF1....
- sarciszewski 11y ago
  Nope, PBKDF1 was a typo.
- logicallee 11y ago
  how can anyone take anything seriously that requires 1000 iterations. if iterations had an exponential function then the difference between 1000 iterations and 10,000 is ridiculous, like the difference between 16 bit encryption (no such thing, this would be a joke) and 160 bit encryption. But if it's not exponential, then adding thousands of iterations doesn't do much. Maybe instead of 1 day to break it, now it takes 1000 days, or instead of spending $4,000 on CPU time now you need to spend $4M to crack it. Big deal - it's just as broken. So can anyone explain the math here? How can they seriously suggest linearly increasing the number of iterations over time?
  - sarciszewski 11y ago
    Attackers can use special hardware (ASICs, for example) to perform a lot of low-memory but CPU-intensive calculations quickly. Modern KDFs emphasize a property called memory-hardenss: It should be reasonably fast on consumer devices, require a reasonable amount of memory, and trading off memory usage should require an absurd CPU slowdown. PBKDF2 doesn't have this property, so if you're forced to use it, the standard recommended iteration count is 86000. 50 is a joke.
    - logicallee 11y ago
      so it's not really exponential - if ridiculous amounts of memory somehow became very cheap and available, then it would break it? this is quite different from the exponential properties most encryption has. I would expect "ridiculous amounts of memory" to mean "more bytes than the number of atoms on Earth", that sort of thing. It sounds like rather than these kinds of theoretical limits, they chose much more practical limits - which seems a lot more dangerous and less future-proof, but I guess I'm not an expert.
      - sarciszewski 11y ago
        As attackers get better, we can just up the ante. More rounds, more memory usage, etc. If you're building software in 2016, you want to use one of the following for turning a password into a crypto key: - Argon2 - scrypt - bcrypt PBKDF2 should be your last resort. Don't fall back to a simple hash function.
        logicallee 11y ago
        that makes zero sense. something encrypted in 2001 isn't supposed to magically become plaintext in 2016 because "attackers get better." it's fundamentally not the promise of encryption. (I thought.)
        sarciszewski 11y ago
orthecreedence 11y ago
> Nothing says secure like PBKDF2-SHA1 with 50 rounds. This code is deriving an encryption key and an HMAC key from a master key. The master key is already a random value, so even if you managed to "crack" either one of the derived keys, you wouldn't know it. > or timing attacks on MAC validation Good point, I'll fix that!
- sarciszewski 11y ago
  The correct tool for the key-splitting job is HKDF. If SJCL doesn't offer HKDF, I'll be surprised. It's not hard to implement, however.
  - orthecreedence 11y ago
    Thanks. I researched key splitting when I was building the CBC+HMAC version of the crypto, but HKDF never came up. This is why there are experts (which I do not claim to be). Your feedback on the crypto side of things is really important and well received. I appreciate you taking the time to look through the code.
    - sarciszewski 11y ago
      > This is why there are experts (which I do not claim to be). Heh, humility goes a long way towards becoming an expert. ;) Thanks for taking this feedback well. :) Also, a friend in IRC point out that: https://github.com/turtl/js/blob/master/library/tcrypt.js#L677-L679 https://github.com/turtl/js/blob/master/library/tcrypt.js#L6... Your default iterations here is only 400.

mrmondo 11y ago

"When the standard was written in 2000, the recommended minimum number of iterations was 1000, but the parameter is intended to be increased over time as CPU speeds increase. As of 2005 a Kerberos standard recommended 4096 iterations,[2] Apple iOS 3 used 2000, iOS 4 used 10000,[3] while in 2011 LastPass used 5000 iterations for JavaScript clients and 100000 iterations for server-side hashing" source: https://en.wikipedia.org/wiki/PBKDF2 https://en.wikipedia.org/wiki/PBKDF2 *Edit: Oh.. it's PBKDF1....

sarciszewski 11y ago
Nope, PBKDF1 was a typo.
logicallee 11y ago
how can anyone take anything seriously that requires 1000 iterations. if iterations had an exponential function then the difference between 1000 iterations and 10,000 is ridiculous, like the difference between 16 bit encryption (no such thing, this would be a joke) and 160 bit encryption. But if it's not exponential, then adding thousands of iterations doesn't do much. Maybe instead of 1 day to break it, now it takes 1000 days, or instead of spending $4,000 on CPU time now you need to spend $4M to crack it. Big deal - it's just as broken. So can anyone explain the math here? How can they seriously suggest linearly increasing the number of iterations over time?
- sarciszewski 11y ago
  Attackers can use special hardware (ASICs, for example) to perform a lot of low-memory but CPU-intensive calculations quickly. Modern KDFs emphasize a property called memory-hardenss: It should be reasonably fast on consumer devices, require a reasonable amount of memory, and trading off memory usage should require an absurd CPU slowdown. PBKDF2 doesn't have this property, so if you're forced to use it, the standard recommended iteration count is 86000. 50 is a joke.
  - logicallee 11y ago
    so it's not really exponential - if ridiculous amounts of memory somehow became very cheap and available, then it would break it? this is quite different from the exponential properties most encryption has. I would expect "ridiculous amounts of memory" to mean "more bytes than the number of atoms on Earth", that sort of thing. It sounds like rather than these kinds of theoretical limits, they chose much more practical limits - which seems a lot more dangerous and less future-proof, but I guess I'm not an expert.
    - sarciszewski 11y ago
      As attackers get better, we can just up the ante. More rounds, more memory usage, etc. If you're building software in 2016, you want to use one of the following for turning a password into a crypto key: - Argon2 - scrypt - bcrypt PBKDF2 should be your last resort. Don't fall back to a simple hash function.
      - logicallee 11y ago
        that makes zero sense. something encrypted in 2001 isn't supposed to magically become plaintext in 2016 because "attackers get better." it's fundamentally not the promise of encryption. (I thought.)
        sarciszewski 11y ago

orthecreedence 11y ago

> Nothing says secure like PBKDF2-SHA1 with 50 rounds. This code is deriving an encryption key and an HMAC key from a master key. The master key is already a random value, so even if you managed to "crack" either one of the derived keys, you wouldn't know it. > or timing attacks on MAC validation Good point, I'll fix that!

sarciszewski 11y ago
The correct tool for the key-splitting job is HKDF. If SJCL doesn't offer HKDF, I'll be surprised. It's not hard to implement, however.
- orthecreedence 11y ago
  Thanks. I researched key splitting when I was building the CBC+HMAC version of the crypto, but HKDF never came up. This is why there are experts (which I do not claim to be). Your feedback on the crypto side of things is really important and well received. I appreciate you taking the time to look through the code.
  - sarciszewski 11y ago
    > This is why there are experts (which I do not claim to be). Heh, humility goes a long way towards becoming an expert. ;) Thanks for taking this feedback well. :) Also, a friend in IRC point out that: https://github.com/turtl/js/blob/master/library/tcrypt.js#L677-L679 https://github.com/turtl/js/blob/master/library/tcrypt.js#L6... Your default iterations here is only 400.