The paper describes another problem: interoperability (or interpretation) of "ElGamal encryption", and its impact.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
May 20 2021
May 20 2021
May 18 2021
May 18 2021
Note: I believe this issue might affect multiple other GnuPG projects.
May 11 2021
May 11 2021
May 6 2021
May 6 2021
FWIW, I think that it is a Bad Thing to use unreleased stuff from 1.8 for Debian packages. Only released versions sshould be used or patches we explicitly made to fix a bug. At the very least Andreas should have asked upstream whether this commit should be used for Sid.
Also fixed in version 1.8: rCbd662c090bd4: ecc: Fix the previous commit.
Note that the handling e part uses standard MPI in 1.8 (while it is done by opaque MPI in 1.9).
Apr 28 2021
Apr 28 2021
The patch references the following bug:
Apr 26 2021
Apr 26 2021
Apr 20 2021
Apr 20 2021
• gniibe added a comment to T4900: OS X 10.12 and dyld: Library not loaded: /usr/local/lib/libgcrypt.20.dylib.
IIUC, with libgcrypt in LIBGCRYPT-1.8-BRANCH (not yet released) and libgcrypt 1.9.3, the build process works well (the problem with SIP has been handled).
Apr 19 2021
Apr 19 2021
• werner moved T5396: Remove USE_RANDOM_DAEMON support from libgcrypt from Backlog to For 1.10 on the libgcrypt board.
• werner moved T4894: FIPS: RSA/DSA/ECDSA are missing hashing operation from Backlog to For 1.10 on the libgcrypt board.
• werner moved T3269: (Constant-time) modular reduction from Backlog to For 1.10 on the libgcrypt board.
Apr 15 2021
Apr 15 2021
Thank you.
We also need to release memory for points.
Apr 13 2021
Apr 13 2021
saurik added a comment to T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.
I'm sorry I disappeared on this issue for two weeks; I just got reminded of it by seeing the e-mail with the status change. I've updated to the latest gcrypt (which is the commit with the patch, now pushed to the repository) and was able to upload this to Apple without it being flagged; thanks!
• gniibe changed the status of T5372: assertion failure mulm_25519: different sizes in Libgrypt 1.9 from Open to Testing.
• gniibe changed the status of T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt from Open to Testing.
Apr 12 2021
Apr 12 2021
Do we have CVE number assigned?
• gniibe changed the status of T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection from Open to Testing.
Apr 9 2021
Apr 9 2021
This would be difficult to set up for DSA. Remotely controlled
environment, asking signing same message, using deterministic
DSA... would be not that practical.
Apr 8 2021
Apr 8 2021
So, in my opinion, applying the patch for ElGamal exponent blinding is enough (for now).
For DSA, I had assumed similar attack could be effective.
Apr 7 2021
Apr 7 2021
Yes, will be fixed but it has no severity because the fault is actually by the caller.
Apr 1 2021
Apr 1 2021
• gniibe triaged T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt as Normal priority.
• gniibe added a comment to T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.
IIUC... Could you please try this patch?
diff --git a/random/rndlinux.c b/random/rndlinux.c index a7a78906..c20c5d4c 100644 --- a/random/rndlinux.c +++ b/random/rndlinux.c @@ -35,10 +35,13 @@ #if defined(__APPLE__) && defined(__MACH__) #include <Availability.h> #ifdef __MAC_10_11 +#include <TargetConditionals.h> +#if !defined(TARGET_OS_IPHONE) || TARGET_OS_IPHONE == 0 extern int getentropy (void *buf, size_t buflen) __attribute__ ((weak_import)); #define HAVE_GETENTROPY #endif #endif +#endif #if defined(__linux__) || !defined(HAVE_GETENTROPY) #ifdef HAVE_SYSCALL # include <sys/syscall.h>
Mar 31 2021
Mar 31 2021
Our tentative plan is:
• gniibe added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
I was wrong in my last comment. Escaping by another \ is needed.
Mar 30 2021
Mar 30 2021
We have two or three other open issue which I would like to address before a release. FWIW, release ticket is T5305.
• werner added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).
I already backported the above for Fedora so I am not in hurry now. But I believe others might hit the same issue.
@werner Can you comment about bugfix release?
saurik added a comment to T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.
In https://github.com/rust-random/getrandom/issues/38 they seem to have decided to use SecRandomCopyBytes on iOS, while in https://github.com/LuaJIT/LuaJIT/issues/668 they pushed https://github.com/LuaJIT/LuaJIT/commit/787736990ac3b7d5ceaba2697c7d0f58f77bb782 which I believe falls back to /dev/urandom. In both cases, they are only staring at iOS as an issue; though, it could be that using Rust at the same time as targeting an official macOS application are both rare enough to allow this to have gone two years without a rejection... making this weak_import hack not happen on iOS might be sufficient. If you do this, I recommend checking for TARGET_OS_IPHONE, not TARGET_OS_IOS, as (despite the somewhat hardware-specific sounding name) the former also encompasses tvOS and watchOS (which, if anything, will have stronger checks); I'd personally be satisfied with just some way of manually disabling getentropy by force, though (as I had been previously using ac_cv_func_getentropy=no).
So, I actually just filed an issue about this work: T5375, and then found this opposing task while following through on the various commits ;P... Apple actually forbids usage of getentropy in applications they publish to their App Store (citing ITMS-90338: Non-public API usage), and so there needs to be a way to disable this weak_import. FWIW, I'm not sure if this is only on iOS or on macOS as well (I haven't gotten around to trying to publish a macOS build with the new libgcrypt yet).
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
@gniibe Note that you also need to at least add the semicolons, as BSD sed is trying to parse "gp}" as substitution flags (which, honestly, makes more forward-compatible sense than GNU sed's behavior...).
• gniibe added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
Or, if we keep the code of newline (so that it will eventually support path with a space in future):
• gniibe added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
Thank you. Sorry for the use of GNU sed extension. It could be just a whitespace, if it's OK not to support path having a space.
sed -n -e "/^libraries/{s/libraries: =//;s/:/ /gp}") should work.
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
@gniibe OK, so... "worst case": I guess this worked? ;P
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
@gniibe Actually, I just realized that neither of the commands I provided work, as I failed to notice you were trying to also replace :'s with newlines (as I guess libraries from clang can return multiple paths). I'd momentarily edited my comment to just try to add back your colon replacement, before remembering you can't do that either: \n is a GNU sed extension. Hilariously, I'm always in contexts where I can assume I'm using bash (which isn't ok for configure), so I've never bothered to learn a technique that doesn't involve $'\n'... do you have a strategy for doing this replacement? :(
saurik updated the task description for T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
@gniibe Ah yeah, that was the commit I meant to reference when I said "--maybe caused by --", but then forgot to go back and fill in the commit hash ;P.
• gniibe added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
I wonder if this works in your use case:
diff --git a/m4/gpg-error.m4 b/m4/gpg-error.m4 index d910754e..aeedaf10 100644 --- a/m4/gpg-error.m4 +++ b/m4/gpg-error.m4 @@ -65,7 +65,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR], min_gpg_error_version=ifelse([$1], ,1.33,$1) ok=no
• gniibe added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
(To be clear, I also know enough about autoconf to not have been like, blocked from upgrading by this: overriding ac_cv_path_GPGRT_CONFIG worked, but I can't believe that's the intended way for someone to ensure they get the correct path for gpgrt-config ;P.)
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
@gniibe The problem is that the check seems to just find gpgrt-config from the path; like, I'm already passing --prefix and --host, but it is deciding to just arbitrarily pick up my system-wide copy of /usr/local/bin/gpgrt-config. Here's my entire configure invocation from that earlier failed build: note that the --prefix is the same as --with-gpg-error-prefix.
• gniibe triaged T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection as Normal priority.
We are in transition from old gpg-error-config to new gpgrt-config. <-- This is the cause, while I tried to cover most use cases.
The optimization introduced for curve 25519 and curve 448 en-bugged for usage of direct MPI.
Mar 29 2021
Mar 29 2021
• werner added projects to T5373: Using GCRY_THREAD_OPTION_PTHREAD_IMPL in a file compiled with Clang generates deprecation warning: libgcrypt, clang.
Yet another identify theft scam committed by clang.
• werner updated the task description for T5372: assertion failure mulm_25519: different sizes in Libgrypt 1.9.
• werner updated the task description for T5372: assertion failure mulm_25519: different sizes in Libgrypt 1.9.
Sorry to dig up an old report...
Sorry to dig up an old thread...
Mar 26 2021
Mar 26 2021
Mar 25 2021
Mar 25 2021
Thanks! Tested the above patches and now all the tests pass on the machine where I saw the failures.
Thanks for the report.
Mar 24 2021
Mar 24 2021
• werner shifted T5328: On the (in)security of Elgamal in OpenPGP from the Restricted Space space to the S1 Public space.
I have a minimal reproducer:
diff --git a/tests/basic.c b/tests/basic.c index 9a7e33cc..73ae01db 100644 --- a/tests/basic.c +++ b/tests/basic.c @@ -6346,11 +6346,152 @@ do_check_ocb_cipher (int inplace) "033ac4d13c3decc4c62d7de718ace802" "140452dc850989f6762e3578bbb04be3" "1a237c599c4649f4e586b2de" + }, + { GCRY_CIPHER_AES, 12, "0F0E0D0C0B0A09080706050403020100", + "BBAA9988776655443322110D", + "000102030405060708090A0B0C0D0E0F1011121314151617" + "18191A1B1C1D1E1F2021222324252627", + /* test vector for checksumming */ + "01000000000000000000000000000000" + "02000000000000000000000000000000" + "04000000000000000000000000000000" + "08000000000000000000000000000000" + "10000000000000000000000000000000" + "20000000000000000000000000000000" + "40000000000000000000000000000000" + "80000000000000000000000000000000" + "00010000000000000000000000000000" + "00020000000000000000000000000000" + "00040000000000000000000000000000" + "00080000000000000000000000000000" + "00100000000000000000000000000000" + "00200000000000000000000000000000" + "00400000000000000000000000000000" + "00800000000000000000000000000000" + "00000100000000000000000000000000" + "00000200000000000000000000000000" + "00000400000000000000000000000000" + "00000800000000000000000000000000" + "00001000000000000000000000000000" + "00002000000000000000000000000000" + "00004000000000000000000000000000" + "00008000000000000000000000000000" + "00000001000000000000000000000000" + "00000002000000000000000000000000" + "00000004000000000000000000000000" + "00000008000000000000000000000000" + "00000010000000000000000000000000" + "00000020000000000000000000000000" + "00000040000000000000000000000000" + "00000080000000000000000000000000" + "00000000010000000000000000000000" + "00000000020000000000000000000000" + "00000000040000000000000000000000" + "00000000080000000000000000000000" + "00000000100000000000000000000000" + "00000000200000000000000000000000" + "00000000400000000000000000000000" + "00000000800000000000000000000000" + "00000000000100000000000000000000" + "00000000000200000000000000000000" + "00000000000400000000000000000000" + "00000000000800000000000000000000" + "00000000001000000000000000000000" + "00000000002000000000000000000000" + "00000000004000000000000000000000" + "00000000008000000000000000000000" + "02000000000000000000000000000000" + "04000000000000000000000000000000" + "08000000000000000000000000000000" + "10000000000000000000000000000000" + "20000000000000000000000000000000" + "40000000000000000000000000000000" + "80000000000000000000000000000000" + "00010000000000000000000000000000" + "00020000000000000000000000000000" + "00040000000000000000000000000000" + "00080000000000000000000000000000" + "00100000000000000000000000000000" + "00200000000000000000000000000000" + "00400000000000000000000000000000" + "00800000000000000000000000000000" + "00000100000000000000000000000000" + "00000200000000000000000000000000" + "00000400000000000000000000000000" + "00000800000000000000000000000000", + "01105c6e36f6ac480f022c51e31ed702" + "90fda4b7b783194d4b4be8e4e1e2dff4" + "6a0804d1c5f9f808ea7933e31c063233" + "2bf65a22b20bb13cde3b80b3682ba965" + "b1207c58916f7856fa9968b410e50dee" + "98b35c071163d1b352b9bbccd09fde29" + "b850f40e71a8ae7d2e2d577f5ee39c46" + "7fa28130b50a123c29958e4665dda9a5" + "e0793997f8f19633a96392141d6e0e88" + "77850ed4364065d1d2f8746e2f1d5fd1" + "996cdde03215306503a30e41f58ef3c4" + "400365cfea4fa6381157c12a46598edf" + "18604854462ec66e3d3cf26d4723cb6a" + "9d801095048086a606fdb9192760889b" + "a8ce2e70e1b55a469137a9e2e6734565" + "283cb1e2c74f37e0854d03e33f8ba499" + "ef5d9af4edfce077c6280338f0a64286" + "2e6bc27ebd5a4c91b3778e22631251c8" + "c5bb75a10945597a9d6c274fc82d3338" + "b403a0a549d1375f26e71ef22bce0941" + "93ea87e2ed72fce0546148c351eec3be" + "867bb1b96070c377fff3c98e21562beb" + "475cfe28abcaaedf49981f6599b15140" + "ea6130d24407079f18ba9d4a8960b082" + "b39c57320e2e064f02fde88c23112146" + "1cac3655868aef584714826ee4f361fb" + "e6d692e1589cbb9dd3c74fa628df2a1f" + "3b0029b1d62b7e9978013ed3c793c1dd" + "1f184c8f7022a853cac40b74ac749aa3" + "f33f0d14732dfda0f2c3c20591bf1f5a" + "710ec0d0bca342baa5146068a78ff58c" + "66316312b7a98af35a0f4e92799b4047" + "f047ae61f25c28d232ce5c168cc745d6" + "6da13cb0f9e38a696635dba7a21571cf" + "cd64ec8cc33db7879f59a90d9edd00f6" + "a899e39ab36b9269a3ac04ebad9326bf" + "53cd9b400168a61714cd628a4056d236" + "bd8622c76daa54cb65f5db2fe03bafbe" + "0b23549ae31136f607293e8093a21934" + "74fd5e9c2451b4c8e0499e6ad34fafc8" + "ab77722a282f7f84b14ddebf7e696300" + "c1ef92d4a0263c6cca104530f996e272" + "f58992ff68d642b071a5848dc4acf2ae" + "28fb1f27ae0f297d5136a7a0a4a03e89" + "b588755b8217a1c62773790e69261269" + "19f45daf7b3ccf18e3fc590a9a0e172f" + "033ac4d13c3decc4c62d7de718ace802" + "140452dc850989f6762e3578bbb04be3" + "a8ae66427697167e85725b37b304baf0" + "56dbcef79fbb97cdfe1590e5f3d0bd1b" + "ce518f2f141960a1c80a4fe787b90b63" + "e7b0e0a0d8d522619130c544bb1abad0" + "b267c650e8916b5d7ececfeea7f0ad15" + "206a92581319946b138764f209109a20" + "0146b4cfb2ce8bd0db5c2cd5b495c56f" + "8f8a7934fe1f9add0674d4549080bf0d" + "01149ed18dbdccc5e54a3e7039546970" + "401ecc885902ee3dcfad504a68066f92" + "c779f1e1c48d37ba0e177ac652c1827b" + "f1f6723d533f0cdf36331e3ad1e1b1af" + "bc89a29c87fe3603353130d0dfbe1f29" + "13ad144e7c6515fb92005b6ece218b4f" + "baedc42d484fffee39df88041b49342a" + "6134cc7ca46d40d274c1ffafa98956e6" + "a492486989c4e328761c01798abcb09b" + "a42eb115334619daaeae9175f365fe9f" + "e5c3b254379d546005016784015f729f" + "4715ff6db16c5d16333e03fd" } }; gpg_error_t err = 0; gcry_cipher_hd_t hde, hdd; - unsigned char out[1024]; + unsigned char out[2048]; unsigned char tag[16]; int tidx;
Mar 12 2021
Mar 12 2021
jukivili closed T4531: PowerPC performance improvements, a subtask of T4460: libgcrypt performance TODOs, as Resolved.
Mar 11 2021
Mar 11 2021
Tiger's /usr/include/AvailabilityMacros.h seems to provide what rndlinux.c was looking for: libgcrypt 1.9.2 just built!
Alright! Here is the error report from GCC:
Mar 9 2021
Mar 9 2021
jukivili renamed T5040: Improve PPC code using code from CRYPTOGRAMs from Impove PPC code using code from CRYPTOGRAMs to Improve PPC code using code from CRYPTOGRAMs.
Pushed to master with two commits:
Looks okay. Thanks.
Mar 7 2021
Mar 7 2021
I posted patch-set to mailing-list. Please check if AUTHORS/LICENSES updates are ok.
https://lists.gnupg.org/pipermail/gcrypt-devel/2021-March/005120.html
Can you please also update AUTHORS and LICENSE files? I would also ask you to add
Mar 6 2021
Mar 6 2021
Fixed typos and applied to master. Thanks.
Mar 5 2021
Mar 5 2021
Feb 25 2021
Feb 25 2021
Feb 23 2021
Feb 23 2021
Fixed in libgcrypt 1.9.2. Thanks!
Feb 22 2021
Feb 22 2021
In T5286#143493, @shaoyj wrote:Excuse me, where is the link to this blog you mentioned?
@bobwxc wrote:
And I found a blog seems written by the SM2 implementation author of libgcrybt -- Tianjia Zhang. He/She drew a red circle on a standard picture of the Z_A.
Excuse me, where is the link to this blog you mentioned?
Feb 21 2021
Feb 21 2021
In T5286#142947, @werner wrote:We need more information on the why and when of this change. We don't want to maintain different versions of the same algorithm. The I-D expired more than 6 years ago and thus it should not be used as a reference.