FAQ
Below are frequently asked questions about Miscreant.
A: Good question! It's an underappreciated gem in cryptography.
A: SIV stands for "synthetic initialization vector" and refers to the process of deriving/"synthesizing" the initialization vector (i.e. the starting counter) for AES-CTR encryption from the given message headers and plaintext message.
Where other schemes might have you randomly generate an IV, SIV modes pseudorandomly "synthesize" one from the key, plaintext, and additional message headers including optional associated data and nonce.
A: It provides stronger security properties as compared to AES-GCM. On Intel-based CPUs there is a ~50% performance hit, however on devices without hardware acceleration for GCM's GHASH function (e.g. IoT/embedded), the performance should be much better.
We hope to have benchmarks soon so we can show exactly how much performance is lost/gained over AES-GCM and AES-GCM-SIV on various platforms, however the scheme is still amenable to full hardware acceleration/parallelization (at least in AES-PMAC-SIV's case) and should still remain very fast.
The STREAM construction provides a nonce-based online [authenticated encryption] (nOAE) construction that can be used for incremental/streaming encryption/decryption and supports parallel encryption/decryption as well as random access while defending against reordering and truncation attacks.
There are other libraries that try to solve this problem, such as saltpack, however these libraries do not provide constructions with security proofs, nor do they provide misuse resistant authenticated encryption, and are prescriptive about protocols and on-the-wire formats, whereas Miscreant is agnostic and doesn't need a specified protocol to provide its security properties.
A: Using the AES function as a MAC (i.e. AES-CMAC) is more expensive than faster hardware accelerated functions such as GHASH and POLYVAL (which use CLMUL instructions on Intel CPUs). Additionally AES-CMAC relies on chaining and therefore cannot run in parallel. This makes AES-SIV slower than AES-GCM-SIV on Intel systems, however AES-SIV provides better security guarantees and will be faster on systems that do not have hardware acceleration for GHASH. We hope to post benchmark numbers soon.
Due to the 128-bit size of the AES block function, AES-SIV can only be safely used to encrypt up to approximately 264 messages under the same key before the "birthday bound" is hit and repeated IVs become probable enough to be a security concern. Though this number is relatively large, it is not outside the realm of possibility.
A: SIV encryption requires making a complete pass over the input in order to calculate the IV. This is less cache efficient than modes which are able to operate on the plaintext block-by-block, performing encryption and authentication at the same time. This makes SIV encryption slightly slower than non-SIV encryption.
However, this does not apply to SIV decryption: since the IV is (allegedly) known in advance, SIV decryption and authentication can be performed block-by-block, making it just as fast as the corresponding non-SIV mode (which for AES-SIV would be AES-EAX mode).
A: Though SIV modes run the MAC operation first, then the encryption function second, they are a bit different from what is typically referred to as "MAC-then-encrypt". SIV modes cryptographically bind the encryption and authentication together by using the authentication tag as an input to the encryption cipher, making them provably secure for all the same classes of attacks as encrypt-then-MAC modes. You can think of SIV modes as being a completely different class of combining encryption and a MAC, which can be described as something like "encrypt-with-MAC" or "encrypt-under-MAC".
Another common source of problems with MAC-then-encrypt is padding oracles, which are commonly seen with CBC modes. AES-SIV is based on CTR mode, which is a stream cipher and therefore doesn't need padding, making it immune to padding oracles by design.
Authenticating the decrypted data does involve decrypting it, however. This means decrypted data is, at one point in time, in memory before it is authenticated. This increases the risk that attacker-controlled plaintext might wind up being used due to authentication bugs.
These libraries attempt to ensure unauthenticated plaintext is never exposed. Furthermore some libraries will perform the AES-CTR portion of AES-GCM decryption without checking the GCM tag, so encrypt-then-MAC is not a bulletproof solution to preventing exposure of unauthenticated plaintexts. To some degree you will always be trusting the implementation quality of a particular library to ensure it operates in a secure manner.
7: Q: Why did you implement the same algorithms 5 times instead of just implementing it in Rust and then wrapping the Rust version, which has better security and performance?
A: We certainly plan on making bindings to the Rust implementation available as optional backends for the other language versions. So we are picking both options.
Miscreant is directly implemented in the respective language to make it more portable and easier to install. While the Rust implementation is the best the library presently offers, it has a lot of drawbacks: first, you have to install Rust to compile it. Second, it requires a nightly Rust compiler, which means the implementation must keep up with nightly changes to Rust. Third, the Rust implementation only supports the Intel AES-NI extension, and therefore won't work on anything but modern Intel CPUs.
A: tl;dr: No, but you may be able to defend it as such.
AES-SIV is the combination of two NIST approved algorithms:
- AES-CTR encryption as described in NIST SP 800-38A, and
- AES-CMAC authentication as described in NIST SP 800-38B.
However, while AES-SIV was submitted to NIST as a proposed mode, it has never received official approval from NIST.
If you are considering using this software in a FIPS 140-2 environment, please check with your FIPS auditor before proceeding. It may be possible to justify the use of AES-SIV based on its NIST approved components, but we are not FIPS auditors and cannot give prescriptive advice here.
Please note that none of this code has undergone a FIPS audit to begin with, so if you intend to use it in that capacity, you're on your own and should fork/vendor your own copy.
A: No, there are no IP rights concerns with either the AES-SIV mode or AES-PMAC-SIV modes (see the "What about patents?" section of Rogaway's PMAC FAQ for imformation about PMAC).
To the best of our knowledge, the algorithm is entirely in the public domain.
A: The CAESAR competition (to select a next generation authentication encryption cipher) seems to be taking much longer than was originally expected: most recently it was supposed to wrap up in 2017, and here in 2018 all of the dates have been changed to "TBD".
Even when it concludes, it will be some time before relevant standards are written as to the usage and deployment of its winner.
Meanwhile RFC 5297 is nearly a decade old, and AES-SIV has seen some organic usage. While not entirely optimal by the metrics of the CAESAR competition, it's a boring, uncontroversial solution we can use off-the-shelf today.
Furthermore, Miscreant has a big advantage over any of the CAESAR contestants: simplicity. The Rust version, for example, which provides both AES-SIV and a fully parallelized implementation of AES-PMAC-SIV, implementing all parts of the constituent algorithms from scratch on top of the AES block encryption function alone, is a little more than 800 lines of code.
A: In the future, we may consider adding support for AES-GCM-SIV.
Please see Issue #60: AES-GCM-SIV for more information.
A: Please see the paper Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem