Steffen Jaeckel

I'm reopening this so we can re-work as proposed.

I haven't looked at that draft yet but this PR implements the "predecessor"

I've read a bit through the ML and I think we should wait until the RFC is finished to prevent something like #256.

Okay I played a bit with the implementation and I'm going to add an incremental `add_AD()` function. Also there should be a `siv_memory()` function which has to support multiple AD's...

> ust FYI - there is a bunch of AES-GCM-SIV test vectors in wycheproof test suite thanks, but they don't help me now as this is only AES-SIV :) I...

I think it makes sense to go with standardized solutions for now instead of spending effort on proposals. If it doesn't have an RFC or other freely available specification (i.e....

They have an RFC -- yes I'm aware the RFC's are only informational and from the IRTF/CFRG, not IETF -- but I call this usually standardized. Or am I wrong...

> I would like to note that Salsa20, XSalsa20 and ChaCha20 are all different ciphers. XSalsa20 is missing but the two others are already in the latest develop branch. Btw....

SIV can be ticked as soon as #319 is finished

@LightBit if Salsa20 can easily be turned into XSalsa20 at runtime, so both could use the same basis, I'm pro extension. Otherwise we'd have to have a look what's best.