aead: automatic nonce management

[tarcieri]

The aead crate presently leaves nonces as a concern to the end user.

It would be better to support a set of nonce management strategies, e.g. sequential nonces for AeadMut, or automatically generated random nonces, as opposed to the current explicit nonce API.

I think it's pretty important to do this in an unobtrusive way, as many protocol implementations will still want/benefit from an explicit nonce-based API.

[burdges]

Could this be generic wrappers? Or some ciphers provide their own bespoke modes?

In this vein, could we handle the Aead* and AeadMut* distinction with one trait that we implement only on borrows, RefCell<..>s, etc.? It's makes expressing bounds tricky, but you could propagate the mutability generically I think. I ask because a managing nonces would change mutability sometimes, so if wrappers do not suffice, then maybe being generic over mutability helps.

[tarcieri]

Definitely an approach to consider. It's how I've implemented STREAM, as it were.

[tarcieri]

PR which generically implements the STREAM construction here: #436.

I would say that suffices to close this PR when it lands.

[tarcieri]

STREAM has landed! Closing this issue.