SIKEp434 can only be used to encapsulate a 16 byte (128 bit) shared secret key. Most encryption algorithms these days (specifically (X)ChaCha20) require a 256 bit key to be secure, especially in a post-quantum setting. I found this odd because from what I can tell, it would make SIKEp434 useless for key establishment since the key it establishes is too short, and hashing it to derive a 256 bit key wouldn't be much better as you can treat both the hash function and the encryption as one black box for Grover's algorithm to break, and since the input to this black box is 128 bits, we assume it's feasible to break. I'm probably missing something since it's more likely that I'm the idiot, but it got me thinking, and I came up with this scheme:

  1. Generate a 256 bit shared secret $S$ and split it into 2 halves, $A$ and $B$
  2. Encapsulate $A$ using SIKEp434, we'll call the ciphertext $E$
  3. Get $C = A \oplus B$
  4. Send $(E, C)$ to the other party
  5. Decapsulate $E$ to get $A$, get $B = A \oplus C$
  6. Concatenate $A$ and $B$ to get $S$

This would be much more efficient than concatenating 2 SIKEp434 shared secrets, or using SIKEp751, and would only increase the ciphertext size by 16 bytes. My reasoning behind why this seems secure is that $A$ acts like a one-time pad for $B$. We can even hash $S$ to prevent idiots from XORing it with something else and breaking the one-time pad, except this time since $S$ is 256 bits, Grover's wouldn't break it.

Is it actually secure? I assume it retains its IND-CCA security, is that right? Is there a better way? What am I missing above?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.