[HN Gopher] I want XAES-256-GCM/11
___________________________________________________________________
I want XAES-256-GCM/11
Author : harporoeder
Score : 82 points
Date : 2023-07-06 18:54 UTC (4 hours ago)
(HTM) web link (words.filippo.io)
(TXT) w3m dump (words.filippo.io)
| barbegal wrote:
| > 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 wrote:
| Millions 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 wrote:
| And 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 wrote:
| > This is satire right
|
| It's not. This guy went off the deep end a long time ago. Sadly
| someone thought it was a good idea to give him write access to
| essentially the entire Go crypto package. Meanwhile he ignores
| or downplays REAL problems like TLS fingerprinting.
| jwilk wrote:
| What does 11 mean?
| some_furry wrote:
| 11 rounds instead of 14 rounds.
| zahllos wrote:
| Number of rounds. AES128 uses 10 rounds, 192 uses 12 and 256
| 14. The proposal being to drop AES256 from 14 to 11 rounds.
| dcow wrote:
| Why are we even hashing the nonce in the first place? Don't we
| have enough entropy these days to just pull what we need?
| purple_elephant wrote:
| >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/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 wrote:
| GCM is an encrypt-then-MAC mode.
| some_furry wrote:
| And 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-
| agai...
| fdupress wrote:
| Etam 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 wrote:
| > Etam absolutely allows you to authenticate an
| unencrypted context.
|
| You can specify an EtM construction that accepts
| additional authenticated data. However, you can also do
| it insecurely (as the post I linked above describes)
| without realizing you did it insecurely. This is why most
| people prefer to use cryptographer-approved AEAD modes.
|
| > In fact, you must ensure that the nonce, a piece of
| unencrypted context, is authenticated.
|
| For CBC mode, sure. For CTR mode? Not really.
|
| > Nothing stops you from throwing more stuff in there.
|
| What prevents an attacker from shifting bits from the
| ciphertext field into the AAD field in the decrypt path
| and yield the same HMAC tag? Unless you have an answer to
| this question, vanilla "encrypt then MAC" is not
| sufficient. You need a better-engineered construction
| than that.
|
| I'm pretty sure the linked post covered all of this
| nuance. Please let me know if something wasn't clear, or
| you feel it was missing.
| formerly_proven wrote:
| Maybe I'm missing something here or I'm just being dense
| but what exactly is the problem with EtM and AAD? Just use
| a suitable encoding like MAC(len(aad) || aad || E(plain))
| some_furry wrote:
| It's easy to say "just use a suitable encoding".
|
| But when people say "use AES-CBC + HMAC" and cite Signal
| as an example, and Signal's implementation does this:
| https://github.com/signalapp/Signal-
| Android/blob/main/app/sr...
|
| Well, when that happens, I feel the need to pipe in :)
|
| If you're careful enough to not implement a naive
| protocol that stitches AES+CBC and HMAC-SHA2 together
| (or, as tptacek put it in a podcast episode, throw some
| crypto potions into a cauldron and _see what happens_ ),
| you're probably the minority of crypto-savvy people.
| peppermint_gum wrote:
| > But when people say "use AES-CBC + HMAC" and cite
| Signal as an example, and Signal's implementation does
| this: https://github.com/signalapp/Signal-
| Android/blob/main/app/sr...
|
| That's very vague and therefore not very helpful. Could
| you say what exactly is wrong with the code you linked?
| soatok wrote:
| It does exactly what I've been describing!
|
| They provide AE, not AEAD.
|
| They feed an IV and ciphertext into HMAC. They don't feed
| additional authenticated data.
|
| If someone followed Signal's example, they either
| wouldn't have AEAD, or they're likely to make the exact
| mistake described in the post I linked above.
|
| I don't know how to be more helpful here. I've been only
| repeating myself.
|
| AEAD modes let you bind a ciphertext to a context without
| increasing bandwidth. This is super important for
| database cryptography. Read more:
| https://soatok.blog/2023/03/01/database-cryptography-fur-
| the...
|
| Whether "it's not AEAD" matters for an application
| depends on many factors. Signal doesn't need it.
| formerly_proven wrote:
| AES-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)
| zahllos wrote:
| From the NIST doc for GCM:
| 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.
| tptacek wrote:
| As I understand it, the limitation people are concerned about
| is that of the IV/counter block. It's not that you can't hash
| an arbitrarily large nonce down to 96 bits; you obviously can.
| It's that ultimately you've only got 96 bits on the wire to
| express your nonce, and if they collide GCM falls apart. That's
| the X trick in XSalsa: the wider nonce gets laundered into the
| key.
| JoshTriplett wrote:
| I 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 wrote:
| I 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).
| 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 wrote:
| The SIVs have somewhat different security properties than
| straight AEAD; they're usually a win, but not always.
| Moreover: the whole point of doing an extended-nonce AEAD
| is to avoid the extra mechanism of a nonce-misuse-resistant
| AEAD by giving yourself enough headroom to just pick huge
| random nonces.
| zahllos wrote:
| Note that I'm not saying use SIV. I'm just saying that
| SIV already does the extended nonce part:
|
| > The AEADs defined in this document calculate fresh AES
| keys for each nonce.
|
| I guess write an RFC for extended nonce only?
| tptacek wrote:
| Gotcha, thanks!
| jeron wrote:
| >XAES-256-GCM/11
|
| if Elon has another child, this should be the name
| dathinab wrote:
| please no more child abuse stories for today
| kmeisthax wrote:
| Has 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 wrote:
| You'd probably be interested in the "Too Much Crypto" paper
| linked in the post: https://eprint.iacr.org/2019/1492
| Joker_vD wrote:
| > 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 wrote:
| Which attacks would those be? Are you thinking about
| password cracking? What are the other ones?
| some_furry wrote:
| I 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-w...
|
| I never considered only using 11 rounds, though. That'd have a
| significant performance impact if we could.
| forty wrote:
| How 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?
| conradludgate wrote:
| I'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 wrote:
| I 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 wrote:
| XChaCha20Poly1305 does have an RFC authored by Scott
| Arciszewski: https://datatracker.ietf.org/doc/html/draft-
| arciszewski-xcha...
| wolf550e wrote:
| Because 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 wrote:
| Yes 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.
| sdrapkin wrote:
| GCM (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 wrote:
| Presumably, 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 wrote:
| Indeed. 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 wrote:
| Yep. Gross.
___________________________________________________________________
(page generated 2023-07-06 23:00 UTC)