10 ms·
I want XAES-256-GCM/11
- forty 3y agoHow does it compare to XChachaPoly? I guess it's only useful when you are sure to have CPU support for AES and not having to deal with the annoyance of non constant time software implementations. I feel like XChachaPoly has the benefit of being annoyance free (constant time by design even in software implementation), fairly fast even without hardware support and to exists, so it's probably a good choice for most use cases. EDIT: my question is probably more clearly asked as: what's wrong with XChachaPoly that is solved by this new construct?
- wolf550e 3y agoBecause AESNI and CLMUL, AES-GCM is faster than a SIMD implementation of ChaCha20Poly1305. In theory, ChaCha20 is overkill, 8 rounds would have been enough and people do use 12 rounds for disk encryption.
- forty 3y agoYes that was my thoughts as well, if you are concerned about speed and dropping AES rounds, you might as well do the same with Chacha and use Chacha20/8 (which I don't know if it "exists" but Salsa20/8 is a thing, used in scrypt and available in libsodium for example). At least it's also fast when you don't have AESNI.
- nmadden 3y agoReally pedantic nit here, but the cipher Salsa20 is called “Salsa20” and so reduced round versions are called e.g. “Salsa20/8”. However the ChaCha cipher is just called “ChaCha” so the specific-round versions are just “ChaCha20” or “ChaCha8”. I feel like I just “actually it’s GNU/Linux”ed you there though... I feel bad, I’m sorry.
- conradludgate 3y agoI've unfortunately seen many situations where only NIST approved constructions are allowed. ChaCha is not an approved NIST algorithm but AES-256-GCM is
- forty 3y agoI totally get that, but XAES-256-GCM/11 is in an even worse situation than XChachaPoly since none are NIST but XChachaPoly has at least a RFC ^^ EDIT: I'm wrong, ChachaPoly has an rfc, but not the X variant
- commandersaki 3y agoXChaCha20Poly1305 does have an RFC authored by Scott Arciszewski: https://datatracker.ietf.org/doc/html/draft-arciszewski-xchacha-03 https://datatracker.ietf.org/doc/html/draft-arciszewski-xcha...
- forty 3y agoYes but it has been expired for a while
- zahllos 3y agoFrom the NIST doc for GCM: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli... The IV can be any length up to 2^64-1. The reason for picking 96-bit IVs is that other values require an extra invocation of GHASH (page 15). The document recommends 96-bit for interoperability but that's by no means a requirement. The X part is thus in theory already allowed.
- JoshTriplett 3y agoI may be misunderstanding, but this might be the thing already discussed in footnote 2 of the article: "Technically, GCM accepts longer nonces. However, nonces longer than 96 bits are hashed into a starting 128-bit counter value, leaving no dedicated counter space. (96-bit nonces are instead concatenated with a 32-bit counter.)"
- zahllos 3y agoI missed that, good catch. That said, I find the wording of dedicated counter space a bit bizarre. There are only 128 bits per block in AES - in fact I'm not aware of a widely deployed cipher which a larger block size. Whatever goes through ghash becomes the initial plaintext passed to aes under the key (this is the counter) part and then you just increment. This is just a limitation of counter mode in general: the whole IV is technically counter space and is treated as whole when evaluating the birthday bound issue. The critical part mentioned in the post is that XChaCha "hashes the key+nonce into a fresh key". A very similar technique is used un: AES-GCM-SIV (https://datatracker.ietf.org/doc/html/rfc8452#section-9 https://datatracker.ietf.org/doc/html/rfc8452#section-9). The improved security here comes not from any "counter space" or nonce extension per se but the fact that changing the IV changes the effective key used in the block primitive (i.e. the raw aes-encrypt function) as well as the first block of plaintext fed to AES by deriving these from nonce+key. So I guess this is asking for a somewhat different construction. Personally aside from the fact it is already widely deployed I'm not sure I'd keep GHASH.
- tptacek 3y ago
- purple_elephant 3y ago>In 2023, the way to use AES is AES-GCM. Anything else is very unlikely to make sense. Encrypt-then-MAC remains the most conservative and theoretically secure option. Leaving aside the (very serious) nonce reuse issue, the cracks on non-committing AEADs in general (such as AES-GCM) are already showing. Partitioning oracle attacks affect all of them: https://crypto.stackexchange.com/questions/88716/understanding-the-impact-of-partitioning-oracle-attacks-on-stream-ciphers https://crypto.stackexchange.com/questions/88716/understandi... There are also other minor GCM-specific issues (weak keys etc.). None of the issues are cypher-breaking, but I wouldn't say that AES-GCM is automatically the best choice for everything.
- tptacek 3y agoGCM is an encrypt-then-MAC mode.
- some_furry 3y agoAnd AES-GCM-SIV is MAC-then-Encrypt but is still secure (albeit not committing), so people cry foul when it's pointed out. AEADs are obviously better than EtM, because EtM doesn't allow for authenticating the unencrypted context. I wrote about turning CTR+HMAC into a committing AEAD and promptly screwing it up badly: https://soatok.blog/2021/07/30/canonicalization-attacks-against-macs-and-signatures/ https://soatok.blog/2021/07/30/canonicalization-attacks-agai...
- fdupress 3y agoEtam absolutely allows you to authenticate an unencrypted context. In fact, you must ensure that the nonce, a piece of unencrypted context, is authenticated. Nothing stops you from throwing more stuff in there. The only thing you can do with an integrated AEAD that you can't do with a constructed one (with standard interface and security) is include authenticated and unencrypted context halfway through an encryption.
- some_furry 3y ago
- formerly_proven 3y agoAES-256-GCM runs at well above 10 GB/s per core on semi-modern desktop/server CPUs and the 128 variant isn’t actually 40% faster iirc. I think it was like 11 vs 13 GB/s on the same hardware, not what 10-vs-14 rounds would seem to imply. Even chapoly is only around 3-4x slower. (That’s gigabytes per second, not gigabits)
- some_furry 3y agoI sketched out an extended nonce construction using AES-GCM with CBC-MAC last year (both of which are permitted by FIPS). https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-without-nightmare-fuel https://soatok.blog/2022/12/21/extending-the-aes-gcm-nonce-w... I never considered only using 11 rounds, though. That'd have a significant performance impact if we could.
- amadvance 3y agoCool. If I can propose a little improvement, it would be nice to allow an arbitrary long nonce. Like, feeding the first 96 bits of the nonce into GCM, and the rest in CBC-MAC.
- some_furry 3y agoWhat benefit do you hope to gain from an arbitrarily long nonce? The design I sketched out extended the 96-bit GCM nonce to 224 bits, which is longer than the 192 bits of XSalsa and XChaCha. That's also the maximum that's supported by the algorithms as used. If we supported arbitrarily longer inputs to AES-CBC-MAC, it's going to get mixed down into an AES block (128 bits long) anyway, so the benefit of arbitrary-length extensions over a 128-bit extension is unclear to me.
- amadvance 3y agoThat would make AES-XGCM an immediate replacement of AES-GCM that already supports an arbitrary long nonce.
- some_furry 3y agoThe "arbitrary long nonce" gets hashed down (using GHASH) to 96 bits. I mean, sure, if you really want to, you can already do that with the GCM part. I would hesitate to do that to the AES-CBC-MAC part. Your proposal would then be to dedicate the first 16 bytes (128 bits) to the extension, and the rest to GCM.
- jwilk 3y agoWhat does 11 mean?
- some_furry 3y ago11 rounds instead of 14 rounds.
- zahllos 3y agoNumber of rounds. AES128 uses 10 rounds, 192 uses 12 and 256 14. The proposal being to drop AES256 from 14 to 11 rounds.
- jeron 3y ago[flagged]
- dathinab 3y agoplease no more child abuse stories for today
- kmeisthax 3y agoHas there been any situation in which 10 rounds would be utterly broken but 14 would give you "enough" of a security margin? My impression is that once you've managed to break a cipher enough to get that many rounds, you've also discovered a linear-time attack on that cipher[0]. Adding a mere 28% slowdown on that attack won't help. [0] "Linear time" means O(n), which is computer science speak for "f(n) = an, but we ignore the a because we're only interested in the fastest growing component of the function". In some cases the a is so large as to make the algorithm in question not feasible for ANY size. Let's just pretend the attacker doesn't have that problem.
- nemo1618 3y agoYou'd probably be interested in the "Too Much Crypto" paper linked in the post: https://eprint.iacr.org/2019/1492 https://eprint.iacr.org/2019/1492
- Joker_vD 3y ago> To support this claim, we review the cryptanalysis progress in the last 20 years, ...and rationally and scientifically assuming that the rate of the progress won't increase and that there will be no major breakthroughs in the future, we propose revised number of rounds for AES, BLAKE2, ChaCha, and SHA-3. The crypto is already fast enough, thank you very much; many attacks work only precisely it's quite fast to brute force huge subspaces of key material.
- tptacek 3y agoWhich attacks would those be? Are you thinking about password cracking? What are the other ones?
- tedunangst 3y agoSHA-1 collisions are (almost) as much brute force as anything.
- sdrapkin 3y agoGCM (ie. AES-GCM) has the following problems, which extended variants - those that deterministically randomize (key,nonce) pair - do not solve: Inability to encrypt more than 64Gb with the same (key,nonce) pair. Lack of commitment (whether key-commitment, or key+nonce+ad commitment). If one is seriously considering breaking away from existing GCM standards to create yet-another-standard, such proposal would need to offer improvements in all areas (ex. a proposed standard for converting any AEAD into streaming chunk-based AEAD with practically unlimited message sizes under the same (key,nonce) and unlimited message counts. GCM-256 is ubiquitous and is often the preferred choice for all the reasons mentioned by the author, but that very argument is what makes non-standard GCM with 11 AES-rounds silly. In 2023 we should be working on new standards that "wrap" existing crypto-primitives (which are already implemented/available in countless hardware-accelerated libraries/APIs) to get additional features/benefits/capabilities - not musing about AES with 10+1 rounds or SHA-512-really-fast with 80-1 rounds..
- tptacek 3y agoPresumably, if you're going to do an extended-nonce GCM, you could reformat the counter block (since the nonce is encoded in the key anyways) to get rid of the 64Gb limit --- but that complicates the FIPS story, I guess?
- sdrapkin 3y agoIndeed. But FIPS is not the only problem. Both the McGrew/Viega spec and subsequent NIST spec of GCM mandate a 4-byte counter - any departure from that would be "no longer GCM".
- tptacek 3y agoYep. Gross.
- motohagiography 3y agoIs the argument for a small counter that nobody serious will treat it as a significant diversification component or reliable source of entropy, especially in a streaming mode? It's a counter whose function is necesesarily finite and predictable (and reversible?), if not explicitly linear. Intuitively, any substitutions or convolutions derived from it would weaken subsequent operations, no?
- barbegal 3y ago> If for example an application encrypts 2^48 messages under different 128-bit keys, and all messages start with the same few bytes, an attacker can build a lookup table, try and lookup the ciphertext of 2^64 keys, and have a 2^-16 chance to decrypt one message. Not good. This is satire right? The computational and storage requirements to preform such an attack to just get a small probability of decrypting one message seem ludicrous.
- mike_hock 3y agoMillions of terabyte disks of storage. Then repeat the attack a couple thousand times. In cryptography, you don't want "ludicrously" infeasible, as in the NSA can just about afford the hardware and do it, you want astronomically infeasible.
- SahAssar 3y agoAnd you want it to be so infeasible that even attacking a single message with perfect knowledge of all non-secrets is "astronomically infeasible". Its not enough to just make it astronomically infeasible to attack everyone.
- 2h 3y ago[flagged]
- dcow 3y agoWhy are we even hashing the nonce in the first place? Don’t we have enough entropy these days to just pull what we need?
- tptacek 3y agoIt's an AES-based mode, so it only has the AES message block (and, implicitly, the key) to work with, and some of the bits in the message block need to hold the CTR counter. The problem is that leaves an uncomfortably low margin of random bits.
- dcow 3y agoI guess I never conceptually got onboard with the idea that hashing down more entropy is better than pulling the exact amount of good entropy. But I lack the formal qualifications to argue as much (or knowledge of a proof to the contrary). I know we like to be paranoid when things make us uncomfortable.
- tptacek 3y agoIt's not an entropy question at all; it's that the algorithm only gives you a fixed amount of bits (the key size plus the AES message block) to divide up, and if you only use the message block itself (as NIST GCM does) that's not enough space to feel comfortable picking nonces at random due to e.g. the birthday problem.
- mananaysiempre 3y ago> we might wish OCB hadn’t been patented Rogaway says he has released all his OCB patents into the public domain[1], so it sounds like OCB might be an option for greenfield projects? OTOH, I don’t see why you’d use any kind of AES in a greenfield project outside the surreal FIPS world, given how absolutely miserable constant-time software for it is. (ChaCha is kind of miserable when you don’t have at least a 32-bit ALU with a barrel shifter—that is on exactly the kind of platforms where table-based AES might actually be constant-time—but I’m not sure that’s a good enough reason.) [1] https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/ https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3...
- tptacek 3y agoIt is now, but when all this stuff was getting nailed down and all the standards were being written and all the AEAD libraries were being implemented it was off the table, so a lot of people feel like rehabilitating OCB isn't a great hill to die on.
- exabrial 3y agoDo you _really_ need AES256 though? Just a large computation overhead while AES128 is extraordinarily secure already. The conversation about nonce sizes is 100% on point however. Why isn’t it at least the size of the key?
- tptacek 3y agoBecause it predates awareness of how nonce-based AEADs are misused by developers. Which, in fairness, is true of most of the first generation of AEADs, including Chapoly --- XSalsa was a clever hack, not the original design.
- vlovich123 3y agoIs AES256 meaningfully slower than AES128 when you have AES-NI extensions?
- formerly_proven 3y agoNah Specifically, "nah with OpenSSL on AMD or Intel boxes from the last decade": AES-128 (ctr mode) 9.7 GB/s AES-256 (ctr mode) 8.6 GB/s (90 % as fast, not ~70 % as 10-vs-14 rounds would naively suggest) AES-128 (gcm mode) 12.4 GB/s AES-256 (gcm mode) 10.8 GB/s (plain CTR is slower than GCM because the GCM implementation in OpenSSL has received more attention than the counter mode implementation, simply because standalone counter mode is used a lot less) And this is just one core anyway. How many 100 GbE ports are you running per core? I keep reiterating this because crypto=slow is still a very common idea from the days when AES-128 would peg a core running at 40 MB/s, rcp actually was 3x faster than scp, http:// http:// instead of https:// https:// would actually meaningfully reduce load, SMB/NFS encryption would actually slow things down and it was a bog to actually use a system running with LUKS-encrypted drives. But that's not the case any more. Encryption is really really fast and has been for about ten years, depending on what you're looking at exactly. Nowadays even many microcontrollers have AES acceleration because - internet of things mainly.
- vlovich123 3y ago
- cosmojg 3y agoIf FIPS compliance is one of your primary motivations for using AES, why not use Ed25519 or Ed448 instead?
- pingiun 3y agothose are signature algorithms. aes/chacha are symmetric ciphers
- jedisct1 3y agoAEGIS is being standardized, and solves many of the AES-GCM issues while being significantly faster. https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/ https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/ https://github.com/jedisct1/aegis-128X https://github.com/jedisct1/aegis-128X Many implementations are available, including for Go: https://github.com/jedisct1/draft-aegis-aead#known-implementations https://github.com/jedisct1/draft-aegis-aead#known-implement...