6 ms·

Very roughly, this is using a hash of the data mixed into the IV (so IV+key re-use means same plaintext always gives same ciphertext, but not catastrophic fail

by zxcmx 9y ago

Very roughly, this is using a hash of the data mixed into the IV (so IV+key re-use means same plaintext always gives same ciphertext, but not catastrophic fail like re-using IV & key in GCM). I wish the library support were better (e.g. common java libs), and that it would get added to approved cipher lists from various govt. bodies. I'm not across how this really happens so no idea if it will, but I really hope it does. I like how hard to get wrong SIV mode is, and how, as a primitive, it lines up quite well with how developers think encryption works before they go do coursera or the matasano challenges or whatever. In my experience developers don't really get better (as an entire class of people) at security, most of the improvements in security I've seen, I attribute to better APIs and outsourcing of low level infrastructure to highly resourced entities. Yeah so it's a bit slower and your data has to fit in memory, but within these application caveats I see no reason not to universally prefer automatic IV modes. You still have to care that its deterministic in a lot of applications but thats not too hard to communicate.

bostik 9y ago
> In my experience developers don't really get better (as a cohort) at security, most of the improvements in security I've seen are due to better APIs and outsourcing of low level infrastructure to highly resourced entities. And there is nothing wrong with that, IMO. (Disclosure: I've been immersed in the security field since early 1990's.) Security is complex - stupefiengly complex. No other field in all of CS has to worry about catastrophic failure modes that can be both subtle and completely invisible. Unless you have teams(!) of professionals working on security full time, you have only marginally better chances of survical than a snowball in the tropics. Add the fact that most of the time, security is seen as a lack of something. Mostly usability. People who have work to do will find ways to subvert any and all security measures if doing so makes their life easier. We must accept the fact: it is impossible to sell security. But it IS possible to sell convenience. Make the secure option more convenient than the insecure one, and you can't keep people away. In other words: improve the APIs. Make the underlying infrastructure secure and provide a convenient way of using it properly. Don't try to fight human nature. Make use of it instead.
- deleted 9y ago
  [deleted]
- zxcmx 9y ago
  Agree... there's a good argument to be made that the "right" primitive looks more like crypto_box than AES anything and I agree with that too. Sometimes you want things a bit more low level (i.e, that don't dictate s11n) though.
  - lann 9y ago
    To be pedantically correct: crypto_box and AES aren't mutually exclusive, and in fact AES is listed in crypto_box's "Alternate primitives".
    - dchest 9y ago
      What an incorrect correction! The commenter's point was: instead of considering a block cipher (AES) as a primitive, developers should consider a higher-level authenticated encryption construction, crypto_box, as a primitive. What you're talking about is a different implementation of crypto_box, which uses AES-GCM with tag included along with ciphertext.
- baby 9y ago
  That what was done with http/2. Want to use it? Gotta use TLS as well.
  - EwanToo 9y ago
    This is the kind of thing that makes security so hard HTTP/2 does not enforce TLS, only the browser implementations do. https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption
- dsacco 9y ago
  > Make the secure option more convenient than the insecure one, and you can't keep people away. Can you define convenient? Do you mean convenient from a usability perspective, or convenient from a risk/financial consequence perspective? I would assume you're using the first definition if you just leave it undefined. But strictly speaking, convenience and security are inherently at odds under the first definition; as stated I don't find that this approach generally works. Security features don't really augment usability so much as they trade off some of it - at best, if you were to make the functionality incredibly seamless and abstract away much or all of the decision making, I suppose you could make secure software as usable as insecure software, but it's not straightforward to design secure software to be as enjoyable to use as insecure software. If we take the example of iMessage: iMessage's security features do not make it intrinsically more or less usable in a general sense; the usability features are those that differentiate it from SMS. Apple happily baked strong cryptography into the protocol as well. An iMessage with the usability features but without the strong cryptosystem would be as useful, and users wouldn't generally be aware of a difference (in fact, it would technically be faster, so in that sense it would more usable). We can't add any further significant security services to iMessage without meaningfully reducing its usability. If iMessage were implemented as a protocol with end-to-end encryption, it would inherently be less usable due to key management and analytics costs on the client-side. This is why I take the position that security and usability are diametric opposites in software design. I've never observed software where this is not the case, unless you contrive the definition of "usability" to mean something like, "the user is hacked less, so they can use the application more" (and I've seen people apply this kind of thinking).
DamonHD 9y ago
Ah, good. We are using AES-GCM for our IoT devices, with counters maintained very carefully in EEPROM, with mechanisms to detect/repair failing counters (eg powered off at just the wrong moment). It would be nice to be able to be a little less careful, and also we're likely moving to an MCU without onboard byte-writeable EEPROM (ie page-write Flash with 1/10th the endurance), and this approach may make that less painful.
- tptacek 9y ago
  Another problem with GCM is that GHASH is hard to compute safely without hardware support. Modern Intel CPUs have a CLMUL instruction that makes it straightforward and fast to compute without needing table lookups, but IOT devices might not have PCLMULQDQ or an equivalent available.
  - DamonHD 9y ago
    We have an implementation that seems to be acceptably fast and small on (8-bit) AVR: https://github.com/opentrv/OTAESGCM https://github.com/opentrv/OTAESGCM (It also compiles and runs on our x64 machines, Linux and macOS.)
    - tptacek 9y ago
      That's unoptimized GCM, but you might not be pushing enough traffic for it to matter; also note that you're using a vanilla software s-box driven AES, which is itself a cache timing risk. My point is just: there are reasons beyond nonce misuse safety to avoid GCM, especially on IOT devices.
      - DamonHD 9y ago
        Please point me to a few more. AES-GCM seemed the best available choice for us, after much discussion, and some scrutiny from third parties. I hear you on timing issues: we may work on those, though when it comes to AVR there is no cache! B^>

by zxcmx 9y ago

bostik 9y ago

> In my experience developers don't really get better (as a cohort) at security, most of the improvements in security I've seen are due to better APIs and outsourcing of low level infrastructure to highly resourced entities. And there is nothing wrong with that, IMO. (Disclosure: I've been immersed in the security field since early 1990's.) Security is complex - stupefiengly complex. No other field in all of CS has to worry about catastrophic failure modes that can be both subtle and completely invisible. Unless you have teams(!) of professionals working on security full time, you have only marginally better chances of survical than a snowball in the tropics. Add the fact that most of the time, security is seen as a lack of something. Mostly usability. People who have work to do will find ways to subvert any and all security measures if doing so makes their life easier. We must accept the fact: it is impossible to sell security. But it IS possible to sell convenience. Make the secure option more convenient than the insecure one, and you can't keep people away. In other words: improve the APIs. Make the underlying infrastructure secure and provide a convenient way of using it properly. Don't try to fight human nature. Make use of it instead.

deleted 9y ago
[deleted]
zxcmx 9y ago
Agree... there's a good argument to be made that the "right" primitive looks more like crypto_box than AES anything and I agree with that too. Sometimes you want things a bit more low level (i.e, that don't dictate s11n) though.
- lann 9y ago
  To be pedantically correct: crypto_box and AES aren't mutually exclusive, and in fact AES is listed in crypto_box's "Alternate primitives".
  - dchest 9y ago
    What an incorrect correction! The commenter's point was: instead of considering a block cipher (AES) as a primitive, developers should consider a higher-level authenticated encryption construction, crypto_box, as a primitive. What you're talking about is a different implementation of crypto_box, which uses AES-GCM with tag included along with ciphertext.
baby 9y ago
That what was done with http/2. Want to use it? Gotta use TLS as well.
- EwanToo 9y ago
  This is the kind of thing that makes security so hard HTTP/2 does not enforce TLS, only the browser implementations do. https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption
dsacco 9y ago
> Make the secure option more convenient than the insecure one, and you can't keep people away. Can you define convenient? Do you mean convenient from a usability perspective, or convenient from a risk/financial consequence perspective? I would assume you're using the first definition if you just leave it undefined. But strictly speaking, convenience and security are inherently at odds under the first definition; as stated I don't find that this approach generally works. Security features don't really augment usability so much as they trade off some of it - at best, if you were to make the functionality incredibly seamless and abstract away much or all of the decision making, I suppose you could make secure software as usable as insecure software, but it's not straightforward to design secure software to be as enjoyable to use as insecure software. If we take the example of iMessage: iMessage's security features do not make it intrinsically more or less usable in a general sense; the usability features are those that differentiate it from SMS. Apple happily baked strong cryptography into the protocol as well. An iMessage with the usability features but without the strong cryptosystem would be as useful, and users wouldn't generally be aware of a difference (in fact, it would technically be faster, so in that sense it would more usable). We can't add any further significant security services to iMessage without meaningfully reducing its usability. If iMessage were implemented as a protocol with end-to-end encryption, it would inherently be less usable due to key management and analytics costs on the client-side. This is why I take the position that security and usability are diametric opposites in software design. I've never observed software where this is not the case, unless you contrive the definition of "usability" to mean something like, "the user is hacked less, so they can use the application more" (and I've seen people apply this kind of thinking).

DamonHD 9y ago

Ah, good. We are using AES-GCM for our IoT devices, with counters maintained very carefully in EEPROM, with mechanisms to detect/repair failing counters (eg powered off at just the wrong moment). It would be nice to be able to be a little less careful, and also we're likely moving to an MCU without onboard byte-writeable EEPROM (ie page-write Flash with 1/10th the endurance), and this approach may make that less painful.

tptacek 9y ago
Another problem with GCM is that GHASH is hard to compute safely without hardware support. Modern Intel CPUs have a CLMUL instruction that makes it straightforward and fast to compute without needing table lookups, but IOT devices might not have PCLMULQDQ or an equivalent available.
- DamonHD 9y ago
  We have an implementation that seems to be acceptably fast and small on (8-bit) AVR: https://github.com/opentrv/OTAESGCM https://github.com/opentrv/OTAESGCM (It also compiles and runs on our x64 machines, Linux and macOS.)
  - tptacek 9y ago
    That's unoptimized GCM, but you might not be pushing enough traffic for it to matter; also note that you're using a vanilla software s-box driven AES, which is itself a cache timing risk. My point is just: there are reasons beyond nonce misuse safety to avoid GCM, especially on IOT devices.
    - DamonHD 9y ago
      Please point me to a few more. AES-GCM seemed the best available choice for us, after much discussion, and some scrutiny from third parties. I hear you on timing issues: we may work on those, though when it comes to AVR there is no cache! B^>