Score:1

How is ECDH shared secret represented in SoftHSM

ve flag

I am working on implementing ECDH with some HSM. According to the theory behind ECDH, the generated shared secret is a point on the elliptic curve (x, y) which is exactly what is returned by the HSM.

But when I test with SoftHSM via PKCS#11 library, the ECDH function returns a symmetric key directly even with KDF parameter set to null. I did some research and found that some bytes of the shared secret is returned as the value of the symmetric key: https://github.com/google/boringssl/blob/master/include/openssl/ecdh.h#L82

However, I am confused how such operation can be performed on the shared secret if it is represented in the form of a EC point (x, y).

Does anyone know how SoftHSM handles ECDH with KDF parameter as null? Especially, what form is the shared secret in after being generated in SoftHSM but before being processed and put in a key object?

Thanks

Maarten Bodewes avatar
in flag
Usually the X, Y coordinates are encoded as unsigned, statically sized, big integer values and then concatenated. The bytes are then taken from the left hand side. If I had to guess that would be what a library does, but to be sure you'd have to look into the source code *or* test it with another library / key pair.
cn flag
Many ECDH implementations only compute one coordinate of the shared secret.
kelalaka avatar
in flag
https://github.com/opendnssec/SoftHSMv2
Maarten Bodewes avatar
in flag
@CodesInChaos Hey, glad you are still here! Yes, I wondered if I should have mentioned that that's another option, that only the X coordinate is used. But hey, when coming from the left hand side it hopefully doesn't make a big difference (it could of course one side uses just X for key derivation and the other X and Y).
Fan Zhang avatar
ve flag
Thanks @MaartenBodewes for the reply. I did look into the code of SoftHSM and it is kinda doing what you said, taking certain length from the generated secret. But I am confused how the generated secret gets transformed from an EC point to bytes. Are x and y transformed to bytes and concatenated or there is a specific method? For example, ECPublicKey is formed like tag + x + y. Thanks!
Fan Zhang avatar
ve flag
Thanks @CodesInChaos for the reply. If I have a generated secret as (64830192060261760049283727294808668110354933976341491567578109548061246609139, 59423428101938593951845145007294894818095890801518227616691263742277914054172) and want an AES128 key, you mean most implementations take the x coordinate and convert it into a byte array and then extract the first 128 bits of it? Thanks
Maarten Bodewes avatar
in flag
As indicated in the first comment, usually they are not transformed to DER encoding but kept to statically signed integers. It would be weird to encode the point with spurious data bytes, as you don't want to have the tag and length encoding as part of the symmetric key, you want mostly randomized data. A KDF would certainly help. Note that the Y coordinate can be calculated from the X coordinate, so it won't make much sense to include that within a key or in the input keying material of a KDF. This is why many implementations only take X rather than X and Y.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.