How does the Concat KDF work?

Question

I am writing an application using JSON Web Encryption with ECDH using the X25519 Curve. The RFC says that ECHD-ES derived secret is run through a Concat KDF.

Given that many cryptographers seem to be bashing JWT and the JOSE standard for having too many options to shoot yourself in the foot I want to make sure I am not using an insecure mode of JWE.

RFC 7518 JSON Web Algorithms (JWA) states

Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES)

This section defines the specifics of key agreement with Elliptic
Curve Diffie-Hellman Ephemeral Static [RFC6090], in combination with
the Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A].

Following the reference leads to 152 page NIST PDF that I don't fully understand. I am a developer not a cryptographer. I am using the Nimbus JOSE library in my application and it has an implementation of ContcatKDF.java derive function there.

Questions:

• How does Contcat KDF work?
• Is it considered secure?

It derive function gets called with SHA-256 as the hash function concatKDF = new ConcatKDF("SHA-256"); from ECDHCryptoProvider.java which computes the number of cycles using this.

^{Moderator note: crypto-SE is not a code review site. The code was replaced by links to the code. It's still here if needed.}

Answer 1

Looking at it closely, the linked RFC formally references SP800-56Ar2 section 5.8.1, which buries in 5.8.1.2.1:

Note: When the single-step KDF specified in Section 5.8.1.1 is used with H = hash as the auxiliary function and this concatenation format for OtherInfo, the resulting key-derivation method is the Concatenation Key Derivation Function specified in the original version of SP 800-56A. (emphasis mine)

Based also on this, I guess that when the authors of the RFC wrote "Concat KDF, as defined in Section 5.8.1 of [NIST.800-56A]", they had in mind SP800-56Ar1 section 5.8.1, titled "Concatenation Key Derivation Function (Approved Alternative 1)", which is what I would use if I had to implement the thing. I suggest to ignore the RFC's reference to the aforementioned SP800-56Ar2, which seems to be a well-intentioned but unfortunate change; as well as the currently applicable SP800-56Ar3.

Big picture: that KDF hashes the concatenation of a 4-byte counter initialized at 1 (big-endian), the shared secret obtained by ECDH, and some other information passed as input. The counter is incremented and the process is repeated until enough data was produced. The concatenation of the hashes, truncated as needed, forms the output to be used as key. Except for the data hashed and the position of the counter (at start rather than end), this is similar in principle to MGF1 of RSASSA-PSS and RASAES-OAEP in PKCS#1v2.2.

If the hash is SHA-256 as now in the question, as well as in this code which claims to successfully implement something (without stating clearly against what it is tested), I do not see that this KDF has an exploitable weakness of cryptographic nature in the context. This is not a statement about code.