From jcb62281 at gmail.com Wed Oct 1 03:26:23 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Tue, 30 Sep 2025 20:26:23 -0500 Subject: [PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set In-Reply-To: References: <20250927075419.1923877-1-jussi.kivilinna@iki.fi> <20250927075419.1923877-9-jussi.kivilinna@iki.fi> Message-ID: <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> On 9/30/25 01:30, Jussi Kivilinna wrote: > Hello, > > On 27/09/2025 10:54, Jussi Kivilinna wrote: >> * cipher/mceliece6688128f-patches: New. >> * cipher/mceliece6688128f.sh: Apply patches from >> 'cipher/mceliece6688128f-patches/*'. >> -- > > I had to drop this commit with patch files as git server rejects this > with: > > remote: > cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:40: > trailing whitespace. > remote: + > remote: > cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:44: > trailing whitespace. > remote: + > remote: > cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:49: > trailing whitespace. > remote: + > <...snip...> > remote: error: hook declined to update refs/heads/master > > Should I anyway try to wrestle this change in to repo? These patch > files could be packaged into tar.gz for example. Could the patch be fixed to remove the trailing whitespace?? I suggest trying Emacs M-x whitespace-cleanup on the patches. At a quick check, it looks like that hook may have legitimately caught patches that add non-empty blank lines.? Is there some reason unknown to me to have whitespace on seemingly blank lines in C code? -- Jacob From wk at gnupg.org Wed Oct 1 16:34:25 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Oct 2025 16:34:25 +0200 Subject: [PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set In-Reply-To: <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> (Jacob Bachmeyer via Gcrypt-devel's message of "Tue, 30 Sep 2025 20:26:23 -0500") References: <20250927075419.1923877-1-jussi.kivilinna@iki.fi> <20250927075419.1923877-9-jussi.kivilinna@iki.fi> <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> Message-ID: <87frc24rny.fsf@jacob.g10code.de> > At a quick check, it looks like that hook may have legitimately caught > patches that add non-empty blank lines.? Is there some reason unknown > to me to have whitespace on seemingly blank lines in C code? Some editors do not default to nuke trailing white space. :-( Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From jussi.kivilinna at iki.fi Wed Oct 1 17:57:00 2025 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Wed, 1 Oct 2025 18:57:00 +0300 Subject: [PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set In-Reply-To: <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> References: <20250927075419.1923877-1-jussi.kivilinna@iki.fi> <20250927075419.1923877-9-jussi.kivilinna@iki.fi> <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> Message-ID: <3c6f2ead-6c63-48e0-98fb-dc18ddc42f77@iki.fi> On 01/10/2025 04:26, Jacob Bachmeyer via Gcrypt-devel wrote: > On 9/30/25 01:30, Jussi Kivilinna wrote: >> Hello, >> >> On 27/09/2025 10:54, Jussi Kivilinna wrote: >>> * cipher/mceliece6688128f-patches: New. >>> * cipher/mceliece6688128f.sh: Apply patches from >>> 'cipher/mceliece6688128f-patches/*'. >>> -- >> >> I had to drop this commit with patch files as git server rejects this with: >> >> remote: cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:40: trailing whitespace. >> remote: + >> remote: cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:44: trailing whitespace. >> remote: + >> remote: cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:49: trailing whitespace. >> remote: + >> <...snip...> >> remote: error: hook declined to update refs/heads/master >> >> Should I anyway try to wrestle this change in to repo? These patch files could be packaged into tar.gz for example. > > Could the patch be fixed to remove the trailing whitespace?? I suggest trying Emacs M-x whitespace-cleanup on the patches. > > At a quick check, it looks like that hook may have legitimately caught patches that add non-empty blank lines.? Is there some reason unknown to me to have whitespace on seemingly blank lines in C code? > Problem with diff/patch files and whitespace is that these are machine generated text files. In diff format, unedited lines start with one space character. Empty unedited lines are represented by lines with single space character. Pre-commit hook detects these as text files with single space lines and rejects commit. Either hook would need to be changed to support patch/diff files or diff files be hidden somehow from hook (for example in gz). Latter seems worst of these as that hides changes from trivial git code review. -Jussi From jcb62281 at gmail.com Thu Oct 2 01:31:00 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 1 Oct 2025 18:31:00 -0500 Subject: [PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set In-Reply-To: <3c6f2ead-6c63-48e0-98fb-dc18ddc42f77@iki.fi> References: <20250927075419.1923877-1-jussi.kivilinna@iki.fi> <20250927075419.1923877-9-jussi.kivilinna@iki.fi> <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> <3c6f2ead-6c63-48e0-98fb-dc18ddc42f77@iki.fi> Message-ID: On 10/1/25 10:57, Jussi Kivilinna wrote: > On 01/10/2025 04:26, Jacob Bachmeyer via Gcrypt-devel wrote: >> On 9/30/25 01:30, Jussi Kivilinna wrote: >>> Hello, >>> >>> On 27/09/2025 10:54, Jussi Kivilinna wrote: >>>> * cipher/mceliece6688128f-patches: New. >>>> * cipher/mceliece6688128f.sh: Apply patches from >>>> 'cipher/mceliece6688128f-patches/*'. >>>> -- >>> >>> I had to drop this commit with patch files as git server rejects >>> this with: >>> >>> remote: >>> cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:40: >>> trailing whitespace. >>> remote: + >>> remote: >>> cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:44: >>> trailing whitespace. >>> remote: + >>> remote: >>> cipher/mceliece6688128f-patches/0001-mceliece6688128f-fix-UBSAN-runtime-errors.patch:49: >>> trailing whitespace. >>> remote: + >>> <...snip...> >>> remote: error: hook declined to update refs/heads/master >>> >>> Should I anyway try to wrestle this change in to repo? These patch >>> files could be packaged into tar.gz for example. >> >> Could the patch be fixed to remove the trailing whitespace?? I >> suggest trying Emacs M-x whitespace-cleanup on the patches. >> >> At a quick check, it looks like that hook may have legitimately >> caught patches that add non-empty blank lines.? Is there some reason >> unknown to me to have whitespace on seemingly blank lines in C code? >> > > Problem with diff/patch files and whitespace is that these are machine > generated text files. In diff format, unedited lines start with one > space character. Empty unedited lines are represented by lines with > single space character. Pre-commit hook detects these as text files > with single space lines and rejects commit. Now I see what is happening:? the commit itself contains a diff, and I misread it embedded in `git diff`. > Either hook would need to be changed to support patch/diff files or > diff files be hidden somehow from hook (for example in gz). Latter > seems worst of these as that hides changes from trivial git code review. Would it be feasible to carry the mceliece code on a tracking branch in the repository, rebase the patchset when pulling updates to an intermediate branch, and merge from that intermediate branch instead of carrying the code directly? You would have one branch carrying only pristine upstream sources (perhaps itself pulled using Git if the code is managed in Git upstream), one branch carrying patched sources that is rebased as upstream updates are imported and merged to the mainline branch. Then you would manage the changes in Git instead of using a script to apply them. -- Jacob From wk at gnupg.org Thu Oct 2 09:58:33 2025 From: wk at gnupg.org (Werner Koch) Date: Thu, 02 Oct 2025 09:58:33 +0200 Subject: [PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set In-Reply-To: <3c6f2ead-6c63-48e0-98fb-dc18ddc42f77@iki.fi> (Jussi Kivilinna's message of "Wed, 1 Oct 2025 18:57:00 +0300") References: <20250927075419.1923877-1-jussi.kivilinna@iki.fi> <20250927075419.1923877-9-jussi.kivilinna@iki.fi> <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> <3c6f2ead-6c63-48e0-98fb-dc18ddc42f77@iki.fi> Message-ID: <87bjmp4tw6.fsf@jacob.g10code.de> On Wed, 1 Oct 2025 18:57, Jussi Kivilinna said: > space character. Empty unedited lines are represented by lines with > single space character. Pre-commit hook detects these as text files > with single space lines and rejects commit. Either hook would need to This explains the oddities I sometimes see. The Gpg4win build system uses lots of patches but almost always the patches are manually edited to include a #! /bin/sh patch -p1 -l -f $* < $0 exit $? header. The -l takes care of the trailing white space which the editor removed. With the removed traling spaces it is no problem to commit these files. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From jussi.kivilinna at iki.fi Sun Oct 5 11:57:12 2025 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 5 Oct 2025 12:57:12 +0300 Subject: [PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set In-Reply-To: References: <20250927075419.1923877-1-jussi.kivilinna@iki.fi> <20250927075419.1923877-9-jussi.kivilinna@iki.fi> <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> <3c6f2ead-6c63-48e0-98fb-dc18ddc42f77@iki.fi> Message-ID: <449ff33c-46ce-4290-a9c6-9fa1dbb709e1@iki.fi> Hello, On 02/10/2025 02:31, Jacob Bachmeyer via Gcrypt-devel wrote: > > Now I see what is happening:? the commit itself contains a diff, and I misread it embedded in `git diff`. > >> Either hook would need to be changed to support patch/diff files or diff files be hidden somehow from hook (for example in gz). Latter seems worst of these as that hides changes from trivial git code review. > > Would it be feasible to carry the mceliece code on a tracking branch in the repository, rebase the patchset when pulling updates to an intermediate branch, and merge from that intermediate branch instead of carrying the code directly? > > You would have one branch carrying only pristine upstream sources (perhaps itself pulled using Git if the code is managed in Git upstream), one branch carrying patched sources that is rebased as upstream updates are imported and merged to the mainline branch. Then you would manage the changes in Git instead of using a script to apply them. > That seems a bit more complicated than this in my opinion should be. We already have changes in git history and duplicating that history in shadow branch seems extra work. How about if generator script extracts changes to 'mceliece6688128f.c' from active branch and then apply those patches. So we'd have something like this: # First commit with "cipher/mceliece6688128f.c" generated using script: START_COMMIT="47ed744465ae7461771a3ca08799264a3d32a7fd" GIT_BASE_DIR="$1/.." GIT_TARGET_FILE="cipher/mceliece6688128f.c" ### set -e ( cd "$1"; mkdir -p "mceliece6688128f-tmp" ) # Generate patches from git commit history of target file COMMIT_LIST=$( \ cd "$GIT_BASE_DIR"; \ git log --reverse --pretty=format:%H ${START_COMMIT}..HEAD -- \ "${GIT_TARGET_FILE}" ) i=0 PATCHES="" for commit in $COMMIT_LIST do i=$(expr $i + 1) ( cd "$GIT_BASE_DIR" git format-patch -1 "${commit}" --stdout -- "${GIT_TARGET_FILE}" ) > "$1/mceliece6688128f-tmp/${i}.patch" PATCHES="$PATCHES mceliece6688128f-tmp/${i}.patch" done cd "$1" # ... # generate initial mcelice6688128f.c as in $START_COMMIT to "$1/mceliece6688128f-tmp/mceliece6688128f.c" # ... # apply $PATCHES to "$1/mceliece6688128f-tmp/mceliece6688128f.c" # ... # print "$1/mceliece6688128f-tmp/mceliece6688128f.c" # ... # clean-up of "$1/mceliece6688128f-tmp" -Jussi From jussi.kivilinna at iki.fi Sun Oct 5 11:59:09 2025 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 5 Oct 2025 12:59:09 +0300 Subject: [PATCH] mceliece6688128f: update generation script to apply changes from git In-Reply-To: <449ff33c-46ce-4290-a9c6-9fa1dbb709e1@iki.fi> References: <449ff33c-46ce-4290-a9c6-9fa1dbb709e1@iki.fi> Message-ID: <20251005095909.2444927-1-jussi.kivilinna@iki.fi> * cipher/mceliece6688128f.sh: Apply changes to 'mceliece6688128f.c' from git history. -- Signed-off-by: Jussi Kivilinna --- cipher/mceliece6688128f.sh | 47 +++++++++++++++++++++++++++++++++++++- 1 file changed, 46 insertions(+), 1 deletion(-) diff --git a/cipher/mceliece6688128f.sh b/cipher/mceliece6688128f.sh index 84245432..aab50b25 100755 --- a/cipher/mceliece6688128f.sh +++ b/cipher/mceliece6688128f.sh @@ -77,10 +77,42 @@ FILES=" libmceliece-20230612/include-build/crypto_declassify.h libmceliece-20230612/crypto_kem/6688128f/vec/wrap_dec.c libmceliece-20230612/crypto_kem/6688128f/vec/wrap_enc.c libmceliece-20230612/crypto_kem/6688128f/vec/wrap_keypair.c" + +# First commit with "cipher/mceliece6688128f.c" generated using script: +START_COMMIT="47ed744465ae7461771a3ca08799264a3d32a7fd" +if [ "x$GIT_BASE_DIR" = "x" ]; then + GIT_BASE_DIR="$1/.." +fi +if [ "x$GIT_TARGET_FILE" = "x" ]; then + GIT_TARGET_FILE="cipher/mceliece6688128f.c" +fi + ### set -e -cd $1 + +( cd "$1"; mkdir -p "mceliece6688128f-tmp" ) + +# Generate patches from git commit history of target file +COMMIT_LIST=$( \ + cd "$GIT_BASE_DIR"; \ + git log --reverse --pretty=format:%H ${START_COMMIT}..HEAD -- \ + "${GIT_TARGET_FILE}" ) +i=0 +PATCHES="" +for commit in $COMMIT_LIST +do + i=$(expr $i + 1) + ( + cd "$GIT_BASE_DIR" + git format-patch -1 "${commit}" --stdout -- "${GIT_TARGET_FILE}" + ) > "$1/mceliece6688128f-tmp/${i}.patch" + PATCHES="$PATCHES mceliece6688128f-tmp/${i}.patch" +done + +cd "$1" + +( echo '/* mceliece6688128f.c - Classic McEliece for libgcrypt' echo ' * Copyright (C) 2023-2024 Simon Josefsson ' echo ' *' @@ -248,3 +280,16 @@ void mceliece6688128f_keypair(uint8_t *pk, crypto_kem_keypair((unsigned char*) pk, (unsigned char*) sk); } EOF + +) > mceliece6688128f-tmp/mceliece6688128f.c +cd mceliece6688128f-tmp +for patchfile in $PATCHES; do + patch -s -p2 < "../$patchfile" +done +cd .. +cat mceliece6688128f-tmp/mceliece6688128f.c +rm mceliece6688128f-tmp/mceliece6688128f.c +for patchfile in $PATCHES; do + rm "$patchfile" +done +rmdir mceliece6688128f-tmp -- 2.48.1 From jcb62281 at gmail.com Mon Oct 6 04:18:57 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 5 Oct 2025 21:18:57 -0500 Subject: [PATCH 09/10] mceliece6688128f: update generation script to apply changes as patch set In-Reply-To: <449ff33c-46ce-4290-a9c6-9fa1dbb709e1@iki.fi> References: <20250927075419.1923877-1-jussi.kivilinna@iki.fi> <20250927075419.1923877-9-jussi.kivilinna@iki.fi> <4bd3e906-6a25-4c41-9a0f-bcc930f4b014@gmail.com> <3c6f2ead-6c63-48e0-98fb-dc18ddc42f77@iki.fi> <449ff33c-46ce-4290-a9c6-9fa1dbb709e1@iki.fi> Message-ID: <2f3c6afb-dcf3-448b-916c-a31799fb1b3a@gmail.com> On 10/5/25 04:57, Jussi Kivilinna wrote: > Hello, > > On 02/10/2025 02:31, Jacob Bachmeyer via Gcrypt-devel wrote: >> >> Now I see what is happening:? the commit itself contains a diff, and >> I misread it embedded in `git diff`. >> >>> Either hook would need to be changed to support patch/diff files or >>> diff files be hidden somehow from hook (for example in gz). Latter >>> seems worst of these as that hides changes from trivial git code >>> review. >> >> Would it be feasible to carry the mceliece code on a tracking branch >> in the repository, rebase the patchset when pulling updates to an >> intermediate branch, and merge from that intermediate branch instead >> of carrying the code directly? >> >> You would have one branch carrying only pristine upstream sources >> (perhaps itself pulled using Git if the code is managed in Git >> upstream), one branch carrying patched sources that is rebased as >> upstream updates are imported and merged to the mainline branch. Then >> you would manage the changes in Git instead of using a script to >> apply them. >> > > That seems a bit more complicated than this in my opinion should be. > We already have changes in git history and duplicating that history in > shadow branch seems extra work. How about if generator script extracts > changes to 'mceliece6688128f.c' from active branch and then apply > those patches. So we'd have something like this: > > [...] This would essentially reimplement `git rebase` except without keeping the clear records that a shadow branch scheme would carry.? With the shadow branches I propose, each merge into mainline would have exactly the changes made to adapt the upstream sources to libgcrypt, greatly facilitating auditing. Unfortunately, it turns out that Git does not actually support the regular merges required in my proposal, so it all falls apart.? :-( -- Jacob From zach.fogg at gmail.com Wed Oct 8 15:04:13 2025 From: zach.fogg at gmail.com (Zachary Fogg) Date: Wed, 8 Oct 2025 09:04:13 -0400 Subject: think I discovered a libgcrypt EdDSA Verification Bug -- Ed25519 skips verification + can't verify Message-ID: Hi friends. I'm working on a project and I implemented crypto for it with libsodium, with support for ssh and gpg keys. My project is ascii-chat : a couple of C programs (client+server) that let you make video-rendered-to-text video calls from your terminal over tcp/ip. It's pretty cool and has audio support and supports multiple clients like Google Hangouts and Zoom. I'm still working on it a bunch and barely just got it compiling on Windows so be nice if you check the code. Anyway, I discovered gpg and libsodium are incompatible in my code. Verification fails in my crypto process when using libgcrypt and gpg-agent to authenticate in my protocol. It seems gpg-agent and libgcrypt both cannot seem to do Ed25519 verifications. I tried a few simple test programs that look like they should work, but fail. Here's a basic one: ``` #include #include #include int main(void) { gcry_error_t err; gcry_sexp_t keypair = NULL, privkey = NULL, pubkey = NULL; gcry_sexp_t s_sig = NULL, s_data = NULL; gcry_check_version(NULL); gcry_control(GCRYCTL_DISABLE_SECMEM, 0); gcry_control(GCRYCTL_INITIALIZATION_FINISHED, 0); // Generate Ed25519 keypair err = gcry_sexp_build(&keypair, NULL, "(genkey (ecc (curve Ed25519)))"); gcry_pk_genkey(&keypair, keypair); privkey = gcry_sexp_find_token(keypair, "private-key", 0); pubkey = gcry_sexp_find_token(keypair, "public-key", 0); const char *msg = "Test message"; size_t msg_len = strlen(msg); // TEST 1: GPG agent Format 2 (THE BUG) printf("Format 2: (data (flags eddsa) (hash-algo sha512) (value %%b))\n"); err = gcry_sexp_build(&s_data, NULL, "(data (flags eddsa) (hash-algo sha512) (value %b))", msg_len, msg); err = gcry_pk_sign(&s_sig, s_data, privkey); printf(" Sign: %s\n", err ? "FAILED" : "OK"); err = gcry_pk_verify(s_sig, s_data, pubkey); printf(" Verify: %s\n", err ? "FAILED ?" : "OK"); gcry_sexp_release(s_sig); gcry_sexp_release(s_data); // TEST 2: Simple Format 3 (CONTROL - should work) printf("\nFormat 3: (data (value %%b))\n"); err = gcry_sexp_build(&s_data, NULL, "(data (value %b))", msg_len, msg); err = gcry_pk_sign(&s_sig, s_data, privkey); printf(" Sign: %s\n", err ? "FAILED" : "OK"); err = gcry_pk_verify(s_sig, s_data, pubkey); printf(" Verify: %s\n", err ? "FAILED" : "OK ?"); // Cleanup gcry_sexp_release(s_sig); gcry_sexp_release(s_data); gcry_sexp_release(pubkey); gcry_sexp_release(privkey); gcry_sexp_release(keypair); return 0; } ``` ``` gcc -o test_bug test_bug.c $(pkg-config --cflags --libs libgcrypt) ./test Format 2: (data (flags eddsa) (hash-algo sha512) (value %b)) Sign: OK Verify: FAILED ? Format 3: (data (value %b)) Sign: OK Verify: OK ? ``` In other tests I ran, I FAILED to get format three working in my ascii-chat crypto code with libsodium + gpg-agent. But this code works. Important to check this when fixing this bug I guess. So it fails when using "(data (flags eddsa) (hash-algo sha512) (value %b))" format. Now, why exactly does this bug exist? I am wondering this, because I was doubting that it was a bug because this is official gpg code, and I was banging my head against the wall wondering why my crypto was failing when the code looks perfect and gpg-agent itself works with itself cryptographically. My ssh key and password crypto code was working perfectly too. This was curious to me. Very curious. Is this really a bug? Well I don't actually usually write crypto code, and to be honest C code is not my forte.. I'm a JavaScript web developer by nature! So I didn't investigate as thoroughly as should be done because I don't have the ability. I'll leave that to you all. What I did do is make this GitHub issue that has proof of this bug with links to your code that causes it and test programs to prove it: https://github.com/zfogg/ascii-chat/issues/92 . The programs are simple and compile easily and print errors when they shouldn't, but alas this seems to be a real bug. One more reason this bug exists: you all don't test verification of format 2! I checked gpg test code. That should be tested. Verification is explicit for RSA in the code but a similar check for Ed25519 verification is missing from the code and has been since Ed25519 was introduced according to my research. What I would like to see come of this: I want to use gpg in ascii-chat to let users verify with their gpg keys in the crypto process. It will be cool, the other party (client or server) can load the first party's gpg keys from github/gitlab automatically with the user's username via https with my code with --server-key github:username.gpg because everyone's github gpg public keys are at github.com/yourusername.gpg (your ssh keys are at .keys! ascii-chat supports that and it works!! proving my code actually works and this is a gpg bug.). verifying public keys gotten over https in the crypto protocol, neat huh? useful! i think so anyway. Right now, my code errors and exits with "crypto verification failed" when using gpg keys from github or anywhere else. I want to fix this. So I'm submitting this bug report and I'll follow along until someone tells me either how to fix my code and that it's not a bug, or fixes it and lets me compile ascii-chat against working gpg code. I left a lot of info out.. definitely check the GitHub issue if you want to see more (there's a program that shows how it fails with libsodium). But the example program in this email should be enough in my opinion.. Here's maybe some info you might need.. here's a simplified view of my crypto protocol. you can see exactly where it fails when using gpg for verification: Client Server | | |------ Challenge Request ----->| | | |<----- Random Challenge -------| | | | | | Sign challenge: | | - libsodium: ? WORKS | | - SSH keys: ? WORKS | | - GPG keys: ? FAILS | | | |------ Signed Response ------->| | | | | Verify with gcry_pk_verify() | | Result: "Bad signature" |<----- Auth Rejected ----------| see that? my ssh key code works properly there at that point in the protocol. I can't get gpg-agent program or libgcrypt code to work there with libsodium. verification fails so the protocol can't proceed. I hope this is enough information and an actual bug lol. If it's not a bug please let me know how to get libsodium and gpg working together properly. Feel free to ask me any questions about this. Thank you. -Zachary Fogg -- -- ? ?? ? zfo.gg/ -------------- next part -------------- An HTML attachment was scrubbed... URL: