Add ChaCha20-Poly1305 to CoreFX

[DemiMarie]

Add ChaCha20-Poly1305 to CoreFX's cipher suite. It is a very fast AEAD (significantly faster than AES-GCM except when the latter has hardware support) that is immune to side channel attacks and is relatively easy to implement.

It is included in OpenSSL 1.1 or later, or in libSodium.

[CodesInChaos]

What kind of API should be used for this? ICryptoTransform isn't a good match of authenticated encryption since it has to release data before verifying the MAC, which is a security risk. It doesn't support additional data at all.

[morganbr]

@drbo, are you specifically looking for a stream cipher? I agree with @CodesInChaos that we'd need to design an authenticated stream cipher API surface. My priorities in such an API would be that it:

1. Ensures that authentication actually happens -- we've seen cases where people use ICryptoTransform to decrypt the amount of data they expect and then stop reading before getting to the end of the input
2. Makes it unlikely that users will accidentally fall into key/nonce reuse since that can break stream ciphers very easily
3. Is reasonably usable -- ideally much more so than ICryptoTransform

[DemiMarie]

@morganbr no, I am not specifically looking for a stream cipher.

Rather, I am looking specifically for ChaCha20-Poly1305 (for AEAD) and possibly XSalsa20-Poly1305.

The big advantages of the Salsa20 family of ciphers (which includes ChaCha20 and XSalsa20):

• Designed for secure implementation in software. When AES-NI is not available OpenSSL uses
  an
• Very fast, even in pure-software implementations. On ARM, ChaCha20-Poly1305 is over 3.5 times
  faster than 128-bit AES-GCM.

Nonetheless, a good AEAD interface would be extremely useful, but it is a seperate issue.

[prajaybasu]

Any progress on this yet ?

[bartonjs]

@prajaybasu Nope, sorry. Since AES-GCM works on both Windows (via bcrypt.dll) and Unix (via libcrypto) it will be the framework's first venture into AEAD.

Partly it's a problem of designing an API that creates the pit of success (e.g. forcing that the integrity be checked before letting you see any of the decrypted data) while also allowing for performance (e.g. streaming data out live).

But, even AES-GCM is behind getting the current 1.0 release out the door.

[karelz]

We need API proposal for the algorithm.
Keep in mind that each new algorithm has to receive Microsoft crypto-board approval - we can help get it started, but there is no guarantee about the result.

[tmds]

@stephentoub what does 5.0 mean on this (and other issues)? Is this planned? Or issues considered for 5.0 planning?

[stephentoub]

I bulk moved all api-* to 5.0 a few months back so they could be triaged and then closed, left, or pushed out as appropriate.