New crate versions

[newpavlov]

Migrating to 2018 edition is a long overdue and since it's a good chance to introduce breaking changes, I propose to use this issue to discuss them. Right now I have the following list of changes:

• Migrate to 2018 edition and bump MSRV to 1.36 1.41 (needed for generic-array v0.14)
• Update generic-array to v0.13 v0.14.
• Release crypto-mac v0.8 which uses subtle v2. (see Release a 0.8.0 version? #35)
• Rename crypto_mac::Mac::input and digest::Digest::input methods to update.
• Rename digest::Input to digest::Update.
• Remove digest::Reset trait in favor of reworked FixedResult trait. See this comment.
• Deprecate block-cipher-trait and use block-cipher crate instead Rename block-cipher-trait to block-cipher on the next breaking change #28.
• Introduce a new NewBlockCipher trait (stream-cipher: add FromBlockCipher trait (fixes #32) #164).
• Add stream_cipher::FromBlockCipher trait.
• Add impl_write! macro to crypto-mac.
• Find solution for buffer-to-buffer cipher operations Consider supporting buffer-to-buffer cipher operations #31
• Add try_new methods (closed as wontfix, see *::new to should return Result<T, E> #47)
• Rename MacResult type to something like Code/Output and rename code method to into_bytes for consistency with the universal-hash crate.
• Add macro for implementing io::Write to crypto-mac similarly to the digest crate. (dup of above)
• Bump opaque-debug to v0.2
• Support variable length AEAD Nonces aead: support variable-length nonces #65 (EDIT: solved by making ciphers generic over their NonceSize)
• Rename crypto_mac::Mac::result, digest::Digest::result, and universal_hash::UniversalHash::result to ::finalize or ::finish

I may have forgotten some changes I had in mind. Feel free to suggest other public API changes.

[burdges]

I think renaming input to update runs contrary to common terminology.

[tarcieri]

To me the common terminology is Initialize-Update-Finalize (IUF) and update would make sense IMO

[newpavlov]

@burdges
Can you provide examples of other libraries which use input? I would also prefer to keep the name to limit breakage, but it looks like it's fairly uncommon name for the method across hashing libraries.

[burdges]

After a quick look, it appears terms like input and add are common only for hashmaps, etc., and update wins with it being the term from OpenSSL, libsodium, and Python, while Go and libgcrypt use write, and operators overloading being common too.

We'd use core::io::Write if it existed, but it does not so whatever. :)

[newpavlov]

BTW maybe we should bump MSRV to 1.36? It will allow us to use alloc without compatibility workarounds.

[akhilles]

Can block-cipher traits support IV non-reuse? With the current API, IV has to be introduced in the cipher’s constructor. We should be able to specify the IV in the encryption call instead.

[newpavlov]

Maybe you mean stream-cipher or block-modes? IIRC the main reason for moving IV to new was interaction with seeking. Also it was more consistent with other traits.

What is motivation for such change in your opinion, assuming we will get the FromBlockCipher trait?

[akhilles]

@newpavlov I was referring specifically to the BlockMode trait. Currently, in order to use a different IV for each encryption, you have to reconstruct the cipher object which results in poor performance. This encourages the reuse of IVs.

Instead, I think it's reasonable to have an API that allows you to specify IV for each encryption request. I believe mbedtls offers a similar API.

[tarcieri]

@akhilles I'd be all about finding misuse resistant nonce management strategies at the abstraction level of AEAD crates, but at the level of block ciphers, concerns like this ring hollow to me:

Currently, in order to use a different IV for each encryption, you have to reconstruct the cipher object which results in poor performance. This encourages the reuse of IVs.

Perhaps we haven't found a way to position block mode crates correctly, but here's how I would advertise them:

• WARNING: Dangerous "hazmat" materials with "subtle" properties
• Prone to explode in your face
• Really you should use AEADs if you want safety

[akhilles]

@tarcieri AES-CBC w/o auth tag and w/o reusing IVs is a perfectly legitimate (and common) use case. There is no API that supports it in this project.

What are the downsides to allowing IV to be provided in the encryption call?

[newpavlov]

@akhilles
I am not sure if you proposal will work well with the stateful approach which we use for block modes API (see encrypt_blocks and decrypt_blocks methods). I think FromBlockCipher trait should work fine here. For example, instead of:

type AesCbc = Cbc<Aes128>;
let cipher = AesCbc::new(key);
let res1 = cipher.encrypt(buf1, pos1, iv1)?;
let res2 = cipher.encrypt(buf2, pos2, iv2)?;

You will write:

let cipher = Aes128::new(key);
let res1 = Cbc::from_cipher(cipher, iv1).encrypt(buf1, pos1)?;
let res2 = Cbc::from_cipher(cipher, iv2).encrypt(buf2, pos2)?;

It's a bit more verbose, but efficiency-wise it will be equivalent. Also it will be more flexible, since encrypt_blocks and decrypt_blocks will be left intact.

[akhilles]

@newpavlov, I'd be perfectly happy with FromBlockCipher. I just wanted a way to change IV without going through round key generation.

Is there a PR open for the FromBlockCipher trait or is it still in the design phase?