4 ms·

Nonce-exposing high-level crypto APIs are flawed by design. Most developers believe that they need low-level crypto APIs - in fact they get a kick out of coding

Nonce-exposing high-level crypto APIs are flawed by design. Most developers believe that they need low-level crypto APIs - in fact they get a kick out of coding against low-level crypto APIs. This is a dangerous fallacy/hubris. Most developers, in fact, should never touch low-level crypto APIs, and should only use high-level crypto APIs (or not touch crypto at all, which would make the digital world a safer place). SecurityDriven.Inferno library is nonce-misuse-resistant by design (http://securitydriven.net/inferno/ http://securitydriven.net/inferno/).

KMag 10y ago
Thanks for the link! I was expecting something not well thought out, but the front page has a good answer to "Why not NaCl?" ... the short answer is that Inferno is a bit more conservative with choice of algorithms. My main criticism would be that it supports AES256-CBC-HMAC. Encrypt-then-MAC should protect against CBC padding oracles, but CTS mode instead of CBC mode would be more conservative. I understand using CBC instead of CTR mode if you're afraid you might possibly have a flaw that reuses nonces (CBC and CTS modes leak less information than CTR if you have a nonce reuse bug). CTS mode is a slight tweak on CBC mode that modifies the final two blocks in a way that makes it immune to padding oracle attacks. Encrypt-then-MAC should also protect against padding oracle attacks, but CTS mode fits better with the belt-and-suspenders philosophy of Inferno.
- tptacek 10y ago
  Encrypt-than-MAC precludes padding oracle attacks, and if you're not checking MACs, you have bigger problems than padding oracles, so I do not understand what the win would be from CTS --- which is itself little-used, and something I mostly associate with bad disk cryptography.
  - KMag 10y ago
    You're much more qualified than I am, but I was talking about cases where there are bugs in the MAC layer. For instance, t's possible that the constant-time comparison code is well tested on a processor with constant time comparison of a 64-bit register with zero, but ends up being run on some oddball ultra-low power processor that uses one cycle for each leading zero byte in the register, or something. Using CBC potentially allows an attacker to leverage a timing attack against the MAC into a plaintext disclosure via padding oracle. Granted, this scenario requires multiple cascading bugs, but that's kind of the point of Inferno. In general, one is well advised to use the most well-tested and standard algorithms, but CTS is very close to CBC. Have you specifically seen any CTS implementation bugs?

KMag 10y ago

Thanks for the link! I was expecting something not well thought out, but the front page has a good answer to "Why not NaCl?" ... the short answer is that Inferno is a bit more conservative with choice of algorithms. My main criticism would be that it supports AES256-CBC-HMAC. Encrypt-then-MAC should protect against CBC padding oracles, but CTS mode instead of CBC mode would be more conservative. I understand using CBC instead of CTR mode if you're afraid you might possibly have a flaw that reuses nonces (CBC and CTS modes leak less information than CTR if you have a nonce reuse bug). CTS mode is a slight tweak on CBC mode that modifies the final two blocks in a way that makes it immune to padding oracle attacks. Encrypt-then-MAC should also protect against padding oracle attacks, but CTS mode fits better with the belt-and-suspenders philosophy of Inferno.

tptacek 10y ago
Encrypt-than-MAC precludes padding oracle attacks, and if you're not checking MACs, you have bigger problems than padding oracles, so I do not understand what the win would be from CTS --- which is itself little-used, and something I mostly associate with bad disk cryptography.
- KMag 10y ago
  You're much more qualified than I am, but I was talking about cases where there are bugs in the MAC layer. For instance, t's possible that the constant-time comparison code is well tested on a processor with constant time comparison of a 64-bit register with zero, but ends up being run on some oddball ultra-low power processor that uses one cycle for each leading zero byte in the register, or something. Using CBC potentially allows an attacker to leverage a timing attack against the MAC into a plaintext disclosure via padding oracle. Granted, this scenario requires multiple cascading bugs, but that's kind of the point of Inferno. In general, one is well advised to use the most well-tested and standard algorithms, but CTS is very close to CBC. Have you specifically seen any CTS implementation bugs?