
AES-GCM-SIV: AES-GCM with some forgiveness - mzl
https://www.imperialviolet.org/2017/05/14/aesgcmsiv.html
======
zxcmx
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
> _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.

~~~
dsacco
_> 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).

~~~
mikeash
I thought iMessage _was_ implemented as a protocol with end-to-end encryption.
At least Apple claims that it is.

I don't see how security and usability can be opposites. They are in conflict
with each other to an extent, but increasing security doesn't _necessarily_
hurt usability or vice versa. There are many products which have become both
more usable and more secure over time, or which are both more usable and more
secure than their competitors.

~~~
dsacco
_> I thought iMessage was implemented as a protocol with end-to-end
encryption. At least Apple claims that it is._

Sorry, let me be more precise: iMessage is not a true "zero knowledge"
protocol construction - Apple could, _theoretically_ , port your iMessage
history to another iPhone without using your device's private key or iCloud
password. This might be helpful to read:
[https://blog.cryptographyengineering.com/2013/06/26/can-
appl...](https://blog.cryptographyengineering.com/2013/06/26/can-apple-read-
your-imessages/)

 _> I don't see how security and usability can be opposites. They are in
conflict with each other to an extent, but increasing security doesn't
necessarily hurt usability or vice versa. There are many products which have
become both more usable and more secure over time, or which are both more
usable and more secure than their competitors._

Let me try to formalize it a bit. Security is offered through confidentiality,
integrity or authentication (increasingly integrity is just a sub-feature of
authentication). Before you add authentication, a user might have been able to
access their data or account somewhere without needing to log in. But access
control was required, so now they need to enter a password, which requires
password management of some kind.

When you add a security service, what capabilities in the application are now
impossible, or more difficult? Maybe those capabilities were undesirable or
negligible, but they were there; by removing those capabilities you have added
a cost, or a _friction_ in its place. A possible workflow has been diminished,
even if its for good reason.

In practice you can reduce the impact of these quite a lot, i.e. encrypted
messaging doesn't have to be PGP, it can be like iMessage. But fundamentally
security (or cost) and usability have been transacted.

~~~
mikeash
Interesting, so it's "end-to-end" in that the messages are encrypted on one
end and decrypted on the other without being decrypted in between, but nothing
stops Apple from inserting themselves in the middle without our knowledge?

I agree that the two are generally in tension, but I don't think they're
opposites, and they don't always fight. Consider, for example, switching from
a plaintext network protocol to one that uses encryption with an
unauthenticated key exchange. The result isn't particularly secure since it's
vulnerable to a MITM attack, but it's a definite improvement since it shuts
down passive snooping, and it doesn't impact usability at all.

Or consider something like HSTS. You shut down a real avenue of attack and the
user never even sees the difference.

------
snakeanus
There is
[https://competitions.cr.yp.to/round2/hs1sivv2c.pdf](https://competitions.cr.yp.to/round2/hs1sivv2c.pdf)
for SIV on Chacha.

~~~
jedisct1
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.

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

~~~
StavrosK
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.

~~~
kobeya
So it wouldn't work for stream encryption then?

~~~
problems
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
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
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
The author of the linked blog post has a post exactly about this:
[https://www.imperialviolet.org/2014/06/27/streamingencryptio...](https://www.imperialviolet.org/2014/06/27/streamingencryption.html)

(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))

