3
$\begingroup$

I'm designing a system where my hardware piece uses an ATECC608A to calculate an ECDH shared secret in order to exchange data with a HSM in the cloud.

For some unknown reason, whenever the first nibble of the shared secret generated by the device is zero, the correspondent shared secret generated by the HSM is shifted 4 bits.

ATECC output :  0D E8 A2 9D 8F .....
HSM output   :  DE 8A 29 D8 FE .....

The HSM never generates a shared secret starting with 0, while the ATECC generates it at a rate statistically compatible with 1:16.

My questions are:

  1. Is it mathematically possible to generate a shared secret starting with 0x0n using ECDH? (My guess is "yes")

  2. Is there any rule or convention stating that a shared secret should be shifted so that the first nibble shall never be 0?

  3. Since I'm not the guy working on the HSM side, and don't know anything about it. Is it possible that there is some sort of configuration flag enabling or disabling the generation of shared secrets starting with nibble 0?

I don't believe there is a bug in such a widely used device, nor that at least two different software packages running on the HSM (as the HSM guy told me) are also wrong.

Added information: the generated shared secret is 32 bytes long.

Any ideas?

Thank you very much for any help.

Improve this question
$\endgroup$
4
  • $\begingroup$ How does the HSM output end? With a 0000 nibble, maybe? What's the size of the shared secrets? ECDH is not used much for HSM calculations. I would personally blame the HSM - what type of HSM are we talking about? It could well be the software that communicates with the HSM. Anyway: 1. Yes, 2. No, 3. No. $\endgroup$
    – Maarten Bodewes ♦
    Commented May 27, 2019 at 23:18
  • $\begingroup$ Thank you for your comments Maarten. I'll ask the HSM guy about the last nibble. $\endgroup$
    – Alexandre Meyer
    Commented May 27, 2019 at 23:41
  • $\begingroup$ The spec for ECDH the HSM should be using is nvlpubs.nist.gov/nistpubs/SpecialPublications/… . I strongly suspect a higher level protocol that serializes/wraps/transmits the values computed by the HSM to the source of your problem. I thought of ASN.1 DER "smallest possible number of octets", but that says nothing about nibbles. $\endgroup$
    – Z.T.
    Commented May 27, 2019 at 23:51
  • 1
    $\begingroup$ Note that if you consider the output of ECDH as a number then of course you cannot generate leading zeros (as a number doesn't have a standard representation in bits). Generally however we handle the shared secret as a statically sized enocded (unsigned, big endian) number, and that certainly can have leading zeros. So the leading bits issue depends on the encoding of the number. That still doesn't directly explain the shifting of the bits though. The only thing I can think about is a weird ASN.1 / DER BIT STRING representation of the shared secret. $\endgroup$
    – Maarten Bodewes ♦
    Commented May 28, 2019 at 0:00

1 Answer 1

Reset to default
1
$\begingroup$

1 - Is it mathematically possible to generate a shared secret starting with 0x0n using ECDH? (My guess is "yes")

Yes; the shared secret is the $x$ coordinate; approximately half of the values between 0 and $p-1$ (where $p$ is the prime that the elliptic curve is defined over) are possible; there's no reason to believe that the values with a top nybble of 0 are all impossible.

2 - Is there any rule or convention stating that a shared secret should be shifted so that the first nibble shall never be 0?

I've never heard of one.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.