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.
"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.