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 provides nonce-based online authenticated encryption (nOAE), which the CHAIN/STREAM paper proves is equivalent to OAE2.
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 nOAE 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 ([email protected])
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 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 CHAIN construction achieves the best-possible security for an online authenticated encryption scheme (OAE2).
The STREAM construction provides nonce-based online authenticated encryption (nOAE) 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. 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.
(Note that the 1k-PMAC_Plus construction might be able to address this)
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: 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. 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
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.
The paper describing AES-SIV, Deterministic Authenticated-Encryption: A Provable-Security Treatment of the Key-Wrap Problem contains this explanatory rap song at the end, which goes out to all the chronic IV misusing miscreants in the land:
Yo! We’z gonna’ take them keys an’ whatever you pleaze
We gonna’ wrap ’em all up looks like some ran’om gup
Make somethin’ gnarly and funky won’t fool no half-wit junkie
So the game’s like AE but there’s one major hitch
No coins can be pitched there’s no state to enrich
the IV’s in a ditch dead drunk on cheap wine
Now NIST and X9 and their friends at the fort
suggest that you stick it in a six-layer torte
S/MIME has a scheme there’s even one more
So many ways that it’s hard to keep score
And maybe they work and maybe they’re fine
but I want some proofs for spendin’ my time
After wrappin’ them keys gonna’ help out some losers
chronic IV abusers don’t read no directions
risk a deadly infection If a rusty IV’s drippin’ into yo’ veins
and ya never do manage to get it exchanged
Then we got ya somethin’ and it comes at low cost
When you screw up again not all ’ill be lost
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.