Wed, Feb 19
All changes are pushed to master.
Pushed the changes by the commit rC2039d93289db: mpi: Add MPI helper modular exponentiation, Least Leak Intended.
Fri, Feb 14
Use of mpi_cmp is now being fixed, by providing _gcry_mpih_cmp_lli function.
Along with that, we need to fix use of mpi_cmp_ui, since it's skips earlier depending its limbs.
diff --git a/cipher/dsa-common.c b/cipher/dsa-common.c index 170dce12..e010e182 100644 --- a/cipher/dsa-common.c +++ b/cipher/dsa-common.c @@ -25,6 +25,7 @@
Mon, Feb 10
And then, we need to use less leaky version of mpi_cmp (because mpi_cmp calls mpi_normalize, it's not good).
And this is for less leak for _gcry_dsa_modify_k:
This is needed before we remove leaks by mpi_add in _gcry_dsa_modify_k :
Commit rC35a6a6feb9dc: Fix _gcry_dsa_modify_k. is related, but it doesn't matter for usual compilers (it's an issue for MSVC).
Fri, Feb 7
This is needed for RFC6979 flag support.
Fri, Jan 31
The commit rC58c11aa8 is the improved version by k-ary exponentiation (while rC6dffd105e2e2 is 1-bit at a time) and using heap.
Jan 25 2025
I created https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7490/
The commit rC6dffd105e2e2 works for me.
It is a bit of exponent at time Montgomery exponentiation.
I don't put an optimization for the reduction as I don't know if it's OK for patent-wise (looks like expired, though).
Jan 22 2025
Jan 21 2025
Jan 17 2025
Re-open, so that I can pursue constant-time modular exponentiation.
Jan 15 2025
Dec 12 2024
Here are changes for gcry_md_open and its friends.
My idea in https://dev.gnupg.org/T7338#195529 doesn't work well when a function call is done multiple times.
Assuming SUCCESS, and marking all non-compliant places in the code works, and it would be good because libgcrypt so far maintains non-compliant path with rejection.
Dec 9 2024
Pushed the change for adding hash tests in rC7faf542f1573: fips,tests: Add t-digest.
Dec 6 2024
It seems that the internal API (as of 2024-12-06) is not enough.
Now, we have _gcry_md_hash_buffer function with the new FIPS service indicator.
It's used for public key crypto, too.
The compliance for hash function is a part of public key crypto, but not all.
A change for gcry_md_hash_* functions are pushed by rC3478caac62c7: fips,md: Implement new FIPS service indicator for gcry_md_hash_*..
It doesn't have tests with FIPS service indicator yet.
Dec 5 2024
New external API is by GCRYCTL_FIPS_SERVICE_INDICATOR and/or the new macro gcry_get_fips_service_indicator.
This change is pushed by rCf51f4e98930e: fips: Introduce GCRYCTL_FIPS_SERVICE_INDICATOR and the macro.
New internal API is introduced with T7340 by the commit rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.
Change is pushed by rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.
Dec 4 2024
Nov 14 2024
Nov 4 2024
Oct 24 2024
I created a branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/
Oct 16 2024
Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html
Oct 15 2024
Sep 17 2024
Sep 12 2024
Sep 6 2024
Sep 4 2024
Sep 2 2024
Use --enable-large-data-tests with configure and go out for a real long lunch
Aug 30 2024
As far as I know the practice to have separate -dev packages is very common among Linux distributions.
I wonder how common this practice of splitting development material into a separate file might be? It is in place at Alpine, since the file libgpg-error-dev exists. Once the related component is instaled, these messages/strings are printed:; output filtered:
checking for GPG Error - version >= 1.49... expr: warning: '^x-L': using '^' as the first character of a basic regular expression is not portable; it is ignored yes (1.49)
Aug 29 2024
Does alpine split the development files of libgpg-error into a separate *-devel (or similar) package like most other distros? If yes, then you need to install this development package.