4 ms·

I wouldn't say this is bad or anything, but it is focusing on the wrong problem. Block ciphers like AES are the very strongest piece of the puzzle. This is kind

by sdevlin 11y ago

I wouldn't say this is bad or anything, but it is focusing on the wrong problem. Block ciphers like AES are the very strongest piece of the puzzle. This is kind of like putting three huge locks on your front door. It doesn't hurt, but the second and third locks have limited utility. The best attack on this scheme (in a purely offline scenario) is probably just cracking weak passwords, just like it would have been with only one encryption pass. EDIT: One more point. The FAQ says something about plans for a future streaming API. Please do not do this, at least for the decrypt operation. Streaming decryption APIs expose application developers to not-yet-authenticated plaintext. EDIT EDIT: I think it's an API mistake to leave key generation in the hands of the user, especially by using a PBKDF. PBKDFs are a measure of last resort. If you can just generate key material randomly, you should do so.

mckiddy 11y ago
Exactly, this will fail just as fast as a single cipher when your users inevitably use 'password123' for their password.
- mangeletti 11y ago
  This is like saying, "A self driving car is a bad idea, because the user might enter the bottom of the ocean as their destination.".
  - mckiddy 11y ago
    Except this also adds very little benefit. Sure, 3 ciphers might be better than one, but as the top comment said the cipher is already the strongest part of the entire process.
  - me2i81 11y ago
    If the user enters the bottom of the ocean as their destination, it would be bad for a self-driving car to take them there. "The user is an idiot and so we killed him" is not going to be such a great defense in court...
    - mangeletti 11y ago
      In all seriousness, if a man puts a GLOCK 21 in his mouth and pulls the trigger, is it GLOCK that "killed him"? If I take my car and intentionally drive into the ocean, I expect it to continue until the engine dies, and then I do shortly after. Why should machines start prohibiting me from doing stupid things, if I want to do them? I think Isaac Asimov wrote a parable about such a future.
      - sdevlin 11y ago
        None of the mistakes people make in crypto are intentional. We need better interfaces to help them not make those mistakes.
  - sdevlin 11y ago
    There's no a priori need for password-derived key material in a library like this. To require it unilaterally is to introduce a security risk, since people have proven to be poor sources of entropy. I don't really understand the self-driving car analogy. A better analogy would probably be three cars hitched together.
  - tedunangst 11y ago
    This is like saying "adding triple redundant GPS to a self driving car is a bad idea because the GPS is the component least likely to cause you to end up at the bottom of the ocean."
CyberDildonics 11y ago
That's why you do password strengthening, which helps quite a bit.
sarciszewski 11y ago
> I wouldn't say this is bad or anything I would. The idea might not be bad, but the implementation is. They use a pure software AES implementation that, due to its reliance on S-boxes, opens the door for cache-timing attacks. Offending file: https://github.com/keybase/triplesec/blob/master/src/aes.iced https://github.com/keybase/triplesec/blob/master/src/aes.ice... Permalink: https://github.com/keybase/triplesec/blob/bb0b2f449cc28ca402f031486ae3671669daa05c/src/aes.iced https://github.com/keybase/triplesec/blob/bb0b2f449cc28ca402... Issue: https://github.com/keybase/triplesec/issues/47 https://github.com/keybase/triplesec/issues/47 (opened March 17, still collecting dust) Reference: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf AES-NI or bust. > The FAQ says something about plans for a future streaming API. Please do not do this, at least for the decrypt operation. Streaming decryption APIs expose application developers to not-yet-authenticated plaintext. I've written a streaming PoC to encrypt/decrypt file handles in PHP. During the decryption process, it first recalculates the HMAC over the entire file then verifies it with the one stored before decrypting. (Yes, in constant time too.) It's slower than just blindly decrypting, but more trustworthy. Not quite the same as streaming network resources, but I figured that bit of nuance is worth mentioning. The experiment lives here if you're interested in schooling me on some matter I overlooked, though I'm going to significantly rewrite it before I propose it to the project I was PoCing it for: https://github.com/paragonie-scott/php-crypto-stream https://github.com/paragonie-scott/php-crypto-stream (For starters, the actual pull request won't be using CBC.)
- sdevlin 11y ago
  I was mainly commenting on the design. I actually haven't looked at the implementation. Also, I would put AES side channels somewhat low on the list of practical vulnerabilities.
  - sarciszewski 11y ago
    > Also, I would put AES side channels somewhat low on the list of practical vulnerabilities. Sure, but if they're concerned about weaknesses in AES enough to cascade it with other ciphers, ignoring the side-channel inherent to the AES design is pretty silly and indicates a lack of research or foresight. Combine that with no response from their team for threee months after I opened the issue, and I think we can safely conclude that this library is not currently trustworthy. (in b4 "TripleSec Considered Harmful")

by sdevlin 11y ago

mckiddy 11y ago

Exactly, this will fail just as fast as a single cipher when your users inevitably use 'password123' for their password.

mangeletti 11y ago
This is like saying, "A self driving car is a bad idea, because the user might enter the bottom of the ocean as their destination.".
- mckiddy 11y ago
  Except this also adds very little benefit. Sure, 3 ciphers might be better than one, but as the top comment said the cipher is already the strongest part of the entire process.
- me2i81 11y ago
  If the user enters the bottom of the ocean as their destination, it would be bad for a self-driving car to take them there. "The user is an idiot and so we killed him" is not going to be such a great defense in court...
  - mangeletti 11y ago
    In all seriousness, if a man puts a GLOCK 21 in his mouth and pulls the trigger, is it GLOCK that "killed him"? If I take my car and intentionally drive into the ocean, I expect it to continue until the engine dies, and then I do shortly after. Why should machines start prohibiting me from doing stupid things, if I want to do them? I think Isaac Asimov wrote a parable about such a future.
    - sdevlin 11y ago
      None of the mistakes people make in crypto are intentional. We need better interfaces to help them not make those mistakes.
- sdevlin 11y ago
  There's no a priori need for password-derived key material in a library like this. To require it unilaterally is to introduce a security risk, since people have proven to be poor sources of entropy. I don't really understand the self-driving car analogy. A better analogy would probably be three cars hitched together.
- tedunangst 11y ago
  This is like saying "adding triple redundant GPS to a self driving car is a bad idea because the GPS is the component least likely to cause you to end up at the bottom of the ocean."

CyberDildonics 11y ago

That's why you do password strengthening, which helps quite a bit.

sarciszewski 11y ago

> I wouldn't say this is bad or anything I would. The idea might not be bad, but the implementation is. They use a pure software AES implementation that, due to its reliance on S-boxes, opens the door for cache-timing attacks. Offending file: https://github.com/keybase/triplesec/blob/master/src/aes.iced https://github.com/keybase/triplesec/blob/master/src/aes.ice... Permalink: https://github.com/keybase/triplesec/blob/bb0b2f449cc28ca402f031486ae3671669daa05c/src/aes.iced https://github.com/keybase/triplesec/blob/bb0b2f449cc28ca402... Issue: https://github.com/keybase/triplesec/issues/47 https://github.com/keybase/triplesec/issues/47 (opened March 17, still collecting dust) Reference: http://cr.yp.to/antiforgery/cachetiming-20050414.pdf http://cr.yp.to/antiforgery/cachetiming-20050414.pdf AES-NI or bust. > The FAQ says something about plans for a future streaming API. Please do not do this, at least for the decrypt operation. Streaming decryption APIs expose application developers to not-yet-authenticated plaintext. I've written a streaming PoC to encrypt/decrypt file handles in PHP. During the decryption process, it first recalculates the HMAC over the entire file then verifies it with the one stored before decrypting. (Yes, in constant time too.) It's slower than just blindly decrypting, but more trustworthy. Not quite the same as streaming network resources, but I figured that bit of nuance is worth mentioning. The experiment lives here if you're interested in schooling me on some matter I overlooked, though I'm going to significantly rewrite it before I propose it to the project I was PoCing it for: https://github.com/paragonie-scott/php-crypto-stream https://github.com/paragonie-scott/php-crypto-stream (For starters, the actual pull request won't be using CBC.)

sdevlin 11y ago
I was mainly commenting on the design. I actually haven't looked at the implementation. Also, I would put AES side channels somewhat low on the list of practical vulnerabilities.
- sarciszewski 11y ago
  > Also, I would put AES side channels somewhat low on the list of practical vulnerabilities. Sure, but if they're concerned about weaknesses in AES enough to cascade it with other ciphers, ignoring the side-channel inherent to the AES design is pretty silly and indicates a lack of research or foresight. Combine that with no response from their team for threee months after I opened the issue, and I think we can safely conclude that this library is not currently trustworthy. (in b4 "TripleSec Considered Harmful")