search

chipsalliance / caliptra-rtl

HW Design Collateral for Caliptra RoT IP
Apache License 2.0
75 stars 38 forks source link

Adding ECDH feature to ECC engine #577

Closed mojtaba-bisheh closed 2 months ago

mojtaba-bisheh commented 2 months ago

Added ECDH feature to ECC block Updated smoke tests to cover ECDH fixed issue #556

bluegate010 commented 2 months ago

Could this PR add some documentation on exactly what key derivation flow is being used to generate the final shared secret? I see the test code using an IV and nonce; how are those being used to derive the shared secret? Is there a pointer to some NIST document that this implementation is following?

Specifically, I'm trying to gauge whether this implementation will gel with https://www.rfc-editor.org/rfc/rfc9629#section-5

mojtaba-bisheh commented 2 months ago

Could this PR add some documentation on exactly what key derivation flow is being used to generate the final shared secret? I see the test code using an IV and nonce; how are those being used to derive the shared secret? Is there a pointer to some NIST document that this implementation is following?

Specifically, I'm trying to gauge whether this implementation will gel with https://www.rfc-editor.org/rfc/rfc9629#section-5

This PR only takes care of classic ECDH without KEM operation. any required changes for hybrid operation will be added later

bluegate010 commented 2 months ago

Could this PR add some documentation on exactly what key derivation flow is being used to generate the final shared secret? I see the test code using an IV and nonce; how are those being used to derive the shared secret? Is there a pointer to some NIST document that this implementation is following?

Specifically, I'm trying to gauge whether this implementation will gel with https://www.rfc-editor.org/rfc/rfc9629#section-5

This PR only takes care of classic ECDH without KEM operation. any required changes for hybrid operation will be added later

ECDH is a KEM. Hybrid is not required.

mojtaba-bisheh commented 2 months ago

Could this PR add some documentation on exactly what key derivation flow is being used to generate the final shared secret? I see the test code using an IV and nonce; how are those being used to derive the shared secret? Is there a pointer to some NIST document that this implementation is following?

Specifically, I'm trying to gauge whether this implementation will gel with https://www.rfc-editor.org/rfc/rfc9629#section-5

This PR only takes care of classic ECDH without KEM operation. any required changes for hybrid operation will be added later

ECDH is a KEM. Hybrid is not required.

section 1 of RFC9629 describes KEM that needs ciphertext (ct) to be passed to the recipient. ECDH does not have encapsulate/decapsulate operations. this PR implements section 5.7.1.2 of SP800 56A https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf

bluegate010 commented 2 months ago

ECDH is a KEM. Hybrid is not required.

section 1 of RFC9629 describes KEM that needs ciphertext (ct) to be passed to the recipient. ECDH does not have encapsulate/decapsulate operations. this PR implements section 5.7.1.2 of SP800 56A https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf

Thanks. I overreached when I said ECDH is a KEM - it's an ingredient, sure.

I perused section 5.7.1.2 of SP800 56A, and I see it describes an operation that computes an output based on domain parameters, a public key, and a private key. I don't see anything involving a nonce or IV. Yet, it appears from the tests in src/integration/test_suites/libs/ecc/ecc.c that a nonce and IV are part of the interface being added in this PR. Hence my questions as to what the implementation is doing with those arguments.

mojtaba-bisheh commented 2 months ago

ECDH is a KEM. Hybrid is not required.

section 1 of RFC9629 describes KEM that needs ciphertext (ct) to be passed to the recipient. ECDH does not have encapsulate/decapsulate operations. this PR implements section 5.7.1.2 of SP800 56A https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf

Thanks. I overreached when I said ECDH is a KEM - it's an ingredient, sure.

I perused section 5.7.1.2 of SP800 56A, and I see it describes an operation that computes an output based on domain parameters, a public key, and a private key. I don't see anything involving a nonce or IV. Yet, it appears from the tests in src/integration/test_suites/libs/ecc/ecc.c that a nonce and IV are part of the interface being added in this PR. Hence my questions as to what the implementation is doing with those arguments.

The IV is utilized as a source of randomness for the SCA countermeasure and does not alter the output. The inclusion of the nonce was an error due to a copy-paste from the key generation operation. I have removed the nonce from the smoke tests and will include a description of this mode in the specification.