If you encrypt your data twice (taken very literally):
c1 = E1(p, k1)
c2 = E2(p, k2)
If we assume E1() is broken by a quantum computer, E2 doesn't matter to protect p.
What you do instead is to use multiple KEMs and combine them securely (see the blog post I linked) in such a way that the confidentiality of your shared secret (i.e., the key you actually use for encryption) is preserved if any of the underlying KEMs is unbroken.
This in practice looks like a KDF based on a hash function where the component shared secrets (and, depending on the underlying KEM's binding properties, underlying ciphertexts too) are concatenated.
This is very different than merely "encrypt your data twice". You only encrypt your data once. The KEY YOU ENCRYPT WITH is, instead, the result of multiple asymmetric operations.
I cannot stress enough how different these proposition are. It's like suggesting someone swim downstream in electric current. The words might make logical sense to a non-expert, but it's utterly unsafe taken literally.
It seems to me you assumed that the poster that replied to you meant encrypting in parallel, while it seems pretty clear to me what they meant was c = E1(E2(p, k2), k1).
The thing is: Quantum computers don't break AES-GCM, ChaCha20-Poly1305, or any other modern authenticated cipher. Layering encryption or doing cipher cascades is pointless.
The thing a cryptography-relevant quantum computer does is break RSA and elliptic curve cryptography, so that the underlying key (k1 or k2) is recoverable from its corresponding public component.
Hybrid KEMs, such as mlkem768x25519 (a.k.a. X-Wing) is a simple abstraction with security proofs that does both classical (X25519 is elliptic curve) and post-quantum (ML-KEM-768 is lattice-based) cryptography and combines them securely into a single key agreement.
"Encrypt twice" is bad advice. Even if you get the same approximate security, you're giving up a lot of performance.
Encrypt once, but encrypt with a key you can be confident in the secrecy of.
Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs? The change of jargon from "encryption" to "KEM" doesn't mean anything to most people talking about this post-quantum risk. To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.
Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection. They intuit having to open two locks in series to get to the valuable stuff, not adding two different access paths that each suffice for access.
"Intuition" about how cryptography works is notoriously bad. Many intuitive things about cryptography are false, and many true things about cryptography are non-intuitive. For this reason it is difficult to seriously discuss cryptography when people are vaguely referring to what they intuitively hope to achieve, framed in terms of concrete constructions that are not secure.
This is also completely ignoring that designing secure systems is about MUCH more than selecting the right "hard problem". Concretely
> They intuit having to open two locks in series to get to the valuable stuff, not adding two different access paths that each suffice for access.
might mean requiring a much more complicated lock that, in its ideal implementation has the properties you want, but practically is easier to implement incorrectly, yielding a less secure scheme. Considerations of this form almost never appear, despite being very relevant to the end goal of protecting users.
Similarly, this "defense in depth" intuition is currently not particularly controversial for hybrid KEMs. it is currently quite controversial for hybrid signatures though. The intuitive story would work perfectly well for signatures though. So this intuition does not end up being particularly useful for understanding the actual discussion.
I don't disagree, but I think the folks who know this ought to remember the lay person perspective and try to address it more concretely.
Rather than rejecting the framing because they (we) aren't fluent in your jargon, provide a more constructive hint... E.g. "You may be thinking the symmetric cipher key is simply encrypted with the asymmetric cipher and concatenated to the bulk message. But, to mitigate known cryptographic system risks, modern solutions use specialized key encapsulation or key exchange methods (KEM) which are not directly encrypted messages containing key material."
> I think the folks who know this ought to remember the lay person perspective
That's fair. I hold Hacker News to a higher bar of technical proficiency than a general audience. My hope with insisting on correct framing is to nudge other experts in adjacent fields to teach your more general audiences how to think about these topics more correctly so it's more approachable to the general public.
I'm generally sympathetic to your point, it is just difficult for this particular topic. For example, I mentioned how precision in cryptographic language is important, as there was a discussion about combiners for encryption, when really people should use combiners for KEMs, along with hybrid encryption (here, meaning building public-key encryption from a KEM + symmetric key encryption).
The issue is that none of the above is relevant to the article that we are in the comments of. The article is about signatures. Why are we talking about encryption/KEMs in the first place?
One might hope the story for combiners for KEMs (which people may have intuition for due to combiners for encryption, which you could easily show in an undergraduate cryptography course) is broadly similar to the story for combiners for signatures. Unfortunately, that's not true at all. It would be a very reasonable perspective to have that we should use combiners for KEMs but not combiners for signatures. It would be very difficult to communicate this to a layperson without being very precise about the jargon.
This is especially true as this is a topic where a notable cryptographer has spent the last few years libeling several other cryptographers, and spreading a good deal of misinformation to laypeople. He is also extremely litigious, and has either sued or threatened to sue several cryptographers for what I view to be nonsense reasons. For some (at least myself), this makes precise language all the more important in topics he might have his eyes on.
So I both broadly agree with you for most topics, and also this particular topic requires a good deal more precision than most others in cryptography.
> Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs?
No, I'm saying that "hybrid KEM" or "chaining two KEMs" is very distinct from "encrypt twice". Confuse the two at your own peril.
> To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.
Encryption is reversible. If you have the key, you can decrypt. It's not encryption if you can't decrypt.
KEMs are their own class of algorithms. They combine an asymmetric encryption scheme with an all-or-nothing one-way transform (usually a key derivation function built on hash functions). It's the safest way to hold asymmetric encryption in practice (even not considering PQ; RSA-KEM beats RSA-OAEP in implementation safety).
Calling KEMs "encryption" is misleading to the point of malpractice. I will push back on conflating the two.
> Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection.
Your only defense-in-depth should be in delivering a strong pseudorandom ephemeral key over an untrusted network, and then using the tried-and-true AEAD constructions that we're already using today. Encrypt once. Do whatever you need to do to get the key exchanged securely.
I write a blog that very regularly covers applied cryptography. I deal with newbie confusion all the time. It's very important that we talk about these things correctly on forums like Hacker News comment threads so that the people learning from us won't get more confused.
both encrypting in parallel and encrypting in the second way you mentioned are bad ideas, and are far from being what is seriously being discussed when people talk about hybrid KEMs. Encrypting in parallel is explicitly IND-CPA insecure if one of the ciphers is broken. Your construction is IND-CPA secure, but quite inefficient, and would not fit into modern protocols.
If this was a typical cryptographic topic, this might be fine, and is how I would likely phrase things for an undergraduate cryptography course. Unfortunately, this is a topic that a certain cryptographer with a decently large public following has been spreading conspiracy theories (and slandering other cryptographers about) for a number of years now. So, discussions on this topic often come from a place where the audience is misinformed, and more care is required in grounding the discussing in what is actually being discussed/considered.
# You kind of have to define this since most libraries don't have it
def classic_kem(pk):
[eph_sk, eph_pk] = classic_keygen()
d = classic_shared_secret(eph_sk, pk)
return hash(d + eph_pk + pk), eph_pk
# Two pieces ...
[ss1, ct1] = classic_kem(pk1)
[ss2, ct2] = postquantum_kem(pk2)
# ... combine into one:
# note: for some KEMs, ct1 and/or ct2 can safely be omitted
shared_secret = hash(ss1 + ss2 + ct1 + ct2)
ciphertext = symmetric_encrypt(plaintext, shared_secret, context)
send_to_other_party(
ct1,
ct2,
ciphertext
)
This sounds more complex, but I'm just filling in the details implied by your pseudocode and making it at least 2x as fast.
If you mean "doing two different KEMs and then securely combining them", then just say that. "Hybrid KEM" is short enough and distinct from other verbage.
"Encrypt" means something specific, not just the vague use of cryptography.
Trying to bridge this a bit since I'm closer to a layperson in this area.
Symmetric encryption does not need a quantum computer alternative, nor do we need a post quantum hashing algorithm. We may need larger keys and larger outputs from the existing algorithms, but that really depends on the level of paranoia.
It is the asymmetric keys that need post quantum replacement.
So I'm guessing the change to your proposed pseudocode you would have two derivation algorithms based on two input asymmetric keys - one post quantum and one classical. You would get from these two separate symmetric keys. You would then layer encryption using each of them, encrypting the cipher text output from the first with the second.
You can however just combine the two derived symmetric keys together to create a single symmetric key, and encrypt once. That is what hybrid algorithms propose.
It's up to the researcher to make the call. Maybe they feel that it's best to disclose to bring attention to the MSRC problem - arguably, that'll be massively better for security longer term vs a point in time vuln disclosure.
Because you think that current models can, in a practical sense, find an infinite number of vulnerabilities, or you think that they can find so many that it isn't possible to fix them?
In other words: do you think that the impossibility lines in exhausting the number finds or does the impossibility lie in fixing them?
In either case, do you think that this was also true pre-AI? That is to say: it was not possible to, given some set of practical resource constraints, find and fix all the vulnerabilities that a similarly-resourced group would find?
If so, then would you say that you just fundamentally don't believe in secure software and the only defense is lack of attention?
I think that there are, practically, infinite vulnerabilities in common and critical software - browsers, operating systems, etc. So discovering all of them is not tractable, and even if we 100x our rate of discovery it won't matter.
> In either case, do you think that this was also true pre-AI? That is to say: it was not possible to, given some set of practical resource constraints, find and fix all the vulnerabilities that a similarly-resourced group would find?
Yes.
> If so, then would you say that you just fundamentally don't believe in secure software and the only defense is lack of attention?
I believe in security software, few people are building it though and the majority of relevant attack surface is dogshit for security.
Squashing vulns via discovery is irrelevant to security. If we want safer software it has to be built to be safer.
1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs.
2. Anywhere you have `npm install` or `npm test` or anything where code executes, that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and test them, another to do any sort of publishing, signing, etc. If you use AI, add a skill / guidance to enforce this pattern.
3. If you use Github Actions, install the latest version of zizmor. It will significantly improve your posture.
(2) means that you are no longer "wormable", which is a massive part of the problem that we have today. (1) gives companies more time to respond to the attacks.
There are some vendors in this space that you can and should evaluate as well.
lol yeah I thought of that as typing but figured I'd avoid the complexity. "latest version" means, give or take, whichever the latest one was that contained a bunch of new rules around supply chain stuff.
Exactly, popular AI coding harness (OpenCode/KiloCode) downloads random npm packages in the background without you knowing. What's worse is the devs don't care.
Should we instead of these cooldowns just run builds in isolated contexts?
I’m running a maven proxy locally. All builds happen inside containers. I only use public repos for python, npm, and go. So these builds happen also in containers but don’t need a repository proxy.
> Should we instead of these cooldowns just run builds in isolated contexts?
I'd suggest both. Cooldown for 1-2 days is very cheap and you likely won't even notice it, so it's quite harmless and from what I've seen even just 24 hours is enough to let security companies pick up malware.
It's also the standard, and by far it's the contrast to not allow this. pnpm has a massive advantage of being the non-standard package manager, npm does not have that - what do you suggest that npm does?
It could require a 48 hour cooldown period on any package update that wants to add an install script that didn't have one before, and has a certain number of downloads. And it could publish the list of these so security researchers have an opportunity to scan them.
It could add an optional key to package.json that allows someone to whitelist which packages can run install scripts.
It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI; (2) this hardened package status would be public, and (3) a developer could set a flag in their package.json that causes any npm action to act as if all non-hardened packages had frozen versions.
You realize that "dependency cooldowns" as a popular concept are extremely new, right? npm manages the installation of dependencies for millions upon millions of users across the globe.
> It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI;
Great, they did this.
> And so much more.
This shit takes time. Yes, they should have done this on day 1. Acting like any of this is easy to retrofit is just nuts though.
What is being said is that a new flag like '--minimum-release-age' would take, realistically speaking, tops 4 hours to implement (without AI assistance), plus a good 1 week of thorough testing, and maybe a 1 month period of progressive deployment. Come on, let's give it a total of 1.5 months, for good measure.
Of course this should have been started since the beginning of the major recent stream of supply chain attacks, circa 2024 or 2025... but even assuming the most backwards calendaring possible -starting after the last bug compromise (Axios, on March 31st)- that new flag should have already been shipped a couple weeks ago.
Shit does take time, but where there's a will there's a way, and nobody buys that this shit would take that much time.
Not infra, but final product. I know, corporations move slow. But when there is a critical issue, and an actual desire to solve it from someone in a suit, suddenly turns out that the cogs were always able to speed up and move fast...
You're probably not getting much Creatine from your diet, definitely not supplement levels. I don't think energy drinks have it, maybe pre-workouts. Creatine doesn't dissolve well afaik so it's rare in energy drinks.
1. That's because it's true. Creatine is extremely well studied and the studies pretty much all tell you that Creatine is safe, it's great at what we know it's great for, and it turns out it might be good for things we didn't expect. So when people all say "wow it's so amazing" they're right.
2. Because of (1) being so blatantly true, if you want to push some other supplement, it adds a lot of legitimacy to say "Creatine is the number one supplement, but here's something that takes things to the next level". Since the Creatine claim is well supported and you're already marketing to a group that's taking a supplement (Creatine), it is likely good marketing to piggyback on that.
But this doesn't change the fact that Creatine is shockingly well supported as a supplement.
For me, besides creatine which has been genuinely transformative at age 50, I've gained a lot more from the stuff I've dropped (dairy milk, ~2/3 of my caffeine (mostly by drinking reduced-caff coffee or tea and eliminating soda), sweets of course) than stuff I've added. But of the latter, I'd say fiber and fruits have been the biggest additions, partly in themselves and partly that they make it easier to avoid the bad stuff. I tried experimenting with a few other supplements, but most of them were meh at best.
So, "take things to the next level" with some pears and oatmeal and chia seeds! Now I just need a sponsor.
There are a number of studies on the topic of varying quality but I think that's besides the point.
> It’s called a loading phase
This is not about a loading phase. "It's called a loading phase" indicates that the reason you would take high doses is for the muscular saturation that some people think is required. You're right that you can absolutely skip the loading phase, but that's not the point. The point is that you would take the higher dose for the cognitive effects.
reply