Nonce-exposing, not nonce-using. If I understand correctly, the idea is to have the api securely generate nonces behind the scenes; that is, E(K,M) is not deterministic. In a high-level api for people who just need to move data from Alice to Bob securely, this seems reasonable.
I goofed with this comment -- it was supposed to be a reply to a sdrapkin's comment, not a reply to the article. Not quite sure how I did that.
Inferno, which sdrapkin cited as an example of crypto done right, offers this API:
public static byte[] Encrypt(byte[] masterKey, ArraySegment<byte> plaintext, ArraySegment<byte>? salt = null)
The docs suggest:
The "salt" parameter can include Additional Data (AD) or its hash - which will also be authenticated.
This is, in my opinion, not okay as a high-level easy-to-use primitive, as it leaks information if you don't properly use the salt.
EDIT: I read the source (https://github.com/sdrapkin/SecurityDriven.Inferno/blob/mast...), and Inferno's primitive is randomized. This avoids the info leak, but it's likely to be a decent amount slower as a result, and the primitive needs a good RNG. As a result, it might be vulnerable to failure if the application uses fork(), it's awkward to implement on some embedded platforms, etc.
The point of nonce-misuse-resistant encryption is to reduce the damage from nonce reuse, not to give you an excuse to ignore nonces entirely for encryption of arbitrary data.
I've read the source too. You are strangely looking at EtM_CBC, which is not Inferno's primary mode. Inferno uses EtM_CTR for the "Encrypt" signature you cite. The raw CBC mode is already nonce-misuse-resistant (reveals common prefix), and thus is better than raw CTR from NMR perspective. If you want to critique Inferno's NMR properties, you should target its primary EtM_CTR primitive, rather than EtM_CBC.
"vulnerable to failure if the application uses fork()" - I strongly suspect that your comfort-zone is c/c++/Linux/*nix, and not .NET framework and Windows. You failure scenario does not apply to Inferno.
If CSRNG is "awkward to implement on some embedded platforms" then it is a platform problem, not Inferno's. Inferno is designed to take full advantage of plentiful (ie. high-quality/cheap/fast) cryptographically-strong randomness available to .NET framework on Windows.
You question Inferno's speed - performance is in the eye of the benchmark beholder - but I doubt you have run any (ie. this is likely FUD). Based on the benchmarks I've run, Inferno is very fast.
Inferno does not ignore nonces - it force-randomizes them internally to the maximum extent (320 bits of entropy). This creates a nonce-misuse-resitant design which eliminates user-supplied nonces, and does not break even under a faulty CSRNG producing a lot less entropy than it should.
