by michaelsmanley
1 subcomments
- I just want to comment on how clear I find Filippo Valsorda's writing on this kind of thing. Even for an old dunderhead like me, his mathematics and examples were easy to follow. I really appreciate that kind of clarity in technical writing.
by staticassertion
3 subcomments
- Is there any reason to believe that Grover's is as good as it gets? I'm on board here, and I think the article caveats that it's a matter of cost, priority, and assumptions. Cool, cool, I'm already using xaes-256-gcm. But I'm just curious if quantum could have new applications for algorithmic analysis, or take advantage of other weaknesses?
- On one hand I hear that quantum computers will crack factorisation and discrete logarithms, on the other that the max number factorised is 15 and that 21 might not even be feasible.
What is going on?
- I think quantum may be practically mitigated with aggressive key rotation in some cases. I've been prototyping an oauth machine-to-machine integration with a banking vendor that has our ecdsa keys rotate every 5 minutes. The keys are scheduled for deletion after 10 minutes. I see no reason I couldn't reduce this to something like 30s/60s. Our counterparty frequently scans our JWKS endpoint for revocation, so in practice an attacker with a quantum computer would need to be very fast if they wanted to break this particular wire agreement the scary way.
by red_admiral
0 subcomment
- On the symmetric side, I think "AI finds some new classical attack" is the main thing to worry about at the moment. Small probability of p(doom) in the sense of AES falling, but nonzero nonetheless.
As far as I know, the current state of AES-256 is something like "this attack breaks AES in 2**254 instead of 2**256 if we have something like 2**80 bits of ciphertext to work with in the first place". That's nice for getting papers in crypto conferences but not something to lose sleep over yet, but an AI trained on the entirety of LNCS and ePrint might be a different matter.
That and side-channels, but we've known about those for a while.
Whether AES or ChaCha holds up better in the face of AI is an interesting open question for which I can't offer anything better than a coin flip.
by jcalvinowens
0 subcomment
- > I generally believe that 256-bit “security levels” are somewhere between a comfort blanket and numerology [...] AES-256 was unfortunately defined to perform more rounds than AES-128, making it needlessly slower.
Obviously if you benchmark it in RAM you'll see it... but with LUKS disk encryption, for example, disk throughput is completely unaffected by the key size on my newer machines with AES-NI.
In cases like that, it seems silly to me to use the smaller keysize: why would I sacrifice even a tenuous theoretical security benefit for absolutely nothing in return? But granted, the larger keysize will have a measurable cost in most applications, FDE is a rarer case.
by ninjahawk1
2 subcomments
- Very good breakdown, if I’m understanding Grover’s algorithm correctly, are you saying essentially that it would require either too much compute or too much time to be feasible but is still much more realistic than a brute force attack?
If that’s the case, would the time eventually be basically irrelevant with enough compute? For instance, if what’s now a data center is able to fit in the palm of your hand (comparing early computers that took up rooms to phones nowadays). So if compute is (somehow) eventually able to be incredibly well optimized or if we use something new, like how microprocessors were the next big thing, would that then be a quantum threat to 128-bit symmetric keys?
- I get what he’s saying, but, doesn’t he compare classical speed up of parallelizing 64 bit key space on 2^16 cpus with parallelizing 128 bits key space on QCs? It’s true that sqrt (2^128/2^16) = 2^56 and that 56 >> 48, but in one case you are attacking a 64 bits key space and in the other a 128! If you parallelize 2^128 on 2^16 CPUs you get 128-16=112 bits of key space per cpu which is much bigger than 56! No?
Edit: I mean, I get the point is to prove that 2^128 on QC is not the same as 2^64 on CC but it’s still a lot less to search. If a paper came out with that big of a key space reduction AES would be considered broken IMO
by kazinator
2 subcomments
- Quantum computers are mainly a threat to naive investors.
by TacticalCoder
4 subcomments
- Tangentially related but regarding RSA and ECC... With RSA can't we just say: "Let's use 16 384 bit keys" and be safe for a long while?
And for ECC, I know many are using the "2 exp 255 - 19" / 25519 for it's unlikely to be backdoored but it's only 256 bits but... Can't we find, say, "2 exp 2047 - 19" (just making that one up) and be safe for a while too?
Basically: for RSA and ECC, is there anything preventing us from using keys 10x bigger?
by the_data_nerd
0 subcomment
- Rotation protects one threat model, not both. A broken signing key five minutes old is one forged-window. Harvested ciphertext in someone's archive does not care when you deleted the session key. Rotate the signer, but put xaes-256-gcm on the payload if you want the bytes safe ten years out.
by fred_is_fred
0 subcomment
- He mentions "non-existing AES-512" but why not? Why not AES-1024 or AES-4096? Is it too much processing power needed to encrypt and decrypt? I am guessing perhaps also the algo needs work - you can't just take AES-128 and add bits, if you could it would have been done?
by jeffrallen
0 subcomment
- One frustrating thing about the forefront of crypto is that certainty is missing. Responsible cryptographers have to hedge their advice.
One wonderful thing about Filippo is that when it is possible for him to give concrete advice, he gives it, and brings receipts.
Thanks Filippo!
by dogtimeimmortal
0 subcomment
- > there is a concrete danger to asymmetric cryptography
I guess there is genuine cause for concern and a reason why i keep seeing these error pages telling me to update my browser.
note, firefox 78(esr) still gets a 32/32 in security on https://html5test.co/
basilisk 2025: 26/32(-6 experimental features)
pale moon 33.5: 26/32(-6 exp. feat.)
seamonkey 2.53.23: 24/32(-6 exp. -2 prop.)
I don't know why i experience so much hate against spidermonkey and goanna while surfing the web? it appears they are keeping up to date with security features...?
- If this is true, I feel teh wifi alliance have a tonne to answer for the ewaste they generate.
WPA3 moved from symmetric AES to ECDH which is vulnerable to Quantum. Gonna be a tonne of IOT inverters waste.
- Good post. Entirely correct, and well known amongst quantum researchers, but under appreciated in general.
Grover attacks are very blatantly impractical. When someone describes Grover-type attacks in the same breath as Shor-type attacks, without caveats, that's a red flag.
- Certainty is a wonderful thing
- I wonder when the OpenSSH developers will change their stance on Ed448.
- [flagged]
by jeremie_strand
0 subcomment
- [dead]
- [dead]
- Interesting approach — curious how this scales under real load.
by occamofsandwich
1 subcomments
- Disconcerting opening. If you want to put hash algorithms in the same category as symmetric keys in this particular case then say so without referring to them as if they are symmetric keys.
- encryption is not ever to be considered impossible to break.
every encryption scheme has at least one way to be decrypted.
fidelity of information is one use of encryption, if you apply the solution and get garbage, something is wrong, somewhere.
occultation of information is another use, that is commonly abused by extending undue trust. under the proviso that encryption will eventually be broken, you cant trust encryption to keep a secret forever, but you can keep it secret, for long enough that it is no longer applicible to an attack,or slightly askew usecase, thus aggressive rotation of keys becomes desirable
Hacker News