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.
ss1, ct1 = KEM1(pk1)
ss2, ct2 = KEM2(pk2)
secret = Combiner(ss1, ss2, [ct1, [ct2]])
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.
The idea would be:
key = get_key()
classic_key = derive_key(key, "domain-classic")
qc_key = derive_key(key, "domain-qc")
ciphertext_a = classic_encrypt(plaintext, classic_key)
ciphertext_b = qc_encrypt(ciphertext_a, qc_key)
I think this is different from what you wrote but I can't really tell.FWIW I am not advocating for "encrypt twice" at all, I'm just trying to understand.
Why would you take the stupidest possible interpretation of that person's comment?
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).