Re: [MLS] Proposal: Change AES-GCM to AES-SIV

In response to the questions about implementations, I've quickly 
trawled for libraries supporting AES-SIV: 

[BoringSSL] - Google's port of OpenSSL 

[IntelIPP] - Intel, implemented in ANSI C 

[libaes_siv] - Akamai, implemented in C

[Miscreant] - Go, Rust, C#, Javascript, Python, Ruby 

[siv-mode] - Java, audited by Cure 53

[openssl] - PR, Awaiting second review before release

[AESSIVWrapper] - iOS Obj-C Wrapper

Summary:  all major languages seem to have at least one implementation. That said,
AES-GCM enjoys much wider support. I'm not an implementation person, so I can't 
speak as to whether this is a blocker for considering AES-SIV at all. 

References: 

[Miscreant] https://github.com/miscreant/miscreant

[BoringSSL] https://github.com/google/boringssl/blob/master/include/openssl/aead.h

[IntelIPP] https://software.intel.com/en-us/ipp-crypto-reference-aes-siv-functions

[libaes_siv] https://github.com/dfoxfranke/libaes_siv

[siv-mode] https://github.com/cryptomator/siv-mode

[openssl] https://github.com/openssl/openssl/pull/3540

[AESSIVWrapper] - https://github.com/daresaydigital/AESSIVWrapper

On Wed, 26 Sep 2018 22:30:43 +0100
Dennis Jackson <dennis.jackson@cs.ox.ac.uk> wrote:

> Proposal: Change AES-GCM to AES-SIV
> 
> Rationale: 
> 
> AES-GCM requires a unique nonce for every message, otherwise it
> fails catastrophically by directly leaking the authentication key
> and consequently provides no resistance to active attacks on 
> confidentiality. 
> 
> AES-SIV is a drop in replacement for AES-GCM which significantly
> mitigates the impact of repeated nonces. For a message pair with
> repeated nonces the attacker only learns if the two plaintexts were
> equal. There is no other loss of confidentiality or authenticity. This
> is provably the minimum leakage possible in the event of a repeated
> nonce. 
> 
> Handling nonces is a tricky part of any implementation and easy to get
> wrong in the presence of state loss or concurrency. Failures
> in nonce generation are both catastrophic and subtle. Richard Barnes
> has already improved the specification by moving from explicit to
> implicit nonces which can aid the discovery of faulty implementations.
> However, implicit nonces are not a silver bullet and recent papers
> have uncovered serious nonce reuse issues in both TLS [1] and WPA
> [2]. 
> 
> + AES-SIV significantly mitigates the impact of nonce reuse
> + AES-SIV is a drop in replacement with the same interface as AES-GCM
> + AES-SIV makes use of the same hardware support as AES-GCM
> + AES-SIV has a proof of security [3] and is described in RFC 5297 [4]
> * AES-SIV has reasonable (but not extensive) library support
> (including OpenSSL, BoringSSL, Intel IPP)
> * Despite being over 10 years old, AES-SIV has not seen widespread
>   deployment
> * AES-SIV Encryption is ~70% of the speed of AES-GCM Encryption
>   (Decryption is the same speed as AES-GCM)
> 
> References: 
> 
> [1]
> https://www.usenix.org/system/files/conference/woot16/woot16-paper-bock.pdf
> 
> [2] https://www.krackattacks.com/
> 
> [3] http://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf
> 
> [4] https://datatracker.ietf.org/doc/rfc5297/
> 
> _______________________________________________
> MLS mailing list
> MLS@ietf.org
> https://www.ietf.org/mailman/listinfo/mls

-- 
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC