I found the case of X.509, which also uses fixed length output for RSA-PSS and ECDSA: https://www.rfc-editor.org/rfc/rfc8692.html
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 22 2023
Jun 20 2023
Thank you for having a look into that! The proposed patch looks good. Should we have this change also in master?
Jun 19 2023
Here is a possible change (... to master, assuming it's good to support use case of RFC 8702):
diff --git a/cipher/keccak.c b/cipher/keccak.c index 22c40302..76e08cb5 100644 --- a/cipher/keccak.c +++ b/cipher/keccak.c @@ -1630,8 +1630,8 @@ const gcry_md_spec_t _gcry_digest_spec_sha3_512 = const gcry_md_spec_t _gcry_digest_spec_shake128 = { GCRY_MD_SHAKE128, {0, 1}, - "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 0, - shake128_init, keccak_write, keccak_final, NULL, keccak_extract, + "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 32, + shake128_init, keccak_write, keccak_final, keccak_read, keccak_extract, _gcry_shake128_hash_buffers, sizeof (KECCAK_CONTEXT), run_selftests @@ -1639,8 +1639,8 @@ const gcry_md_spec_t _gcry_digest_spec_shake128 = const gcry_md_spec_t _gcry_digest_spec_shake256 = { GCRY_MD_SHAKE256, {0, 1}, - "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 0, - shake256_init, keccak_write, keccak_final, NULL, keccak_extract, + "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 64, + shake256_init, keccak_write, keccak_final, keccak_read, keccak_extract, _gcry_shake256_hash_buffers, sizeof (KECCAK_CONTEXT), run_selftests
Reading RFC 8702, I realized that it defines the hash size in the use of CMS as: SHAKE128 : 32-byte SHAKE256 : 64-byte.
Jun 16 2023
I found this use case: RFC 8702
"Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)": https://www.rfc-editor.org/rfc/rfc8702.html
Another possibility for digest&sign API: it is possible to determine the length of required hash function by the underlining field Fp of the curve in use. Then, use this length instead. It's better than to (try to) get the length by _gcry_md_get_algo_dlen (for SHAKE, it's undefined).
Fixed in both of master and 1.10 branch.
Jun 15 2023
Jun 14 2023
I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.
I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.
Jun 13 2023
Another approach would be having "non-hash" algo for gcry_md_open.
Before adding FIPS support flag and tests, we need to modify implementation:
- Adding PCT check for EdDSA
- Adding support of gcry_pk_hash_sign/verify API for EdDSA
Thanks. I think that it was the oldest one: FSF used to be there in Cambridge, then moved to Tremont St. in Boston, and now it's in Franklin St.
Jun 12 2023
FYI, while going through the licenses again I noticed one of the pinentry files have even older address that so if you would do sed, this would not be matched:
Jun 8 2023
I'm going to add selftest of EdDSA with test vectors from RFC 8032.
Jun 1 2023
They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.
Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:
My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.
May 31 2023
May 30 2023
Let's schedule that for 2.6
May 16 2023
Just let me note that we used to have such an API : the former gcry_ac_ functions. However, it turned out that they were more complicated to use.
May 5 2023
If you experience build problems on macOS see T6442
May 2 2023
I don't see a reason backing off the original commit. A fix for macOS is now available (rCfa21ddc158b5) and will be in the next release. No reason for other changes.
Apr 27 2023
Fixed for libgcrypt, updating copyright notices and license files.
Apr 23 2023
Here's fix for mode specific setkey clearing error code:
Apr 21 2023
There is still a buglet because in some modes the weak key error can be swallowed by other errors. A fix would be something like:
@jukivili Yes, please go ahead for both branches. Thank you.
Apr 20 2023
About error code. You need to use gcry_err_code(error_code) to get the GPG_ERR_WEAK_KEY value.
Apr 17 2023
Ok sorry, my bad, I have to use DES Keying option 2 to have 45 de ae ae e1 f4 6a 29, problem solved.
In T6451#169608, @gniibe wrote:Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.
Thank you for you responses! :)
I'll add documentation about GCRYCTL_SET_ALLOW_WEAK_KEY which was missing from be original commit.
tests/basic now actually fail because setkey not returning GPG_ERR_WEAK_KEY for weak keys with GCRYCTL_SET_ALLOW_WEAK_KEY.
That's right. With GCRYCTL_SET_ALLOW_WEAK_KEY, setkey still returns GPG_ERR_WEAK_KEY when weak key is detected. However, cipher handle can still be used as if setkey succeeded.
Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.
Apr 16 2023
Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.
Apr 14 2023
Apr 13 2023
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Fixed in 1.10.2.
Apr 12 2023
This problem was introduced by commit cf10c74bd9d5aa80798f1c0e23a9126f381b26b3. Perhaps that change should be backed out in the interim so that a portable fix can be considered for the original issue?
It is a bit complicated. Let me describe the situation.
Actually Linux already returns ENOSYS on older kernels where there is no getrandom libc call. Thus returning ENOSYS if we don't have the libc version of that syscall (i.e. getrandom) in FIPS mode seems to be the Right Thing to do. My whole comment was about fips mode - it does not make much sense to enable FIPS mode if the system is not appropriate for it.
I see, your issue is with the use of getrandom for FIPS. I understand now.
ENOSYS is POSIX. My point is that: getrandom was introduced in Linux kernel with flags for particular purpose (differentiate use of /dev/random and /dev/urandom), but that feature has gone.
But, for FIPS behavior, RHEL and related OS use (possibly, some would say misuse) getrandom with GRND_RANDOM. This use is RHEL specific (not for other GNU/Linux). Use of getrandom is non-POSIX.
In T6442#169419, @gniibe wrote:Returning ENOSYS is too strict, in my opinion; It doesn't work for machines other than CentOS/Fedora/RHEL.
Returning ENOSYS is too strict, in my opinion; Because the code in question doesn't work for machines other than CentOS/Fedora/RHEL. For other machines, it would be natural to just rely on getentropy (rather standard call).
Apr 11 2023
What Werner wrote was also my thought. If getrandom is mandatory for FIPS, then it must not be possible to disable it silently.
What about
Apr 10 2023
Fixed in libgcrypt 1.10.2.
Tested. I applied the above diff to libgcrypt-1.10.2, and it builds and runs.
Thank you for the report.
Here is the git diff that I used:
Apr 8 2023
I just ran into this, too, on macOS.
Apr 7 2023
Fixed in 1.10.2.
Apr 6 2023
In T6388#168750, @gniibe wrote:Thank you for the bug report.
I see your problem. We need to improve the patch, as we cannot use Bash-only feature in configure.
[...]
That is, prefer possible_libdir1 when not used. Please test this.
Apr 4 2023
Fixed in master and 1.10 branch.
Apr 3 2023
Your quick support solve my problem, I am thanking you :)
Bye bye
I added a remark to the print function. Thanks for the suggestion.
You are right, w.y should be "00039E2C9AEC146C5799651C42691A3E35E291B6BC45FF079DDA3E70E709BF33".
Can you please share the expected result with us? Note that Libgcrypt strips leading zeroes except when it is required to keep the value positive.
Mar 25 2023
@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:
Mar 24 2023
@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350
Pushed the change.
Mar 23 2023
Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).
Mar 22 2023
Thank you for the bug report.