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.

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.

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.

Any ideas?

Thank you very much for any help.

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.