The best crypto you've never heard of, brought to you by Phil Rogaway
A misuse resistant symmetric encryption library designed to support authenticated encryption of individual messages, encryption keys, message streams, or large files using the AES-SIV (RFC 5297) and CHAIN/STREAM constructions.
Miscreant is available for several programming languages, including Go, JavaScript, Python, Ruby, and Rust.
Miscreant is a set of interoperable libraries implemented in several languages providing a high-level API for misuse-resistant symmetric encryption. Additionally, it provides support for "online" authenticated encryption use cases such as streaming or incrementally encryption/decryption of large files.
The following constructions are provided by Miscreant:
-
AES-SIV: (standardized in RFC 5297) combines the AES-CTR (NIST SP 800-38A) mode of encryption with the AES-CMAC (NIST SP 800-38B) or AES-PMAC function for integrity. Unlike most authenticated encryption algorithms, AES-SIV uses a special "encrypt-with-MAC" construction which combines the roles of an initialization vector (IV) with a message authentication code (MAC) using a construction called a synthetic initialization vector (SIV). It works in practice by first using AES-CMAC or AES-PMAC to derive an IV from a MAC of zero or more "header" values and the message plaintext, then encrypting the message under that derived IV. This approach provides not just the benefits of an authenticated encryption mode, but also makes it resistant to accidental reuse of an IV/nonce, something that would be catastrophic with a mode like AES-GCM. AES-SIV provides nonce reuse misuse resistance, considered the gold standard in cryptography today.
-
CHAIN: a construction which provides "online" chunked/multipart authenticated encryption when used in conjunction with a cipher like AES-SIV. CHAIN achieves the best-possible security for an online authenticated encryption scheme (OAE2).
-
STREAM: a construction which provides streaming authenticated encryption and defends against reordering and truncation attacks. Unlike CHAIN, STREAM supports parallelization and seeking, allowing chunks within a message to be encrypted and decrypted in any order the user wants. STREAM achieves a slightly lower definition of security for an online encryption scheme (OAE1) as compared to CHAIN.
Though not yet described in an RFC, CHAIN and STREAM were designed by Phil Rogaway (who also created AES-SIV) and are described in the paper Online Authenticated-Encryption and its Nonce-Reuse Misuse-Resistance, which contains a rigorous security analysis proving them secure under the definitions of OAE2 and OAE1 respectively.
NOTE: this library does not yet support CHAIN and STREAM! Please see the tracking issues CHAIN support (OAE2) and STREAM support (Nonce-based OAE) to follow progress on adding support.
Have questions? Want to suggest a feature or change?
- Gitter: web-based chat about Miscreant
- Google Group: join via web or email (miscreant-crypto+subscribe@googlegroups.com)
| Name | Authenticated Encryption | Misuse Resistance | Performance | Standardization |
|---|---|---|---|---|
| AES-SIV | 💚 | 💖 | 💛 | RFC 5297 |
| AES-PMAC-SIV | 💚 | 💖 | 💚 | None |
| Name | Authenticated Encryption | Misuse Resistance | Performance | Standardization |
|---|---|---|---|---|
| AES-GCM-SIV | 💚 | 💚† | 💖♣ | Forthcoming‡ |
| AES-GCM | 💚 | 💔 | 💖♣ | NIST SP 800-38D |
| AES-CCM | 💚 | 💔 | 💛 | NIST SP 800-38C |
| AES-CBC | 💔 | 💔 | 💖 | NIST SP 800-38A |
| AES-CTR | 💔 | 💔 | 💖 | NIST SP 800-38A |
| ChaCha20+Poly1305 | 💚 | 💔 | 💖 | RFC 7539 |
| XSalsa20+Poly1305 | 💚 | 💔 | 💚 | None |
| Heart | Meaning |
|---|---|
| 💖 | Excellent |
| 💚 | Great |
| 💛 | Fine |
| 💔 | Bad |
† Previous drafts of the AES-GCM-SIV specification were vulnerable to key recovery attacks. These attacks are being addressed in newer drafts of the specification.
‡ Work is underway in the IRTF CFRG to provide an informational RFC for AES-GCM-SIV. For more information, see draft-irtf-cfrg-gcmsiv.
♣ Only applies to platforms which provide a hardware accelerated version of the GHASH/POLYVAL functions. On platforms that do NOT provide acceleration for these functions (e.g. microcontrollers/IoT platforms), these ciphers receive a 💛 (or potentially 💔 if too constrained)
When standardization work around AES-GCM-SIV is complete, it will be seriously considered for inclusion in this library. AES-GCM-SIV has the advantage of the GHASH (technically POLYVAL) function being able to run in parallel, versus AES-CMAC's sequential operation.
AES-SIV has the advantages of stronger security guarantees, simplicity, and that it can be implemented using the AES encryption function alone, making it a better choice for environments where a hardware accelerated version of the GHASH function is unavailable, such as low-powered mobile devices and so-called "Internet of Things" embedded use cases.
Miscreant libraries are available for the following languages:
| Language | Version |
|---|---|
| Go | N/A |
| JavaScript |  |
| Python |  |
| Ruby |  |
| Rust |  |
This section provides a more in-depth exploration of how the AES-SIV function operates.
- AES-CMAC and AES-CTR keys: K1 and K2
- Zero or more message headers: H1 through Hm
- Plaintext message: M
- Initialization vector: IV
- Ciphertext message: C
AES-SIV first computes AES-CMAC on the message headers H1 through Hm and messages under K1, computing a synthetic IV (SIV). This IV is used to perform AES-CTR encryption under K2
- AES-CMAC and AES-CTR keys: K1 and K2
- Zero or more message headers: H1 through Hm
- Initialization vector: IV
- Ciphertext message: C
- Plaintext message: M
To decrypt a message, AES-SIV first performs an AES-CTR decryption of
the message under the provided synthetic IV. The message headers
H1 through Hm and candidate decryption message are
then authenticated by AES-CMAC. If the computed IV’ does not match the
original one supplied, the decryption operation is aborted. Otherwise, we've
authenticated the original plaintext and can return it.
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 at the cost of a small performance hit as compared to AES-GCM. We hope to have benchmarks soon so we can show exactly how much performance is lost, however the scheme is still amenable to full hardware acceleration and should still remain very fast.
The CHAIN construction achieves the best-possible security for an online authenticated encryption scheme (OAE2).
The STREAM construction provides a weaker definition of online authenticated encryption (OAE1) but 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. In particular saltpack is a rather complicated amateur construction which does many repitious and redundant HMAC operations with little justification as to why or if all relevant data is actually cryptographically bound, much less a rigorous security proof.
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.
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.
A: 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 AES-SIV mode. 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. 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.
A: We are working on adding support for an AES-SIV construction based on AES-PMAC instead of AES-CMAC which we are calling AES-PMAC-SIV. Though this is a novel construction, it retains all of the original security properties of the original AES-SIV construction, but is fully parallelizable/vectorizable and therefore provides better performance.
In the future, we may consider adding support for AES-GCM-SIV.
Please see Issue #31: Support a faster construction than AES-SIV for more information.
A: Please see the paper Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem.
A: The many claims of support in the READMEs are actually lies! They are not implemented yet. Support is forthcoming, sorry!
Please see the tracking issues CHAIN support (OAE2) and STREAM support (Nonce-based OAE) to follow progress on adding support.
We abide by the Contributor Covenant and ask that you do as well.
For more information, please see CODE_OF_CONDUCT.md.
Bug reports and pull requests are welcome on GitHub at https://github.com/miscreant/miscreant
Copyright (c) 2017 The Miscreant Developers. Distributed under the MIT license. See LICENSE.txt for further details.
Some language-specific subprojects include sources from other authors with more specific licensing requirements, though all projects are MIT licensed. Please see the respective LICENSE.txt files in each project for more information.