4
$\begingroup$

Using a sealed_box type construct (eg. tool like age[1]) with non-hybrid ECC.

Payload is encrypted to some recipient ECC public key.

In this scenario, the recipient public key remains secret.

Having nothing but the encrypted payload, can a cryptographically relevant quantum computer (CRQC) crack the ECC to obtain the symmetric key?

Would using the public key itself as an additional input to the KDF (which determines the symmetric key) help?

  1. https://github.com/FiloSottile/age
Improve this question
New contributor
Caliph is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
$\endgroup$

1 Answer 1

Reset to default
6
$\begingroup$

Can a CRQC crack ECC without a public key?

Actually, that depends on how ECC is being used.

The most obvious example is ECDSA; even if you don't give the adversary that public key, he can, with the signature and the message, recover the public key (within a few possibilities), and then use his fancy CRQC to break that.

On the other hand, if you're doing ECIES, that is, the message is $rG, \text{Enc}( \text{KDF}( rH ), \text{message} )$, he can't really - he could recover $r$, but without knowing $H$ (which is the public key), $rH$ could be any curve point, and so that's effectively symmetric crypto, which CRQC's are not good against.

Given that age doesn't document (at least from what I can find, and I'm not about to go about code spelunking) what it does internally, I wouldn't say which way it is. On the other hand, this reasoning works only if the recipient's public key is completely unknown - if the adversary has (say) 1000 public keys, and the recipient's public key is somewhere on this list, this reasoning doesn't work.

Improve this answer
$\endgroup$
3
  • $\begingroup$ So assuming that an additional KDF operation is cheap, it would be good practice to mix in the public key and not worry about it? Why isn't it standard? $\endgroup$ Commented yesterday
  • 1
    $\begingroup$ @Caliph usually the assumption is that the public key is, well, public. If you have a shared secret with the receiver, you can use symmetric cryptography. $\endgroup$ Commented 9 hours ago
  • $\begingroup$ @Caliph You should always include public keys in key derivation because it helps avoid attacks in general. This answer isn't about the KDF though; it's the fact you can't compute the shared secret because the recipient is unknown. Here is the spec for age. It's worth saying that age now supports hybrid ML-KEM-768. $\endgroup$ Commented 37 mins ago

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.