@gniibe Thanks!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jul 28 2022
Jul 25 2022
Jul 22 2022
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.
Jul 21 2022
Jul 18 2022
Thank you.
Jul 13 2022
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.
Jul 12 2022
Jul 7 2022
Thank you for your report. That's my badness (forgetting to implement in pk_verify_md function).
Jul 6 2022
For the record, the valgrind trace for the crash is:
Thanks. Applied. Also, fixed about a warning for ChaCha20.
Jul 5 2022
Here's another one related to this: https://lists.gnupg.org/pipermail/gcrypt-devel/2022-July/005344.html
Jul 1 2022
Applied and pushed.
The last patch is related to FIPS, so, I add the FIPS tag.
Jun 28 2022
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:
Jun 24 2022
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.
Jun 22 2022
Jun 16 2022
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
Jun 15 2022
Thanks! Interestingly didn't seem to work with 1.9.x but it does with 1.10x. Maybe I made some error when testing.
Jun 12 2022
Patch applied to master with small changes.
Jun 7 2022
I can only find this one: https://github.com/patrickfav/singlestep-kdf/wiki/NIST-SP-800-56C-Rev1:-Non-Official-Test-Vectors
Jun 3 2022
Thanks @jukivili , Here is the changelog,
Thanks for updated patch. I'm travelling next week and have time to check it closely only after I'm back. On quick glance, it looks good. What is also needed is the changelog for git commit log.
Jun 2 2022
Thanks @jukivili. I have never thought of interleaving with interger poly1305 operation and that's a good suggestion. Will think about that one.
Jun 1 2022
I meant interleaving integer register based 1xPoly1305 with 8xChacha20 as is done for 4xChacha20 in cipher/chacha20-ppc.c (interleaved so that for each 4xChaCha20 processed, 4 blocks of 1xPoly1305 is executed). Quite often microarchitectures have separate execution units for integer registers and vector registers and then it makes sense to interleave integer-poly1305 with vector-chacha20 as algorithms do not end up competing for same execution resources. Interleaving vector-poly1305 and vector-chacha20 is not likely to give performance increase (and likely to run problems with running out of vector registers).
HI @jukivili , Thanks for the updates. For f14-f31 registers that was my mistake that did not think floating point will be used. Will correct that. For poly1305, it can be used on ARCH_3.0 so checking use_p10 doesn't seem to be necessary but I can include that as well.
May 31 2022
Also applied to 1.10.
Applied and pushed.
I learned that it's now called "OneStep KDF" in SP 800-56Cr2.
It's "SSKDF" in OpenSSL (Single Step KDF, perhaps).
May 28 2022
Problem is that new assembly is using VSX registers vs14-vs31 which overlap with floating-point registers f14-f31. f14-f31 are ABI callee saved, so those need to be stored and restored.
Tested patch with small change so that HWF_PPC_ARCH_3_00 is used instead of HWF_PPC_ARCH_3_10. Building bench-slope with "-O3 -flto" makes bug in new implementation visible. Without new implementations bench-slope is ok (testing with QEMU):
$ tests/bench-slope --disable-hwf ppc-arch_3_00 cipher chacha20 Cipher: CHACHA20 | nanosecs/byte mebibytes/sec cycles/byte STREAM enc | 2.35 ns/B 405.0 MiB/s - c/B STREAM dec | 2.32 ns/B 410.7 MiB/s - c/B POLY1305 enc | 2.46 ns/B 388.0 MiB/s - c/B POLY1305 dec | 2.34 ns/B 408.1 MiB/s - c/B POLY1305 auth | 0.238 ns/B 4003 MiB/s - c/B
May 27 2022
-O2 problem with bench-slope seems strange. Does problem appear after this patch is applied?
May 26 2022
May 23 2022
In T5975#158113, @werner wrote:I can imagine thar there are use cases for this. Thus I see no problems for the first part.
The second part is imho not a good idea. Libgcrypt is a building block for all kind of software and there are for sure legitimate reasons to use rsa512 (MCUs, short living keys, etc). Thus I think that the decision on the key size should be done by the software using libgcrypt.
May 19 2022
Pushed the change (master and 1.10).
At first, we need to add/enhance new API for KDF in libgcrypt. Currently, the term "KDF" in libgcrypt is used with narrower focus, that is, only for password->key KDF.
May 17 2022
I do not claim I understand anything of this assembler syntax :)
Lets implement it for 2.3
For the second, I wonder if newer xlclang++ compiler works with 1.9.
Thank you for the bug report.
Pushed the change.
May 16 2022
Thanks for your confirmation.
May 14 2022
Okay, confirmed: I was just wrong and the build failure was only ever with --disable-asm (i.e. the log in this bug is the only relevant one). Patch works.
May 13 2022
Ok. Thank you for the clarification. I will drop the second part and keep only the FIPS change in the patch. Merge request already updated.
Thanks. Should be applied.
I can imagine thar there are use cases for this. Thus I see no problems for the first part.
May 12 2022
May 11 2022
May 10 2022
Pushed the change. Also, it's backported to 1.10 branch.
Thanks for creating this ticket. I'll reply.
libgcrypt 1.10 is out with the API change for Windows, and we don't see any report (yet).
Pushed the change to master.
May 9 2022
GCC 11.3 and GCC 12.1 are out with the fix.