4 ms·

Reasoning by Lego: A wrong way to think about cryptography

42 points by paragon_init 11y ago

ufo 11y ago
I think the bigger problem is that the crypto primitives we have available do not behave like lego blocks. For example, encryption is useless without authentication on top of it but the API will still let you use AES in CBC mode without authenticating afterwards. If you use a higher-level crypto API like libsodium/NaCl then you can treat functions like lego blocks just fine.
- sarciszewski 11y ago
  Aye. I think cryptography escapes most developers. Especially most PHP developers. I've been talking in #php.security on Freenode with ircmaxell and a few others about making a pluggable high-level PHP library that abstracts all the lego blocks away and just gives a sane interface. (Note: This is mostly ircmaxell's idea, I just offered a draft for the API layout.) For example: $c = new \Crypto\Symmetric('openssl:cipher=aes-128;mode=cbc;hash=sha256'); $k = $c->generateKey(); $cipher = $c->encrypt("Some message", $k); Omitting any of these parameters (e.g. just passing 'openssl:') should have sane, opinionated defaults that prioritize security. Developers will NOT be allowed to use ECB mode. The idea is that it should support multiple "drivers" (openssl, libsodium, possibly a begrudging mcrypt inclusion). PDO : databases :: this idea : cryptography The roadmap looks like this: 1. a PHP implementation/PoC 2. a PECL extension 3. a RFC and pull request to make it part of the PHP 7.1 core We already have password_hash() and password_verify(), there's no reason we can't abstract a typical use-case away from the average PHP developer and prevent them from implementing it themselves, horribly.
fr0styMatt2 11y ago
This one immediately jumped out at me while reading (I'm interested in crypto but when asked about it in a job interview I happily told them that security implementations should be done by someone that knows what they're doing!). Can someone explain this: > Let’s ignore the fact that it’s using MCRYPT_RIJNDAEL_256 (the 256-bit block version of Rijndael, not AES) instead of MCRYPT_RIJNDAEL_128 (real AES), When I look at those enum names I would immediately think that MCRYPT_RIJNDAEL_256 was stronger than MCRYPT_RIJNDAEL_128. The naming strongly suggests the same algorithm but _256 being stronger. Is this part of an API design issue?
- sarciszewski 11y ago
  Yes, mcrypt is terrible. https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...
- tptacek 11y ago
  The 32 byte block option is strictly speaking more secure.
  - some_furry 11y ago
    Are you saying that just because it operates on larger blocks, or do you know something else that I don't?
    - tptacek 11y ago
      All things being equal, larger blocks are better.
  - sarciszewski 11y ago
    Have you (or any of your colleagues) studied Rijndael-256? I'd be interested in seeing your analyses and conclusions if you have.
    - tptacek 11y ago
      Studied in what sense? It's one of the best studied block ciphers in the world. I wouldn't go out of my way to use it, but I flinched a little when this report suggested its use was a vulnerability. I don't think 32 byte blocks are much better than 16 byte blocks, but 16 byte blocks are much, much better than 8 byte blocks, and so I feel like I should be consistent.
      - earthrise 11y ago
        I usually consider this a "vulnerability" in the sense that the author probably intended to use AES and so they may have misunderstood the mcrypt API. Most importantly, they might have wanted AES-256 and missed the fact that mcrypt selects the key size based on the size of key you give it. That does not appear to be the case this time, however, since the page acknowledges (in an update) "256 bit block" and the fact that it isn't AES. So I should probably make note of that in the CryptoFails post. I'm unsure how well the analysis of AES (and the attacks against it) carry over to Rijndael-256, so I'd be hesitant to actually recommend it without asking a cryptographer... but, like you, I'd be very surprised if it was a source of vulnerability itself.
nrser 11y ago
the best part of security is that fat meaty area in the middle of the venn for people that don't understand it and don't understand that they don't.

42 points by paragon_init 11y ago

ufo 11y ago

I think the bigger problem is that the crypto primitives we have available do not behave like lego blocks. For example, encryption is useless without authentication on top of it but the API will still let you use AES in CBC mode without authenticating afterwards. If you use a higher-level crypto API like libsodium/NaCl then you can treat functions like lego blocks just fine.

sarciszewski 11y ago
Aye. I think cryptography escapes most developers. Especially most PHP developers. I've been talking in #php.security on Freenode with ircmaxell and a few others about making a pluggable high-level PHP library that abstracts all the lego blocks away and just gives a sane interface. (Note: This is mostly ircmaxell's idea, I just offered a draft for the API layout.) For example: $c = new \Crypto\Symmetric('openssl:cipher=aes-128;mode=cbc;hash=sha256'); $k = $c->generateKey(); $cipher = $c->encrypt("Some message", $k); Omitting any of these parameters (e.g. just passing 'openssl:') should have sane, opinionated defaults that prioritize security. Developers will NOT be allowed to use ECB mode. The idea is that it should support multiple "drivers" (openssl, libsodium, possibly a begrudging mcrypt inclusion). PDO : databases :: this idea : cryptography The roadmap looks like this: 1. a PHP implementation/PoC 2. a PECL extension 3. a RFC and pull request to make it part of the PHP 7.1 core We already have password_hash() and password_verify(), there's no reason we can't abstract a typical use-case away from the average PHP developer and prevent them from implementing it themselves, horribly.

fr0styMatt2 11y ago

This one immediately jumped out at me while reading (I'm interested in crypto but when asked about it in a job interview I happily told them that security implementations should be done by someone that knows what they're doing!). Can someone explain this: > Let’s ignore the fact that it’s using MCRYPT_RIJNDAEL_256 (the 256-bit block version of Rijndael, not AES) instead of MCRYPT_RIJNDAEL_128 (real AES), When I look at those enum names I would immediately think that MCRYPT_RIJNDAEL_256 was stronger than MCRYPT_RIJNDAEL_128. The naming strongly suggests the same algorithm but _256 being stronger. Is this part of an API design issue?

sarciszewski 11y ago
Yes, mcrypt is terrible. https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...
tptacek 11y ago
The 32 byte block option is strictly speaking more secure.
- some_furry 11y ago
  Are you saying that just because it operates on larger blocks, or do you know something else that I don't?
  - tptacek 11y ago
    All things being equal, larger blocks are better.
- sarciszewski 11y ago
  Have you (or any of your colleagues) studied Rijndael-256? I'd be interested in seeing your analyses and conclusions if you have.
  - tptacek 11y ago
    Studied in what sense? It's one of the best studied block ciphers in the world. I wouldn't go out of my way to use it, but I flinched a little when this report suggested its use was a vulnerability. I don't think 32 byte blocks are much better than 16 byte blocks, but 16 byte blocks are much, much better than 8 byte blocks, and so I feel like I should be consistent.
    - earthrise 11y ago
      I usually consider this a "vulnerability" in the sense that the author probably intended to use AES and so they may have misunderstood the mcrypt API. Most importantly, they might have wanted AES-256 and missed the fact that mcrypt selects the key size based on the size of key you give it. That does not appear to be the case this time, however, since the page acknowledges (in an update) "256 bit block" and the fact that it isn't AES. So I should probably make note of that in the CryptoFails post. I'm unsure how well the analysis of AES (and the attacks against it) carry over to Rijndael-256, so I'd be hesitant to actually recommend it without asking a cryptographer... but, like you, I'd be very surprised if it was a source of vulnerability itself.

nrser 11y ago

the best part of security is that fat meaty area in the middle of the venn for people that don't understand it and don't understand that they don't.