4

Given that public key security is very important in the Kyber KEM algorithm and if this is not observed, various attacks can be applied to the discovery of the Kyber key. The question is how to identify weak Kyber public keys (structurally, or In terms of implementation, or library and so on) and remove them from the list of public keys? Has this measure been thought about for post-quantum cryptographic algorithms?

Daniel S
  • 29,316
  • 1
  • 33
  • 73
R_Jalaei
  • 515
  • 2
  • 12

2 Answers2

3

On the encapsulator's side the public and private keys generated are recovered as part of the decapsulation process and then a check is run to ensure that they were legitimately generated (see step 8 of algorithm 18 in FIPS 203). This check should prevent the use of any key that is not overwhelmingly likely to be strong if a strong randomness source is used. In particular, it should inhibit structurally weak keys, implementation errors or malicious libraries (unless the check itself is supressed by a malicious library). Checking on the strength of the randomness source should probably be considered a separate issue, as it will likely have consequences beyond simply the generation of ML-KEM keys.

On the decapsulator's side, there is no check that the public and private keys are legitimately generated to satisfy any particular property. The most naive potential key weakness is that the private key has been compromised by some out of band mechanism which cannot be detected simply from inspection of the keys. This limits the efficacy of key checking and I think we're unlikely to see it until specific threats are identified in practice.

DannyNiu
  • 10,640
  • 2
  • 27
  • 64
Daniel S
  • 29,316
  • 1
  • 33
  • 73
1

Given that public key security is very important in the Kyber KEM algorithm

Well, yes - you need to ensure that the public key corresponds to the entity you want to establish keys with or send encrypted messages to. That is entirely correct.

But that's not what you meant.

I believe that you are referring to attacks where the attacker has control of the expanded private key, and modifies that to something illegal (and more vulnerable), and then the device under attack generates the corresponding public key.

However, if the attacker could modify the stored private key, then he could presumably either read the private key (and thus recovering it with no further effort on his part), or replace it with his valid private key (which he also knows).

It is unclear where the first attack (modifying the expanded private key) would be possible when we have to assume that the latter attacks (reading or replacing the private key) are not (because if they are, they're easier for the attacker and cannot be detected by studying the public key).

Or, if you were thinking of another attack scenario, could you spell it out?

poncho
  • 154,064
  • 12
  • 239
  • 382