Concat KDF in IETF draft supported in libsodium?

[coder5876]

In the IETF draft "Chacha derived AEAD algorithms in JOSE" there is mention of a "Concat KDF" used by the "ECDH-ES" algorithm.

In the libsodium library there is high-level key exchange functionality which produces a shared secret that is recommended to use in the libsodium function crypto_aead_chacha20poly1305_ietf_encrypt.

The question is, does the above libsodium key exchange function use the referenced "Concat KDF", so that libsodium can used out of the box for the IETF standard "ECDH-ES" Diffie-Hellman functionality?

[OR13]

https://github.com/panva/jose/blob/078109803a62804db66b1192014de359b0b0dfcd/README.md#electron-support

https://github.com/potatosalad/erlang-jose#curve25519-and-curve448-support

I gather one could probably hack these implementations ^ to determine if thats the case... The erlang one uses libsodium directly.

I for one am getting a bit tired of verifying that custom implemented JOSE libraries match standard ones / are interoperable.

[tplooker]

From minimal-cipher it appears they use scalar-multiple to derive the secret with x25519 keys, then the resulting key is derived through the concatenation performed here using the secret. However from the doc's on lib sodium its pretty unclear whether the new API you reference above is equivalent to the old one, this is the only commentary they offer

For earlier versions of the library that didn't implement this API, the X25519 function is accessible directly using the crypto_scalarmult_*() API.

[kdenhartog]

@gamringer or @baha-sk may be able to provide better insights into this.

[gamringer]

To answer the original question: No.

The KDF used in JOSE specs in the Concat KDF defined in section 5.8.2.1 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf, while libsodium uses Blake2b as rx || tx = BLAKE2B-512(p.n || client_pk || server_pk).

My draft uses the ConcatKDF for the purpose of continuity with the other JOSE spec documents.

You can see my example for how to compose the various libsodium functions here: https://github.com/gamringer/php-authcrypt, or more specifically here: https://github.com/gamringer/php-authcrypt/blob/master/src/Crypt.php

[tplooker]

@gamringer thanks, just so I understand the equivalence here a little better are they using Blake2B-512 as the key wrapping alg? Or as the replacement for deriving Z e.g scalar-multiple the secret that is then combined with other information like in the Concat KDF definition?

[gamringer]

Sodium uses Blake2b to derive the CEK from Z. It serves the exact same function as the ConcatKDF in the jose specs, with the exception that in the sodium case with Blake2b-512, they generate 2 CEKs. One for sending from the client to the server and the other for sending from the server to the client.

[tplooker]

Thanks, appreciate it!

[baha-ai]

My draft uses the ConcatKDF for the purpose of continuity with the other JOSE spec documents.

You can see my example for how to compose the various libsodium functions here: https://github.com/gamringer/php-authcrypt, or more specifically here: https://github.com/gamringer/php-authcrypt/blob/master/src/Crypt.php

The Go equivalent of ConcatKDF key derivation function for the above PHP example is found here: https://github.com/hyperledger/aries-framework-go/blob/v0.1.0/pkg/internal/cryptoutil/utils.go#L146

It does not use libsodium, it uses GO Jose library that implements JOSE specs.

The full DIDComm Pack/Unpack functions matching this PHP example in Go is found here: https://github.com/hyperledger/aries-framework-go/blob/v0.1.0/pkg/didcomm/packer/jwe/authcrypt/pack.go

[coder5876]

Thanks for the input @gamringer @Baha-sk!

It seems also that the JOSE javascript library implements the ConcatKDF here:

https://github.com/panva/jose/blob/master/lib/jwa/ecdh/derive.js

Unfortunately that library does not support X25519 (since it uses the core Node crypto library which does not support X25519).

It would be nice if the above library exposed doing the ConcatKDF on the already computed Z value (i.e. the result of elliptic curve scalar multiplication). If that was exposed then we could use a different library to compute the scalar multiplication and use that Z value in the Jose library.

[panva]

I for one am getting a bit tired of verifying that custom implemented JOSE libraries match standard ones / are interoperable.

@OR13 if a library implements the test vectors from RFC7520 in its test suite there's no reason for it to not be interoperable.

Unfortunately that library does not support X25519 (since it uses the core Node crypto library which does not support X25519).

@christianlundkvist i've just released two plugins, one for backfilling x25519 ECDH-ES using libsodium, the other for @gamringer's draft

https://github.com/panva/jose-chacha https://github.com/panva/jose-x25519-ecdh

When both used (in this order) one can do { "alg": "ECDH-ES+XC20PKW", "enc": "XC20P" } with an OKP X25519 curve key. libsodium's crypto_scalarmult is used to derive the shared secret that then goes into ConcatKDF.