Switch to AES-GCM-SIV for encryption in the store?

[emschwartz]

Suggested by @tarcieri in https://github.com/interledger-rs/interledger-rs/pull/245#discussion_r321321444.

This would be a breaking change so it would be good to decide sooner rather than later whether we want to make this change.

@tarcieri is miscreant ready to use for this?

@gakonst we should also move the encryption/decryption out of the store and into the node if possible. We could open a separate issue to track that or include it with this change

[tarcieri]

@emschwartz you can use Miscreant for AES-SIV (RFC 5297) and I'd consider that implementation fairly robust.

I've been working on implementing AES-GCM-SIV (which will be available in a standalone aes-gcm-siv crate), and have implemented POLYVAL which is the universal hash function its MAC is built on: https://github.com/RustCrypto/universal-hashes/tree/master/polyval

I'd consider any such forthcoming implementation bleeding edge for awhile though.

[emschwartz]

How does AES-SIV compare to AES-GCM-SIV?

[tarcieri]

They have roughly equivalent security properties. AES-GCM-SIV provides "beyond birthday bound" security by deriving a unique keys for each message. As of the final version, it provides good security bounds under nonce reuse, while when used under the birthday bound AES-SIV leaks nothing but message equivalence under nonce reuse.

AES-SIV is over twice as slow for short messages, and significantly slower for long messages as AES-CMAC isn't parallelizable. AES-GCM-SIV, when properly optimized, is ~30% slower than AES-GCM for encryption, and vanishingly faster than AES-GCM for decryption (due to the use of POLYVAL).

Either are suitable for deterministic "keywrap" use, where a uniformly random key is encrypted without a nonce, shortening the message payload in cases where you may have otherwise used a random nonce. This sort of use case is why AES-GCM-SIV was originally developed (e.g. source-address tokens in QUIC, or session tokens in TLS). Ideally these keys are randomly generated and encrypted, which sidesteps the issue of leaking message equivalence as you won't ever have equivalent messages since they're randomly generated. If you're encrypting an existing key, as opposed to a randomly generated one, make sure it's for a use case where deterministic encryption is desirable and message equivalence isn't helpful to an attacker, like "tokenization" .

[gakonst]

@gakonst we should also move the encryption/decryption out of the store and into the node if possible. We could open a separate issue to track that or include it with this change

This will be done as part of #195.

[emschwartz]

@tarcieri How much value does nonce reuse resistance add if we are in a context where we control the creation of nonces and always use a random nonce generated by ring? It seems like such resistance would be more valuable in contexts where you might have different implementations of a protocol and don't control whether all the implementations do nonce generation correctly.

[tarcieri]

AES-SIV was originally created for the keywrap use case, which it sounds like is what you're doing. Its big advantage there is no nonce is required, which saves space.

If you don't care about that, you can do whatever you want, although personally I'm not a fan of using AES-GCM in combination with random 96-bit nonces.

[emschwartz]

Ah good point, that makes sense

[emschwartz]

We should make a decision on this before #557 is finalized

[tarcieri]

Note the relevant crate is here: https://github.com/RustCrypto/AEADs/tree/master/aes-gcm-siv

There may be a security audit happening soon too.