Closed mefsantos closed 3 years ago
If true, this again should fail somewhere.
Similarly to issue #14 I believe they are not covered by any of the unit tests, since the unit tests only cover KDF and AEAD, not the KEM's key pair generation and encapsulation
Ok, so this is actually fine. The result of the DH call here is 64 bytes for P256 (X and Y). But we only care about the X coordinate with 32 bytes. The check here is only a sanity check to make sure that copying 32 bytes in the next line works and doesn't panic.
I guess the lack of documentation of ever crypt might mislead me, and since I am not implementing in RUST, I cannot test this easily.
However, it is also somewhat confusing that ecdh_derive
derives a valid P256 point with x and y coordinates, when in fact the purpose of the DH is to generate a symmetric key, which for P256 should be 32 bytes long, which is what the crypto package I am using does thus raising the error on my implementation.
The purpose of DH is not to derive a symmetric key. It generates a common point on the curve that can be used to derive a symmetric key.
I guess I was oversimplifying the process and probably misinterpreted the output of my crypto package. It probably already outputs the content to be used for the sym. key derivation. thanks for the clarification.
File: dh_kem.rs lines: 35~37 Code:
from Section 4. DH-Based KEM: P256 dh secret is 32 bytes long.