6 ms·

AES-GCM-SIV: AES-GCM with some forgiveness

88 points by mzl 9y ago

StavrosK 9y ago
That's very interesting, is it possible to go into moderate detail for the layman about how the SIV mode works?
- StavrosK 9y ago
  To answer my own question, this is a good resource: https://www.lvh.io/posts/nonce-misuse-resistance-101.html https://www.lvh.io/posts/nonce-misuse-resistance-101.html In summary, it makes the nonce a function of the message as well, so you always get the same nonce for the same message. Presumably, the attacker only sees duplicate messages rather than plaintext because XORing a message with itself yields zero. This is one of the things that make you ask "why didn't I think of that?" when you hear of them, and I think that's generally the mark of an ingenious idea.
  - therein 9y ago
    I think the most ingenious implication of what you're describing is that as a side effect, it is therefore guaranteed that no two distinct message will have the same nonce.
    - StavrosK 9y ago
      I think that's the point, not a side effect, though. It only seems to prevent nonce reuse, not collisions for small nonce lengths, but I guess that's what they set out to fix, as it's the more common problem. I guess the reasoning went something like: "How do we prevent reusing the same nonce for two different messages? XOR a hash of the message with the nonce" (I'm not sure this is actually how it works, I haven't looked). Obvious in retrospect, like all great ideas.
  - kobeya 9y ago
    So it wouldn't work for stream encryption then?
    - problems 9y ago
      Depends how your stream encryption is done and what you mean by stream encryption. - If you mean encryption of messages using a stream cipher, generally a single IV is used per message so it could be used there. - If you mean encryption of a stream of data, well, if you're using a block cipher to encrypt a stream of data, this indeed could be used as a block cipher inherently creates blocks in the data every X bits. - However, if you're encrypting a stream of data using a stream cipher it is indeed impossible as all data in the stream isn't known when encryption begins.
      - kobeya 9y ago
        I mean encryption of data as it is generated, in a single pass. This entire message is not known, so unless I am misunderstanding, it is not possible to do per-message deterministic nonce generation.
        dom0 9y ago
        Generally speaking, streaming AEAD is discouraged on an API level, because it incentivises using unauthenticated intermediate decryption results. Thus, block the data into reasonably sized blocks. Also, yes.
        dchest 9y ago
        The author of the linked blog post has a post exactly about this: https://www.imperialviolet.org/2014/06/27/streamingencryption.html https://www.imperialviolet.org/2014/06/27/streamingencryptio... (I defined and implemented a variant of Adam's idea with NaCl secretboxes: https://github.com/dchest/nacl-stream-js https://github.com/dchest/nacl-stream-js)
    - tptacek 9y ago
      No: you can't use SIV "online".
  - stouset 9y ago
    The ideas behind SIV are pretty straightforward, and I don't suspect many in the field think it's not an obvious idea. The hard work is in finding a way to build a mode that minimizes the downsides as much as possible (so it can be used widely) and in proving that the construct doesn't violate any expectations or guarantees of the mode it's replacing. A lot of cryptography required a stroke of brilliance to come up with an idea and see it through. AES-GCM-SIV just required putting in the hard, tedious work (this is very much not meant to undersell the effort involved, just to emphasize that the hard part here was labor, not ideas).
  - dsacco 9y ago
    > This is one of the things that make you ask "why didn't I think of that?" when you hear of them, and I think that's generally the mark of an ingenious idea. The trapdoor function of genius: ideas which are very difficult to identify, but very easy to recognize.
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
snakeanus 9y ago
There is https://competitions.cr.yp.to/round2/hs1sivv2c.pdf https://competitions.cr.yp.to/round2/hs1sivv2c.pdf for SIV on Chacha.
- tptacek 9y ago
  HS1-SIV is out of the running for CAESAR now, but you can get a list of CAESAR round 3 candidates, many of which have NMR properties, here: https://competitions.cr.yp.to/caesar-submissions.html https://competitions.cr.yp.to/caesar-submissions.html
- jedisct1 9y ago
  Which didn't pass the 3rd round of the CAESAR competition. But the same idea can still be applied to ChaCha. See https://github.com/jedisct1/libhydrogen/wiki https://github.com/jedisct1/libhydrogen/wiki and https://github.com/codahale/xsalsa20poly1305 https://github.com/codahale/xsalsa20poly1305 for example.

88 points by mzl 9y ago

StavrosK 9y ago

That's very interesting, is it possible to go into moderate detail for the layman about how the SIV mode works?

StavrosK 9y ago
To answer my own question, this is a good resource: https://www.lvh.io/posts/nonce-misuse-resistance-101.html https://www.lvh.io/posts/nonce-misuse-resistance-101.html In summary, it makes the nonce a function of the message as well, so you always get the same nonce for the same message. Presumably, the attacker only sees duplicate messages rather than plaintext because XORing a message with itself yields zero. This is one of the things that make you ask "why didn't I think of that?" when you hear of them, and I think that's generally the mark of an ingenious idea.
- therein 9y ago
  I think the most ingenious implication of what you're describing is that as a side effect, it is therefore guaranteed that no two distinct message will have the same nonce.
  - StavrosK 9y ago
    I think that's the point, not a side effect, though. It only seems to prevent nonce reuse, not collisions for small nonce lengths, but I guess that's what they set out to fix, as it's the more common problem. I guess the reasoning went something like: "How do we prevent reusing the same nonce for two different messages? XOR a hash of the message with the nonce" (I'm not sure this is actually how it works, I haven't looked). Obvious in retrospect, like all great ideas.
- kobeya 9y ago
  So it wouldn't work for stream encryption then?
  - problems 9y ago
    Depends how your stream encryption is done and what you mean by stream encryption. - If you mean encryption of messages using a stream cipher, generally a single IV is used per message so it could be used there. - If you mean encryption of a stream of data, well, if you're using a block cipher to encrypt a stream of data, this indeed could be used as a block cipher inherently creates blocks in the data every X bits. - However, if you're encrypting a stream of data using a stream cipher it is indeed impossible as all data in the stream isn't known when encryption begins.
    - kobeya 9y ago
      I mean encryption of data as it is generated, in a single pass. This entire message is not known, so unless I am misunderstanding, it is not possible to do per-message deterministic nonce generation.
      - dom0 9y ago
        Generally speaking, streaming AEAD is discouraged on an API level, because it incentivises using unauthenticated intermediate decryption results. Thus, block the data into reasonably sized blocks. Also, yes.
        dchest 9y ago
        The author of the linked blog post has a post exactly about this: https://www.imperialviolet.org/2014/06/27/streamingencryption.html https://www.imperialviolet.org/2014/06/27/streamingencryptio... (I defined and implemented a variant of Adam's idea with NaCl secretboxes: https://github.com/dchest/nacl-stream-js https://github.com/dchest/nacl-stream-js)
  - tptacek 9y ago
    No: you can't use SIV "online".
- stouset 9y ago
  The ideas behind SIV are pretty straightforward, and I don't suspect many in the field think it's not an obvious idea. The hard work is in finding a way to build a mode that minimizes the downsides as much as possible (so it can be used widely) and in proving that the construct doesn't violate any expectations or guarantees of the mode it's replacing. A lot of cryptography required a stroke of brilliance to come up with an idea and see it through. AES-GCM-SIV just required putting in the hard, tedious work (this is very much not meant to undersell the effort involved, just to emphasize that the hard part here was labor, not ideas).
- dsacco 9y ago
  > This is one of the things that make you ask "why didn't I think of that?" when you hear of them, and I think that's generally the mark of an ingenious idea. The trapdoor function of genius: ideas which are very difficult to identify, but very easy to recognize.

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

snakeanus 9y ago

There is https://competitions.cr.yp.to/round2/hs1sivv2c.pdf https://competitions.cr.yp.to/round2/hs1sivv2c.pdf for SIV on Chacha.

tptacek 9y ago
HS1-SIV is out of the running for CAESAR now, but you can get a list of CAESAR round 3 candidates, many of which have NMR properties, here: https://competitions.cr.yp.to/caesar-submissions.html https://competitions.cr.yp.to/caesar-submissions.html
jedisct1 9y ago
Which didn't pass the 3rd round of the CAESAR competition. But the same idea can still be applied to ChaCha. See https://github.com/jedisct1/libhydrogen/wiki https://github.com/jedisct1/libhydrogen/wiki and https://github.com/codahale/xsalsa20poly1305 https://github.com/codahale/xsalsa20poly1305 for example.