2

After reading this question about the possibility of using DH key exchange for multiple parties I went looking for a (C) library able to do this and found none.

(I find it hard to believe there is no library for this, and my assumption is I'm looking in the wrong place.)

Are there libraries able to reach DH key agreement from three or more parties (ideally, with ECDSA); or is this theoretical and not used in practice?

Daniel
  • 141
  • 1
  • 8
  • 1
    Are you looking for unauthenticated 3-way (EC)DH or for authenticated 3-way (EC)DH, ie do (some of) the parties have public key certificates / trusted public keys (or a pre-shared key for that matter)? – SEJPM Nov 12 '17 at 16:39
  • @SEJPM The parties have only a hard-coded secret key each (all different) and cannot write to disk; on boot, that secret key is the only thing they have. My plan was to follow this approach to use that secret to seed a PRNG and then use the PRNG in the creation of deterministic public keys. (I need deterministic public keys because the shared secret should always be the same.) Those public keys can then be used to do key agreement with DH. Short answer: This is for unauthenticated EC(DH). – Daniel Nov 12 '17 at 18:29
  • 1
    I'd use a KBKDF such as HKDF instead of the PRNG and then use the answer to create a ECDH private key, from which you can derive a public key in a standard way. Note that if you can somehow trust that public key then you could create authenticated-DH as well, as the public key would be deterministic. You can then use an ephemeral key (or a static-static DH scheme) for a central server. After establishing the connections you can always distribute a session key I suppose. For non-authenticated DH you would normally use a non-deterministic, ephemeral key, not a static key from a specific seed. – Maarten Bodewes Nov 13 '17 at 14:26
  • @MaartenBodewes Could you elaborate on what you meant by using a KBKDF to create a ECDH private key, do you mean using the output of the KBKDF directly as private key? There is an initial setup phase in a trusted environment, so it is doable to place trust in the public keys. I'll look into static-static DH (starting with RFC 6278 it seems). – Daniel Nov 13 '17 at 15:47
  • 1
    Yes, that was what I meant with that. Often PRNG's are seeded initially with a system seed and really specifying the exact formula to derive the keying material can be tricky. There may even be differences between asking for e.g. 2 x 16 bytes or 32 bytes in one go. Therefore a KBKDF with user definable output size is a good replacement; it literally is build for such purpose. And since the private key of ECC is simply random bytes in the first place, you can simply use the output directly. – Maarten Bodewes Nov 13 '17 at 18:50

0 Answers0