Tony Arcieri

Note: this PR doesn't yet impl the `Signer` or `Verifier` traits, but should for this PR to actually be useful.

~~Another note: the MSRV bump isn't strictly necessary and can be worked around by renaming `serde` to `serde_crate`, although I was having trouble making that work with custom derive, which...

This is basically good to go with one caveat: I've left the `SigningKey::sign` and `VerificationKey::verify` inherent methods, even though the `Signer` and `Verifier` traits also define `Signer::sign` and `Verifier::verify` methods....

We also just shipped `ed25519` v2.0, although it's only been out for 5 days and doesn't have any released transitive dependencies or a large number of downloads, so I suppose...

I yanked `ed25519` v2.0.0. So far we haven't had any complaints. Here's a PR to switch to infallible parsing: https://github.com/RustCrypto/signatures/pull/623

This is ready for review. The `ed25519` v2.0.1+ (with v2.0.0 yanked) API now supports infallible signature parsing. I've also changed the argument ordering for `VerificationKey::verify` to match the `signature` crate....

You might also consider [evercrypt-rust](https://github.com/franziskuskiefer/evercrypt-rust) which provides an FFI wrapper to formally verified C implementations.

Upon examining Tink it appears to use the original Rogaway paper definition of STREAM, which is definitely something worth supporting. I can and should add support for it to https://github.com/RustCrypto/traits/pull/436,...

FYI, the new `stream` module is now available: https://docs.rs/aead/0.4.1/aead/stream/index.html The `StreamBE32` type should implement the particular formulation of STREAM used by Tink: https://docs.rs/aead/0.4.1/aead/stream/struct.StreamBE32.html

@Cyril-sf didn't you add a `allow-same-origin` polyfill that causes unsupported browsers to break if they can't sandbox properly?