One nit that I overlooked initially is the memory leak, which is fixed with the following patch:

The specs https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf page 10 says specifically:

I've tested the different hw implementations (amd64, arm64, s390x) and they are all ok.

Thank you for your report.

My poor old laptop - its RAM will now have a hard time to run the huge tests ;-)

The test looks good. I hope I changed the API in all the hw optimized implementations.

Fix looks good to me. This could be tested with new long running test (tests/hashtest) that would allocate 4GiB+ pattern block for inputting to gcry_md_write.

TLS 1.3 requires much changes for NTBTLS.

Applied to master and 1.10 branch.

I realized that some AEAD cipher (including GCM) allows arbitrary length for IV.
But it's not good for the API of setup_geniv and geniv.

I pushed the change with documentation.

Thank you for your work on the proposal. I have two comments:

• Do we have some test vector, which can be used in the testsute to test the new API?
• We need to mention the new API in the documentation.

For the record, the changeset in the attached merge request is final and waiting for reviews.

Experimental branches:
https://dev.gnupg.org/source/libgcrypt/history/t4873/
https://dev.gnupg.org/source/ntbtls/history/t4873/

Should go into 1.10 too

@gniibe Thanks!

In the repo, for all related software, it's done.

Note that versions since 2020-11-07 to 2021-07-03 have major problem with non-POSIX shell, which doesn't support $(..) construct.

Thank you.

Reading through the report, the spec., and current implementation, I concluded that this is not a bug, thus, I'm closing this.

It will be in 1.10.2.

It will be in 1.10.2.

It will be in 1.10.2.

Applied to 1.10.

Thank you for your report. That's my badness (forgetting to implement in pk_verify_md function).

For the record, the valgrind trace for the crash is:

Thanks. Applied. Also, fixed about a warning for ChaCha20.

Here's another one related to this: https://lists.gnupg.org/pipermail/gcrypt-devel/2022-July/005344.html

Applied and pushed.

The last patch is related to FIPS, so, I add the FIPS tag.

Key length requirements for KDFs are specified in SP 800-131Ar2 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf), which is linked from SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) in section "6.2.1 Transitions".

FIPS 140-3 (https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-standards) points to SP 800-140Dr1 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140Dr1.pdf) to list acceptable "Security Parameter Generation and Establishment Methods". From this document, RFC 5869 (i.e., HKDF with the counter at the end) can be reached via two paths:

The change allows internal use of HMAC with shorter key.

Considering again, I concluded the patch above should be applied.
The use of SALT in HKDF may be not secret and there are valid use cases with no last or shorter salt. It's different to the use case of HMAC, where KEY is secret.

I pushed the change needed for GnuPG to t5964 branch.
See: https://dev.gnupg.org/rGc281bd94349e4f7997a89927aaa2c2f45004b902

Added HKDF implementation to master.

Applied to 1.10 branch.

didn't seem to work with 1.9.x