From cwr at cwrichardson.com Tue Jun 1 06:23:47 2021 From: cwr at cwrichardson.com (Christopher Richardson) Date: Tue, 1 Jun 2021 06:23:47 +0200 Subject: decryption failed: No pinentry In-Reply-To: References: <88DFB69B-A400-4E15-973C-76D20E32C14C@cwrichardson.com> Message-ID: > On 31. 5. 2021, at 12:30, Andreas Mattheiss wrote: > > I don't have any pinentry defined in any of my settings in .gnupg/ neither. FYI for the archives, this was the problem. ~/.gnupg/gpg-agent.conf had the following entry: pinentry-program /usr/local/MacGPG2/libexec/pinentry-mac.app/Contents/MacOS/pinentry-mac Cheers, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Jun 3 02:43:02 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 03 Jun 2021 09:43:02 +0900 Subject: keydb_search failed: Invalid argument In-Reply-To: References: Message-ID: <875yyv6and.fsf@akagi.fsij.org> Hello, ?????? ?????? wrote: > I'm getting this error/warning even when I just decrypt an encrypted > file using plain gpg. If you keep using ~/.gnupg/pubring.gpg, I think this is the cause of your problem. In this case, see this comment in the bug tracker of GnuPG: https://dev.gnupg.org/T5409#145906 To excerpt the solution from the comment, it's: -------------------------- cd ~/.gnupg gpg --export-options backup --export >allkeys.gpg mv pubring.gpg pubring.gpg-saved gpg --import-options restore --import Hi, I though migrating my user GPG configuration onto a new computer should be as simple as making a full copy of ~/.gnupg with rsync rsync -av old:/home/me/.gnupg /home/me/ However, on the new computer, I see nothing when I call gpg -k So I checked for differences gpg --version on the new computer prints gpg (GnuPG) 2.2.20 libgcrypt 1.8.7 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/me/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 on the old computer, it is almost the same gpg (GnuPG) 2.2.20 libgcrypt 1.8.5 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/me/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 The directory content on both machines is $ ls -al ~/.gnupg total 152 drwx------ 4 me me 4096 Jun 3 13:41 . drwxr-xr-x 93 me me 4096 Jun 3 11:55 .. drwx------ 2 me me 4096 Dec 22 2017 crls.d -rw------- 1 me me 9400 Feb 25 2016 gpg.conf -rw-r--r-- 1 me me 0 Aug 2 2016 .gpg-v21-migrated drwx------ 2 me me 4096 Aug 30 2019 private-keys-v1.d -rw------- 1 me me 31836 Apr 8 21:51 pubring.gpg -rw------- 1 me me 32 Jun 3 11:30 pubring.kbx -rw------- 1 me me 600 Apr 15 11:24 random_seed -rw------- 1 me me 2582 Feb 25 2016 secring.gpg -rw-r--r-- 1 me me 49152 Oct 17 2019 tofu.db -rw------- 1 me me 2040 Oct 17 2019 trustdb.gpg Can anybody help me out here? Thanks so much in advance! Stephan From mailinglisten at posteo.de Thu Jun 3 23:13:01 2021 From: mailinglisten at posteo.de (mailinglisten at posteo.de) Date: Thu, 3 Jun 2021 21:13:01 +0000 Subject: migration by copy of ~/.gnupg not working In-Reply-To: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> References: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> Message-ID: Am 03.06.21 um 19:50 schrieb Herr Saalfeld via Gnupg-users: > Hi, > > I though migrating my user GPG configuration onto a new computer should > be as simple as making a full copy of ~/.gnupg with rsync > > rsync -av old:/home/me/.gnupg /home/me/ > > However, on the new computer, I see nothing when I call > > gpg -k > (...) What does echo $GNUPGHOME say on your machines? Maybe $GNUPGHOME is set and points to a wrong directory. On your new machine you could try export GNUPGHOME=/home/me/.gnupg/ gpg -k and see what happens. From cderr at simons-rock.edu Thu Jun 3 22:47:22 2021 From: cderr at simons-rock.edu (charlie derr) Date: Thu, 3 Jun 2021 16:47:22 -0400 Subject: migration by copy of ~/.gnupg not working In-Reply-To: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> References: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> Message-ID: On 6/3/21 1:50 PM, Herr Saalfeld via Gnupg-users wrote: > Hi, > > I though migrating my user GPG configuration onto a new computer should > be as simple as making a full copy of ~/.gnupg with rsync > > rsync -av old:/home/me/.gnupg /home/me/ > > However, on the new computer, I see nothing when I call > > gpg -k > > So I checked for differences > > gpg --version on the new computer prints > > gpg (GnuPG) 2.2.20 > libgcrypt 1.8.7 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: /home/me/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > > on the old computer, it is almost the same > > gpg (GnuPG) 2.2.20 > libgcrypt 1.8.5 > Copyright (C) 2020 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. > > Home: /home/me/.gnupg > Supported algorithms: > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > CAMELLIA128, CAMELLIA192, CAMELLIA256 > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > > The directory content on both machines is > > $ ls -al ~/.gnupg > total 152 > drwx------ 4 me me 4096 Jun 3 13:41 . > drwxr-xr-x 93 me me 4096 Jun 3 11:55 .. > drwx------ 2 me me 4096 Dec 22 2017 crls.d > -rw------- 1 me me 9400 Feb 25 2016 gpg.conf > -rw-r--r-- 1 me me 0 Aug 2 2016 .gpg-v21-migrated > drwx------ 2 me me 4096 Aug 30 2019 private-keys-v1.d > -rw------- 1 me me 31836 Apr 8 21:51 pubring.gpg > -rw------- 1 me me 32 Jun 3 11:30 pubring.kbx > -rw------- 1 me me 600 Apr 15 11:24 random_seed > -rw------- 1 me me 2582 Feb 25 2016 secring.gpg > -rw-r--r-- 1 me me 49152 Oct 17 2019 tofu.db > -rw------- 1 me me 2040 Oct 17 2019 trustdb.gpg > > > Can anybody help me out here? > > Thanks so much in advance! > > Stephan Hi Stephan, In 2016, Robert J. Hansen posted the following instructions here on the list, which have always worked for me: https://lists.gnupg.org/pipermail/gnupg-users/2016-September/056729.html Admittedly it's been a while (a year or so?) since i last migrated using this "recipe", so no guarantees that they're still bulletproof... good luck, ~c > > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > -- Charlie Derr Director, Instructional Technology 413-528-7344 https://www.simons-rock.edu Bard College at Simon's Rock Encryption key: http://hope.simons-rock.edu/~cderr/ Personal writing: https://medium.com/@cderr Pronouns: he or they From mailinglist at chiraag.me Fri Jun 4 01:34:23 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Thu, 03 Jun 2021 23:34:23 +0000 Subject: keydb_search failed: Invalid argument In-Reply-To: <875yyv6and.fsf@akagi.fsij.org> References: <875yyv6and.fsf@akagi.fsij.org> Message-ID: 12021/03/32 08:63.22 ?????, NIIBE Yutaka ??????: > Hello, > > ?????? ?????? wrote: > > I'm getting this error/warning even when I just decrypt an encrypted > > file using plain gpg. > > If you keep using ~/.gnupg/pubring.gpg, I think this is the cause of > your problem. > > In this case, see this comment in the bug tracker of GnuPG: > > https://dev.gnupg.org/T5409#145906 > > To excerpt the solution from the comment, it's: > -------------------------- > cd ~/.gnupg > gpg --export-options backup --export >allkeys.gpg > mv pubring.gpg pubring.gpg-saved > gpg --import-options restore --import rm allkeys.gpg > -------------------------- > -- That worked perfectly, thank you! Sincerely, Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 294 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Jun 4 02:43:25 2021 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 03 Jun 2021 20:43:25 -0400 Subject: keydb_search failed: Invalid argument In-Reply-To: <875yyv6and.fsf@akagi.fsij.org> References: <875yyv6and.fsf@akagi.fsij.org> Message-ID: <87y2bq793m.fsf@fifthhorseman.net> On Thu 2021-06-03 09:43:02 +0900, NIIBE Yutaka wrote: > ?????? ?????? wrote: >> I'm getting this error/warning even when I just decrypt an encrypted >> file using plain gpg. > > If you keep using ~/.gnupg/pubring.gpg, I think this is the cause of > your problem. > > In this case, see this comment in the bug tracker of GnuPG: > > https://dev.gnupg.org/T5409#145906 > > To excerpt the solution from the comment, it's: > -------------------------- > cd ~/.gnupg > gpg --export-options backup --export >allkeys.gpg > mv pubring.gpg pubring.gpg-saved > gpg --import-options restore --import rm allkeys.gpg > -------------------------- > -- In debian, we also ship a script /usr/bin/migrate-pubring-from-classic-gpg which should perform a similar approach (though it doesn't use the more recent mechanisms of "--export-options backup"/"--import-options restore"). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kloecker at kde.org Fri Jun 4 09:33:35 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 04 Jun 2021 09:33:35 +0200 Subject: migration by copy of ~/.gnupg not working In-Reply-To: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> References: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> Message-ID: <5033867.m5VLzl1xpT@breq> On Donnerstag, 3. Juni 2021 19:50:17 CEST Herr Saalfeld via Gnupg-users wrote: > Hi, > > I though migrating my user GPG configuration onto a new computer should > be as simple as making a full copy of ~/.gnupg with rsync > > rsync -av old:/home/me/.gnupg /home/me/ I would have expected the same. > However, on the new computer, I see nothing when I call > > gpg -k > > So I checked for differences > > gpg --version on the new computer prints > > gpg (GnuPG) 2.2.20 > libgcrypt 1.8.7 [snip] > Home: /home/me/.gnupg [snip] > > on the old computer, it is almost the same > > gpg (GnuPG) 2.2.20 > libgcrypt 1.8.5 [snip] > Home: /home/me/.gnupg [snip] > > The directory content on both machines is > > $ ls -al ~/.gnupg > total 152 > drwx------ 4 me me 4096 Jun 3 13:41 . > drwxr-xr-x 93 me me 4096 Jun 3 11:55 .. > drwx------ 2 me me 4096 Dec 22 2017 crls.d > -rw------- 1 me me 9400 Feb 25 2016 gpg.conf > -rw-r--r-- 1 me me 0 Aug 2 2016 .gpg-v21-migrated This file indicates that in the past gpg did (try) a migration of the old key storage to the new key storage. > drwx------ 2 me me 4096 Aug 30 2019 private-keys-v1.d This folder is the new storage location for your private keys. > -rw------- 1 me me 31836 Apr 8 21:51 pubring.gpg This is the old public keyring file. > -rw------- 1 me me 32 Jun 3 11:30 pubring.kbx This is the new public keyring file. It is suspiciously small. > -rw------- 1 me me 600 Apr 15 11:24 random_seed > -rw------- 1 me me 2582 Feb 25 2016 secring.gpg This is the old private/secret keyring file. > -rw-r--r-- 1 me me 49152 Oct 17 2019 tofu.db > -rw------- 1 me me 2040 Oct 17 2019 trustdb.gpg > > > Can anybody help me out here? Try the following: a) Terminate all running background processes/daemons of gpg gpgconf --kill all b) Remove the migration indicator file rm ~/.gnupg/.gpg-v21-migrated c) List the public keys gpg -k If this doesn't fix the problem, then do the migration manually by importing the old public keyring and the old secret keyring: gpg --import ~/.gnupg/pubring.gpg gpg --import ~/.gnupg/secring.gpg Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Fri Jun 4 12:59:30 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 04 Jun 2021 12:59:30 +0200 Subject: migration by copy of ~/.gnupg not working In-Reply-To: <5033867.m5VLzl1xpT@breq> ("Ingo \=\?utf-8\?Q\?Kl\=C3\=B6cker\=22's\?\= message of "Fri, 04 Jun 2021 09:33:35 +0200") References: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> <5033867.m5VLzl1xpT@breq> Message-ID: <87mts528vh.fsf@wheatstone.g10code.de> On Fri, 4 Jun 2021 09:33, Ingo Kl?cker said: > Try the following: > a) Terminate all running background processes/daemons of gpg > gpgconf --kill all Before you do that also terminate Kleopatra or other frontends. They might call gpg regualry and thus trigger an autostart of the daemons. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From herrsaalfeld at gmail.com Thu Jun 3 23:38:35 2021 From: herrsaalfeld at gmail.com (Herr Saalfeld) Date: Thu, 03 Jun 2021 17:38:35 -0400 Subject: migration by copy of ~/.gnupg not working In-Reply-To: References: <84cc124bfdcb3f886ef1d1a86ea65f9002560ac1.camel@gmail.com> Message-ID: Hi Charlie, Thanks a lot! This works perfectly but it's also the 'official' export/ import route which is fine to get me back to work :). I would, though, still be interested why making a copy of the .gnupg directory doesn't do it. What else is gpg doing and where? So if anybody had an idea that would be very interesting. Thanks again and all the best, Stephan On Thu, 2021-06-03 at 16:47 -0400, charlie derr wrote: > On 6/3/21 1:50 PM, Herr Saalfeld via Gnupg-users wrote: > > Hi, > > > > I though migrating my user GPG configuration onto a new computer > > should > > be as simple as making a full copy of ~/.gnupg with rsync > > > > rsync -av old:/home/me/.gnupg /home/me/ > > > > However, on the new computer, I see nothing when I call > > > > gpg -k > > > > So I checked for differences > > > > gpg --version on the new computer prints > > > > gpg (GnuPG) 2.2.20 > > libgcrypt 1.8.7 > > Copyright (C) 2020 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > > > Home: /home/me/.gnupg > > Supported algorithms: > > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > > ?CAMELLIA128, CAMELLIA192, CAMELLIA256 > > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > > > > > on the old computer, it is almost the same > > > > gpg (GnuPG) 2.2.20 > > libgcrypt 1.8.5 > > Copyright (C) 2020 Free Software Foundation, Inc. > > License GPLv3+: GNU GPL version 3 or later > > > > This is free software: you are free to change and redistribute it. > > There is NO WARRANTY, to the extent permitted by law. > > > > Home: /home/me/.gnupg > > Supported algorithms: > > Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA > > Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, > > ?CAMELLIA128, CAMELLIA192, CAMELLIA256 > > Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > > Compression: Uncompressed, ZIP, ZLIB, BZIP2 > > > > > > The directory content on both machines is > > > > $ ls -al ~/.gnupg > > total 152 > > drwx------? 4 me me? 4096 Jun? 3 13:41 . > > drwxr-xr-x 93 me me? 4096 Jun? 3 11:55 .. > > drwx------? 2 me me? 4096 Dec 22? 2017 crls.d > > -rw-------? 1 me me? 9400 Feb 25? 2016 gpg.conf > > -rw-r--r--? 1 me me???? 0 Aug? 2? 2016 .gpg-v21-migrated > > drwx------? 2 me me? 4096 Aug 30? 2019 private-keys-v1.d > > -rw-------? 1 me me 31836 Apr? 8 21:51 pubring.gpg > > -rw-------? 1 me me??? 32 Jun? 3 11:30 pubring.kbx > > -rw-------? 1 me me?? 600 Apr 15 11:24 random_seed > > -rw-------? 1 me me? 2582 Feb 25? 2016 secring.gpg > > -rw-r--r--? 1 me me 49152 Oct 17? 2019 tofu.db > > -rw-------? 1 me me? 2040 Oct 17? 2019 trustdb.gpg > > > > > > Can anybody help me out here? > > > > Thanks so much in advance! > > > > Stephan > > Hi Stephan, > > In 2016, Robert J. Hansen posted the following instructions here on > the > list, which have always worked for me: > > https://lists.gnupg.org/pipermail/gnupg-users/2016-September/056729.html > > Admittedly it's been a while (a year or so?) since i last migrated > using > this "recipe", so no guarantees that they're still bulletproof... > > ?? good luck, > ????? ~c > > > > > > > > > > > _______________________________________________ > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users > > > > From azbigdogs at gmx.com Fri Jun 4 19:08:29 2021 From: azbigdogs at gmx.com (Mark) Date: Fri, 4 Jun 2021 10:08:29 -0700 Subject: Automated Comments? Message-ID: I saw this in the key from Microsoft and was wondering how the was done. Was it automated and done at the time of creation or ?? Thanks -----BEGIN PGP PUBLIC KEY BLOCK----- Comment: User-ID:??? Microsoft Security Notifications Comment: Created:??? 10/26/2020 9:54 PM Comment: Expires:??? 10/29/2021 12:00 PM Comment: Type:??? 2048-bit RSA (secret key available) Comment: Usage:??? Signing, Encryption, Certifying User-IDs Comment: Fingerprint:??? 8348AC727723993DB6271A15B65DFC12C4E721B8 From yuanjp89 at 163.com Sat Jun 5 13:54:07 2021 From: yuanjp89 at 163.com (=?GBK?B?1Ky9qMX0?=) Date: Sat, 5 Jun 2021 19:54:07 +0800 (CST) Subject: sha256 of libgcrypt is 10 times slower then busybox sha25sum util on qualcomm IPQ4018 board Message-ID: <6d203868.26aa.179dc05f015.Coremail.yuanjp89@163.com> Hi, I link libgcrypt to calculate the sha256 checksum of router firmware. the code snippets of calcuate sha256 checksum looks like this: uint8_t digest[32]; void *handle; char buf[40960]; sha256_init(&handle) do { ret = read(fd, buf, sizeof(buf)); if (ret < 0) return -ERR_READ; if (ret > 0) sha256_update(handle, buf, ret); } while (ret > 0); sha256_final(handle, digest); Caculate the sha256 of a 6MB file need 3 secoands: # TIME=%e time ./fwtool check ipq4018.bin 3.23 but If i use the sha256sum command provided by busybox, only need 0.4s: # TIME=%e time sha256sum ipq4018.bin 1b4807030b82f07815b7c34d3d32aa06b29081c15b8eb2a2284a5069b962c137 ipq4018.bin 0.43 the libgcrypt build configure in IPQ4018 (ARM cortext A7 soc): conf := --disable-doc --enable-neon-support \ --with-libgpg-error-prefix=$(APP_BUILD)/libgpg-error/ \ --enable-digests="md5 rmd160 sha1 sha256 sha512 blake2" \ --enable-ciphers="arcfour des aes cast5 chacha20" \ --enable-pubkey-ciphers="rsa dsa ecc" \ CFLAGS="-Wno-switch" Is this a problem ? the busybox code seems no hardware support. why libgcrypt is slower so much than busybox. Thanks very much. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio at outerface.net Sun Jun 6 23:24:26 2021 From: sergio at outerface.net (sergio) Date: Mon, 7 Jun 2021 00:24:26 +0300 Subject: "gpg: decryption failed: No secret key" after export-import to another host In-Reply-To: References: Message-ID: <63c9903f-d355-b46d-8f7a-2859ca5d0044@outerface.net> I found the sequence to reproduce my problem: $ rm -rf .gnupg $ gpg --gen-key --batch < ssb ed25519 2021-06-06 [E] $ echo test | gpg --encrypt --recipient test at test.com | gpg --decrypt gpg: encrypted with 256-bit ECDH key, ID 683197C0DF776EC0, created 2021-06-06 "test " test $ gpg --export-secret-keys -a > keys.asc $ rm -rf .gnupg $ gpg --import --trust-model always keys.asc gpg: directory '/home/test/.gnupg' created gpg: keybox '/home/test/.gnupg/pubring.kbx' created gpg: key 6C6DB60F0545821C: public key "test " imported gpg: key 6C6DB60F0545821C: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 $ gpg -K gpg: /home/test/.gnupg/trustdb.gpg: trustdb created /home/test/.gnupg/pubring.kbx ----------------------------- sec ed25519 2021-06-06 [C] 268017E33AFCBAD119C2FB626C6DB60F0545821C uid [ unknown] test ssb# ed25519 2021-06-06 [E] $ echo test | gpg --encrypt --recipient test at test.com | gpg --decrypt gpg: 683197C0DF776EC0: There is no assurance this key belongs to the named user sub ed25519/683197C0DF776EC0 2021-06-06 test Primary key fingerprint: 2680 17E3 3AFC BAD1 19C2 FB62 6C6D B60F 0545 821C Subkey fingerprint: C0E4 F2BE 8532 1C1A 3777 8963 6831 97C0 DF77 6EC0 It is NOT certain that the key belongs to the person named in the user ID. If you *really* know what you are doing, you may answer the next question with yes. Use this key anyway? (y/N) y gpg: encrypted with 256-bit ECDH key, ID 683197C0DF776EC0, created 2021-06-06 "test " gpg: decryption failed: No secret key $ Is this a gnupg bug or I'm doing something wrong? -- sergio. From anon85786376 at protonmail.com Mon Jun 7 02:53:00 2021 From: anon85786376 at protonmail.com (anon85786376) Date: Mon, 07 Jun 2021 00:53:00 +0000 Subject: "gpg: decryption failed: No secret key" after export-import to another host In-Reply-To: References: <63c9903f-d355-b46d-8f7a-2859ca5d0044@outerface.net> Message-ID: <1aPEVm6HzRJjWMNKzafyYW9301lP75ctmNQYrbHj9C3ZkoJW9degs0i_pzxfmKkz-icBXaLjVPVqkTNPneFVVUEl7Q4QUADhWjx8soAmmCo=@protonmail.com> ??????? Original Message ??????? On Sunday, June 6, 2021 2:24 PM, sergio via Gnupg-users wrote: > I found the sequence to reproduce my problem: > > $ rm -rf .gnupg > $ gpg --gen-key --batch < %echo Generating a 25519 key > Key-Type: eddsa > Key-Curve: Ed25519 > Key-Usage: cert > Subkey-Type: ecdh > Subkey-Curve: Ed25519 The problem is the subkey curve being ed25519. It will not import correctly. For an encryption subkey you must use "Subkey-Curve: cv25519". See: https://dev.gnupg.org/T5401 From wk at gnupg.org Mon Jun 7 21:22:46 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 07 Jun 2021 21:22:46 +0200 Subject: Automated Comments? In-Reply-To: (Mark via Gnupg-users's message of "Fri, 4 Jun 2021 10:08:29 -0700") References: Message-ID: <871r9d1nuh.fsf@wheatstone.g10code.de> On Fri, 4 Jun 2021 10:08, Mark said: > I saw this in the key from Microsoft and was wondering how the was done. > Was it automated and done at the time of creation or ?? The Kleopatra GUI tool exports keys using this format. In fact the header lines in the armor can easily be stripped or added by a script. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sergio at outerface.net Tue Jun 8 10:00:54 2021 From: sergio at outerface.net (sergio) Date: Tue, 8 Jun 2021 11:00:54 +0300 Subject: "gpg: decryption failed: No secret key" after export-import to another host In-Reply-To: <1aPEVm6HzRJjWMNKzafyYW9301lP75ctmNQYrbHj9C3ZkoJW9degs0i_pzxfmKkz-icBXaLjVPVqkTNPneFVVUEl7Q4QUADhWjx8soAmmCo=@protonmail.com> References: <63c9903f-d355-b46d-8f7a-2859ca5d0044@outerface.net> <1aPEVm6HzRJjWMNKzafyYW9301lP75ctmNQYrbHj9C3ZkoJW9degs0i_pzxfmKkz-icBXaLjVPVqkTNPneFVVUEl7Q4QUADhWjx8soAmmCo=@protonmail.com> Message-ID: Thank you anon85786376!! -- sergio. From abhisht.sharma at gmail.com Tue Jun 8 03:07:43 2021 From: abhisht.sharma at gmail.com (Abhisht Sharma) Date: Tue, 8 Jun 2021 11:07:43 +1000 Subject: GPG : "No secret key found" error Message-ID: Hi Please keep me in CC as I think I am not a subscribed user yet. GPG: I am using the gpg command in a UNIX Shell script triggered by the Abinitio ETL Tool to decrypt my encrypted source files. I am following below steps to achieve my goal. Step 1. As a POC, I can successfully executed below command. gpg --batch --yes --quiet --always-trust -o /home/output_file.dat -d /etl/inbound/encrypted_file.dat.pgp The above command will simply ask for password and decrypt the source file. Please note that I am intentionally not using --passphrase as password will be exposed to console using ps command. Step 2. Instead, I have thought of storing the passphrase in a file (passphrase.dat.pgp), encrypted that file without password and passing the password to do the work using below command. echo gpg --batch --yes --quiet --always-trust -d /home/sharma43/passphrase.dat.pgp | gpg --batch --yes --quiet --always-trust -o /home/output_file.dat -d /etl/inbound/encrypted_file.dat.pgp Now the problem comes when I execute above command and it fails for below error. gpg: cancelled by user gpg: decryption failed: No secret key Obviously, I have the required secret key as the POC done in Step 1 was successful. Step 3. To my wonder, when I execute Step 1 first and then Step 2 (within a short span), it works, but if I directly run Step 2 ( which actually will be happening as a part of solution), then it doesn't and fails for "No secret key" error. Can you please explain why this could be happening? Is there a specific location where GPG private keys should be imported? Please note the version I am using is "gpg (GnuPG) 2.0.22 version". -Regards Abhisht Sharma +61 420410228 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Tue Jun 8 12:10:24 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 8 Jun 2021 06:10:24 -0400 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: Please do not send HTML to this mailing list. Many of our members refuse to open HTML emails from unknown parties, so when you send HTML email to this list you're limiting the number of people who can see your question -- and maybe be able to help you! > Step 2. Instead, I have thought of storing the passphrase in a file > (passphrase.dat.pgp), encrypted that file without password and passing > the password to do the work using below command. How exactly do you "encrypt that file without password"? At any rate, this is probably a bad idea. Often the best way to proceed for scripting GnuPG tasks is to remove the passphrase from the certificate. > Step 3. To my wonder, when I execute Step 1 first and then Step 2 > (within a short span), it works, but if I directly run Step 2 ( which > actually will be happening as a part of solution), then it doesn't and > fails for "No secret key" error. This tells me that GnuPG is caching your passphrase with gpg-agent. When you run it the second time GnuPG sees the passphrase is in the cache and uses that, without ever needing to ask you for the passphrase. From gniibe at fsij.org Wed Jun 9 06:20:56 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 09 Jun 2021 13:20:56 +0900 Subject: sha256 of libgcrypt is 10 times slower then busybox sha25sum util on qualcomm IPQ4018 board In-Reply-To: <6d203868.26aa.179dc05f015.Coremail.yuanjp89@163.com> References: <6d203868.26aa.179dc05f015.Coremail.yuanjp89@163.com> Message-ID: <87h7i7brdj.fsf@akagi.fsij.org> Hello, ??? wrote: > Caculate the sha256 of a 6MB file need 3 secoands: > # TIME=%e time ./fwtool check ipq4018.bin > 3.23 [...] > the libgcrypt build configure in IPQ4018 (ARM cortext A7 soc): > conf := --disable-doc --enable-neon-support \ > --with-libgpg-error-prefix=$(APP_BUILD)/libgpg-error/ \ > --enable-digests="md5 rmd160 sha1 sha256 sha512 blake2" \ > --enable-ciphers="arcfour des aes cast5 chacha20" \ > --enable-pubkey-ciphers="rsa dsa ecc" \ > CFLAGS="-Wno-switch" What compiler are you using? If it emits code which uses integer unit for FPU/vector operations, it's better to use --disable-neon-support to build libgcrypt, instead. > Is this a problem ? the busybox code seems no hardware support. why > libgcrypt is slower so much than busybox. It looks like busybox code only uses integer operations (no vector operations) for ARM. -- From abhisht.sharma at gmail.com Wed Jun 9 09:46:24 2021 From: abhisht.sharma at gmail.com (Abhisht Sharma) Date: Wed, 9 Jun 2021 17:46:24 +1000 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: Hi Robert, Many thanks for your email. I will try to give you the background of the problem that led me to this approach. *Problem:* ------------------------------------------------------------------------------------------------------------ I have a situation where the password-protected PGP/GPG encrypted files need to be decrypted, processed through ETL operations and loaded in HIVE. I had a generic Korn Shell script which executes below command. cmd 1: *gpg --batch --yes --quite --always-trust -o $OUTPUT_FILE --passphrase $PASSPHRASE -d $ENCRYPTED_SOURCE_FILE* But, this command had a risk of exposing *$PASSPHRASE* to the UNIX console if any user executes *ps -ef* command while the code is running. This was a huge security breach so I chose the *--passphrase-file* option to read the decryption password from a file. Now, all I need is to place the file, which stores the decryption password, with strict user permissions. Having said that, just to add a little bit of more security I was thinking of encrypting the above mentioned file (which stores the Decryption password) and within my shell script, decrypt it, read it and pass the password to the "*gpg*" command. This encryption needs to be passwordless using 7za utility otherwise we will be stuck in a loop of storing the new password securely. Below 7za command was used to encrypt without password. cmd 2: *7za a -mx=9 -mhe -t7z $ENCRYPTED_OUTPUT_FILE $SOURCE_FILE* Now "cmd 1" has been updated to the below command, which UNIX shell script will use to read the above file and pass on the passphrase to the gpg decryption command. cmd 3: *echo `7za -x -so $FILE_WITH_DECRYPTION_PASSWORD` | gpg --batch --yes --quite --always-trust -o $OUTPUT_FILE -d $ENCRYPTED_SOURCE_FILE * ------------------------------------------------------------------------------------------------------------ The problem I mentioned in my original post starts from here. The above command doesn't run and fails for "No secret Key found" issue and runs fine if it is executed immediately after the second part of command i.e. *gpg --batch --yes --quite --always-trust -o $OUTPUT_FILE -d $ENCRYPTED_SOURCE_FILE* There is a similar command as mentioned below, which runs fine. cmd 4: *echo `7za x -so $FILE_WITH_DECRYPTION_PASSWORD` | 7za x -o$OUTPUT_FILE $7Z_ENCRYPTED_FILE* Please note that in the above command (cmd 4) the source files are encrypted with 7z utility (or compressed with password, as many people say). The whole intention of doing all of this is just to avoid any possible PASSWORD security breach. I hope I was able to give you a clearer picture of the requirement. I am even open for any new design approach, if you experts can suggest. Please let me know in case of any queries. -regards, Abhisht Sharma On Tue, 8 Jun 2021 at 20:10, Robert J. Hansen wrote: > Please do not send HTML to this mailing list. Many of our members > refuse to open HTML emails from unknown parties, so when you send HTML > email to this list you're limiting the number of people who can see your > question -- and maybe be able to help you! > > > Step 2. Instead, I have thought of storing the passphrase in a file > > (passphrase.dat.pgp), encrypted that file without password and passing > > the password to do the work using below command. > > How exactly do you "encrypt that file without password"? > > At any rate, this is probably a bad idea. Often the best way to proceed > for scripting GnuPG tasks is to remove the passphrase from the certificate. > > > Step 3. To my wonder, when I execute Step 1 first and then Step 2 > > (within a short span), it works, but if I directly run Step 2 ( which > > actually will be happening as a part of solution), then it doesn't and > > fails for "No secret key" error. > > This tells me that GnuPG is caching your passphrase with gpg-agent. > When you run it the second time GnuPG sees the passphrase is in the > cache and uses that, without ever needing to ask you for the passphrase. > -- With Regards, Abhisht Sharma +353 899875624 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Jun 9 18:58:44 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Jun 2021 12:58:44 -0400 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: I'm not going to respond to this until you re-send it as plain text without HTML. The very first thing I wrote in my last email was that this mailing list strongly prefers plain text without HTML. We're willing to help you, but you need to follow the rules. From rjh at sixdemonbag.org Thu Jun 10 02:46:09 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Jun 2021 20:46:09 -0400 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: > But, this command had a risk of exposing *$PASSPHRASE* to the UNIX > console if any user executes *ps -ef* command while the code is running. > This was a huge security breach so I chose the *--passphrase-file* > option to read the decryption password from a file. > > Now, all I need is to place the file, which stores the decryption > password, with strict user permissions. And this is probably a bad idea. Clearly, you have a place where you feel it's safe to store a file containing the passphrase for your certificate. So remove the passphrase from your certificate and store it there, in that safe place on your filesystem. > Having said that, just to add a little bit of more security... This is a really bad habit: thinking that "I'll just add one more step to add a little bit more security." It's endemic to the community -- you are far from the only person to have it. But it's a bad habit, and here's why: security decisions always need to be connected to your threat model. Is there something in your threat model you can point to and say, "because of this particular threat we're concerned about, this step I want to take is warranted"? If so, go for it. If not, don't. From rjh at sixdemonbag.org Thu Jun 10 02:50:38 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Jun 2021 20:50:38 -0400 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: <8c06dc86-267e-6b4b-0965-7b07434aabcb@sixdemonbag.org> > I am writing this email to you in plain text... I am surprised how is it > coming to as HTML. As I don't use GMail, I can't help you. You'll need to ask Google. Your message comes through as having both plaintext and HTML parts. This, for instance, is part of the source of your email: Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am writing this email to you in plain text... I am surp= rised how is it coming to as HTML.

Any idea?

Any speci= al things I need to check before sending the email?

-Regards
Abhisht Sharma
+61 4204= 10228

On Thu, 10 Jun 2021, 02:58 Robert J. Hansen, <rjh at sixdemonbag.org> wrote:
I'm not going to respond to this until = you re-send it as plain text
without HTML.=C2=A0 The very first thing I wrote in my last email was that =
this mailing list strongly prefers plain text without HTML.

We're willing to help you, but you need to follow the rules.
From abhisht.sharma at gmail.com Thu Jun 10 01:18:51 2021 From: abhisht.sharma at gmail.com (Abhisht Sharma) Date: Thu, 10 Jun 2021 09:18:51 +1000 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: I am writing this email to you in plain text... I am surprised how is it coming to as HTML. Any idea? Any special things I need to check before sending the email? -Regards Abhisht Sharma +61 420410228 On Thu, 10 Jun 2021, 02:58 Robert J. Hansen, wrote: > I'm not going to respond to this until you re-send it as plain text > without HTML. The very first thing I wrote in my last email was that > this mailing list strongly prefers plain text without HTML. > > We're willing to help you, but you need to follow the rules. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhisht.sharma at gmail.com Thu Jun 10 01:19:41 2021 From: abhisht.sharma at gmail.com (Abhisht Sharma) Date: Thu, 10 Jun 2021 09:19:41 +1000 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: Please note that the resolution of this problem is really critical so any quick help will be highly appreciated! -Regards Abhisht Sharma +61 420410228 On Thu, 10 Jun 2021, 09:18 Abhisht Sharma, wrote: > I am writing this email to you in plain text... I am surprised how is it > coming to as HTML. > > Any idea? > > Any special things I need to check before sending the email? > > -Regards > Abhisht Sharma > +61 420410228 > > On Thu, 10 Jun 2021, 02:58 Robert J. Hansen, wrote: > >> I'm not going to respond to this until you re-send it as plain text >> without HTML. The very first thing I wrote in my last email was that >> this mailing list strongly prefers plain text without HTML. >> >> We're willing to help you, but you need to follow the rules. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Jun 10 20:50:14 2021 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 10 Jun 2021 14:50:14 -0400 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: <6c3b7ca7-a3d7-c660-3e85-c0ae583a9a88@sixdemonbag.org> > I am trying to write in plain text mode so hopefully you won't be > seeing it in HTML. Success! Thank you. > Can you please suggest to me the steps that I should follow to > redesign my solution, considering the password security? I already have, twice. For the third time: remove the passphrase from your private key, and make sure the location where you're storing your private key is safe. From wk at gnupg.org Thu Jun 10 20:15:13 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Jun 2021 20:15:13 +0200 Subject: [Announce] GnuPG 2.2.28 (LTS) released Message-ID: <87wnr1y4b2.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG LTS release: version 2.2.28. This release brings a couple of new features and fixes the usual bugs. The new features have been backported from the stable series 2.3. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.28 (2021-06-10) ================================================= * gpg: Auto import keys specified with --trusted-keys. [e7251be84c79] * gpg: Allow decryption w/o public key but with correct card inserted. [e53f6037283e] * gpg: Allow fingerprint based lookup with --locate-external-key. [2af217ecd7e4] * gpg: Lookup a missing public key of the current card via LDAP. [b59af0e2a05a] * gpg: New option --force-sign-key. [#4584] * gpg: Use a more descriptive password prompt for symmetric decryption. [03f83bcda5d1] * gpg: Do not use the self-sigs-only option for LDAP keyserver imports. [#5387] * gpg: Keep temp files when opening images via xdg-open. [0441ed6e1c] * gpg: Fix mailbox based search via AKL keyserver method. [22fe23f46d31] * gpg: Fix sending an OpenPGP key with umlaut to an LDAP keyserver. [7bf8530e75d0] * gpg: Allow ECDH with a smartcard returning only the x-coordinate. [b203325ce1] * gpgsm: New option --ldapserver as an alias for --keyserver. Note that configuring servers in gpgsm and gpg is deprecated; please use the dirmngr configuration options. * gpgsm: Support AES-GCM decryption. [b722fd755c77] * gpgsm: Support decryption of password protected files. [6f31acac767f] * gpgsm: Lock keyboxes also during a search to fix lockups on Windows. [#4505] * agent: Skip unknown unknown ssh curves seen on cards. [bbf4bd3bfcb5] * scdaemon: New option --pcsc-shared. [5eec40f3d827] * scdaemon: Backport PKCS#15 card support from GnuPG 2.3 [7637d39fe20e] * scdaemon: Fix CCID driver for SCM SPR332/SPR532. [#5297] * scdaemon: Fix possible PC/SC removed card problem. [9d83bfb63968] * scdaemon: Fix unblock PIN by a Reset Code with KDF. [#5413] * scdaemon: Support compressed points. [96577e2e46e4] * scdaemon: Prettify S/N for Yubikeys and fix reading for early Yubikey 5 tokens. [f8588369bcb0,#5442] * dirmngr: New option --ldapserver to avoid the need for the separate dirmngr_ldapservers.conf file. * dirmngr: The dirmngr_ldap wrapper has been rewritten to properly support ldap-over-tls and starttls for X.509 certificates and CRLs. [39815c023f03] * dirmngr: OpenPGP LDAP keyservers may now also be configured using the same syntax as used for X.509 and CRL LDAP servers. This avoids the former cumbersome quoting rules and adds a flexible set of flags to control the connection. [2b4cddf9086f] * dirmngr: The "ldaps" scheme of an OpenPGP keyserver URL is now interpreted as ldap-with-starttls on port 389. To use the non-standardized ldap-over-tls the new LDAP configuration method of the new attribute "gpgNtds" needs to be used. [55f46b33df08] * dirmngr: Return the fingerprint as search result also for LDAP OpenPGP keyservers. This requires the modernized LDAP schema. [#5441] * dirmngr: An OpenPGP LDAP search by a mailbox now ignores revoked keys. [b6f8cd7eef4b] * gpgconf: Make runtime changes with non-default homedir work. [c8f0b02936c7] * gpgconf: Do not translate an empty string to the PO file's meta data. [#5363] * gpgconf: Fix argv overflow if --homedir is used. [#5366] * gpgconf: Return a new pseudo option "compliance_de_vs". [9feffc03f364] * gpgtar: Fix file size computation under Windows. [198b240b1955] * Full Unicode support for the Windows command line. [#4398] * Fix problem with Windows Job objects and auto start of our daemons. [#4333] * i18n: In German always use "Passwort" instead of "Passphrase" in prompts. Release-info: https://dev.gnupg.org/T5482 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.28 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.28.tar.bz2 (7049k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.28.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.28_20210610.exe (4380k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.28_20210610.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. New versions of the GnuPG VS-Desktop(tm) and Gpg4win featuring this version of GnuPG will be released shortly. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.2.28.tar.bz2 you would use this command: gpg --verify gnupg-2.2.28.tar.bz2.sig gnupg-2.2.28.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.2.28.tar.bz2, you run the command like this: sha1sum gnupg-2.2.28.tar.bz2 and check that the output matches the next line: 5f92b7b32d594cf21ea2b48cdaa2e460daccd6e3 gnupg-2.2.28.tar.bz2 8fe406980d09e80812fe8fee3f616765e1a4a526 gnupg-w32-2.2.28_20210610.tar.xz 9d53a8092c4f470831417b8f850943960a9fe857 gnupg-w32-2.2.28_20210610.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, and Ukrainian being almost completely translated. Documentation and Support ========================= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in thee manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf . You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T5482 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and still mostly financed by donations. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking in 2021, Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users'at'gnupg.org mailing list. p.p.s List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: ed25519 2020-08-24 [expires: 2030-06-30] Key fingerprint = 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) rsa3072 2017-03-17 [expires: 2027-03-15] Key fingerprint = 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) rsa2048 2011-01-12 [expires: 2021-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. -- "If privacy is outlawed, only outlaws will have privacy." - PRZ 1991 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From wk at gnupg.org Thu Jun 10 21:33:53 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Jun 2021 21:33:53 +0200 Subject: GnuPG distribution key with no trust In-Reply-To: <411fe913-95ed-8ea4-ba81-36f79e29b4da@posteo.de> (mailinglisten's message of "Mon, 31 May 2021 21:08:39 +0000") References: <411fe913-95ed-8ea4-ba81-36f79e29b4da@posteo.de> Message-ID: <87lf7hy0ny.fsf@wheatstone.g10code.de> On Mon, 31 May 2021 21:08, mailinglisten--- said: > Hello, > > is there a reason why the new software distribution key for GnuPG ( > 0x528897B826403ADA ) comes with no chain of trust at all? It does not > have any signature from any preceding key. I see pub ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA6E64A76D2840571B4902528897B826403ADA uid [ full ] Werner Koch (dist signing 2020) sig!3 528897B826403ADA 2020-08-24 Werner Koch (dist signing 2020) sig! 249B39D24F25E3B6 2020-08-24 Werner Koch (dist sig) sig! 63113AE866587D0A 2020-08-24 wk at gnupg.org sig! E3FDFF218E45B72B 2020-08-24 Werner Koch (wheatstone commit signing) But you are right, the distributed key (gnugp tarball, website) has the key signatures removed. The problem is that you won't receive any key signature from the usual keyserver. I'll see that we can update the keys on the web and in gnupg. The above mentioned key with all key sigs is attached. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: 6DAA6E64A76D2840571B4902528897B826403ADA.asc Type: application/pgp-keys Size: 1459 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From abhisht.sharma at gmail.com Thu Jun 10 14:44:43 2021 From: abhisht.sharma at gmail.com (Abhisht Sharma) Date: Thu, 10 Jun 2021 22:44:43 +1000 Subject: GPG : "No secret key found" error In-Reply-To: References: Message-ID: Hi Robert, I am trying to write in plain text mode so hopefully you won't be seeing it in HTML. I really appreciate the help you have provided me so far. I am really not into networking and encryption stuff, so please expect few dumb questions from me. Can you please suggest to me the steps that I should follow to redesign my solution, considering the password security? I have the private keys and passphrase of the PGP encrypted files. Now, my basic question is where/how should I store the decryption password and what would be my "gpg" command. Appreciate your help. -regards, Abhisht Sharma On Thu, 10 Jun 2021 at 10:46, Robert J. Hansen wrote: > > > But, this command had a risk of exposing *$PASSPHRASE* to the UNIX > > console if any user executes *ps -ef* command while the code is running. > > This was a huge security breach so I chose the *--passphrase-file* > > option to read the decryption password from a file. > > > > Now, all I need is to place the file, which stores the decryption > > password, with strict user permissions. > > And this is probably a bad idea. > > Clearly, you have a place where you feel it's safe to store a file > containing the passphrase for your certificate. So remove the > passphrase from your certificate and store it there, in that safe place > on your filesystem. > > > Having said that, just to add a little bit of more security... > > This is a really bad habit: thinking that "I'll just add one more step > to add a little bit more security." It's endemic to the community -- > you are far from the only person to have it. But it's a bad habit, and > here's why: security decisions always need to be connected to your > threat model. > > Is there something in your threat model you can point to and say, > "because of this particular threat we're concerned about, this step I > want to take is warranted"? If so, go for it. If not, don't. -- With Regards, Abhisht Sharma +353 899875624 From x10an14 at gmail.com Fri Jun 11 19:44:22 2021 From: x10an14 at gmail.com (Christian Chavez) Date: Fri, 11 Jun 2021 19:44:22 +0200 Subject: Anyone know of a gpg-encrypted secrets sharing software that allows a client to hold different "bases/repositories" of secrets? Message-ID: Hi! Say I want to use the tools pass, or git secret to semi-automatically encrypt secrets I share with others in my team. In addition I have a separate git repository where I've co-located both passwords and totp tokens (though separated with different yubikeys so as not to completely invalidate the totp keys). Does anyone know of a tool/software that works much like pass/git secret, but also easily/simply allows you to access two different bases/repositories (like my personal passwords/totp and team one above) with the same tool/cli? Had it not been for pass demanding ultimate trust, I might've been happy with that although I would've preferred to avoid the function/alias work-around of `PASS_SECRETS_FOLDER=work|personal pass`. -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus+gnupg at ethgen.ch Sat Jun 12 13:34:12 2021 From: klaus+gnupg at ethgen.ch (Klaus Ethgen) Date: Sat, 12 Jun 2021 12:34:12 +0100 Subject: Anyone know of a gpg-encrypted secrets sharing software that allows a client to hold different "bases/repositories" of secrets? In-Reply-To: References: Message-ID: Hi Christian, When I read the subject, I was thinking exactly of pass. Am Fr den 11. Jun 2021 um 18:44 schrieb Christian Chavez via Gnupg-users: > Does anyone know of a tool/software that works much like pass/git secret, > but also easily/simply allows you to access two different > bases/repositories (like my personal passwords/totp and team one above) > with the same tool/cli? You can combine multiple pass repositories into one using, for example, git submodules. I used that over many years. Having a cron job that committed all submodules changes in the top pass git automatically. In pass, you can have different keys for each subtree. See the man page for `pass init --path=sub-folder`. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 688 bytes Desc: not available URL: From x10an14 at gmail.com Sat Jun 12 16:13:13 2021 From: x10an14 at gmail.com (Christian Chavez) Date: Sat, 12 Jun 2021 16:13:13 +0200 Subject: Anyone know of a gpg-encrypted secrets sharing software that allows a client to hold different "bases/repositories" of secrets? In-Reply-To: References: Message-ID: Hi Klaus, On Sat, Jun 12, 2021 at 2:44 PM Klaus Ethgen wrote: > You can combine multiple pass repositories into one using, for example, > git submodules. I used that over many years. Having a cron job that > committed all submodules changes in the top pass git automatically. > Thank you so much for your suggestion! I will see if I can automate this somehow without putting my private key (currently on a yubikey) on machine =) (If you - or anyone else - have got any tips/suggestions, I'm all ears)! > In pass, you can have different keys for each subtree. See the man page > for `pass init --path=sub-folder`. > This is indeed what "solves" my problem, but I fail to understand how I can utilize this. Maybe I'm interpreting the keyword "init" wrongly, but I was hoping to avoid "hand-crafted" aliases/the like to reference different subdirectories/trees of passwords. My `man pass init` says the following; > init [ --path=sub-folder, -p sub-folder ] gpg-id... > Initialize new password storage and use gpg-id for encryption. Multiple gpg-ids may be specified, in order to encrypt each password with multiple ids. This command must be run first before a password store can be used. If the specified gpg-id is different from > the key used in any existing files, these files will be reencrypted to use the new id. (...) If --path or -p is specified, along with an argument, a specific gpg-id or set of gpg-ids is assigned for that specific sub folder of the password store. (...) My workflow so far has been: 1. `pass init ` 2. Add secrets I want to unlock with pass with this specific key. 3. Use `pass git` to sync between clients. So, in an attempt to clarify my confusion (nevermind the oxymoron that becomes); Are you supposed to `pass init --path ` within an already established PASSWORD_STORE_DIR? Is this the missing link in my understanding? Something like this? ``` tree .password-store/ .password-store/ ??? accountX ??? accountY ??? accountZ ??? ASSOCIATE_MY_SPECIFIED_GPG_ID(S)_FOR_ALL_ITEMS_HERE_ON_DOWNWARDS ??? work-teamA ? ??? ASSOCIATE_ABOVE_REFERENCED_GPG_ID(S)_AND_THOSE_OF_TEAM_A_FOR_ALL_ITEMS_HERE_ON_DOWNWARDS ??? work-teamB ??? ASSOCIATE_ABOVE_REFERENCED_GPG_ID(S)_AND_THOSE_OF_TEAM_B_FOR_ALL_ITEMS_HERE_ON_DOWNWARDS ``` -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglisten at posteo.de Sat Jun 12 22:00:20 2021 From: mailinglisten at posteo.de (mailinglisten at posteo.de) Date: Sat, 12 Jun 2021 20:00:20 +0000 Subject: GnuPG distribution key with no trust In-Reply-To: <87lf7hy0ny.fsf@wheatstone.g10code.de> References: <411fe913-95ed-8ea4-ba81-36f79e29b4da@posteo.de> <87lf7hy0ny.fsf@wheatstone.g10code.de> Message-ID: <290c0c3b-13de-9522-2c49-12baa66037d2@posteo.de> Am 10.06.21 um 21:33 schrieb Werner Koch: > On Mon, 31 May 2021 21:08, mailinglisten--- said: >> Hello, >> >> is there a reason why the new software distribution key for GnuPG ( >> 0x528897B826403ADA ) comes with no chain of trust at all? It does not >> have any signature from any preceding key. > > I see > > pub ed25519 2020-08-24 [SC] [expires: 2030-06-30] > 6DAA6E64A76D2840571B4902528897B826403ADA > uid [ full ] Werner Koch (dist signing 2020) > sig!3 528897B826403ADA 2020-08-24 Werner Koch (dist signing 2020) > sig! 249B39D24F25E3B6 2020-08-24 Werner Koch (dist sig) > sig! 63113AE866587D0A 2020-08-24 wk at gnupg.org > sig! E3FDFF218E45B72B 2020-08-24 Werner Koch (wheatstone commit signing) > > But you are right, the distributed key (gnugp tarball, website) has the > key signatures removed. The problem is that you won't receive any key > signature from the usual keyserver. > > I'll see that we can update the keys on the web and in gnupg. The above > mentioned key with all key sigs is attached. Indeed, the keyserver issue is a real pain that probably won?t go away soon... Lucky to have your own hosted web site or mail provider supporting WKD... Thanks for all efforts! regards From klaus+gnupg at ethgen.ch Sat Jun 12 23:23:40 2021 From: klaus+gnupg at ethgen.ch (Klaus Ethgen) Date: Sat, 12 Jun 2021 22:23:40 +0100 Subject: Anyone know of a gpg-encrypted secrets sharing software that allows a client to hold different "bases/repositories" of secrets? In-Reply-To: References: Message-ID: Hi Christian, Am Sa den 12. Jun 2021 um 15:13 schrieb Christian Chavez: > (If you - or anyone else - have got any tips/suggestions, I'm all ears)! Was something like `cd $HOME/.password-store && git add -u && git commit -m "autocommit"`. I do not still have the cron. And the submodules was created with a normal pass init on a different machine. > > In pass, you can have different keys for each subtree. See the man page > > for `pass init --path=sub-folder`. > > > This is indeed what "solves" my problem, but I fail to understand how I can > utilize this. > Maybe I'm interpreting the keyword "init" wrongly, but I was hoping to > avoid "hand-crafted" aliases/the like to reference different > subdirectories/trees of passwords. The trick is, that there can be a .gpg-id anywhere in the subtree changing the keys that can access the passes. A `pass init -p ...` just create a .gpg-id inside that sub-folder. But the content could be the same as in the top dir. > So, in an attempt to clarify my confusion (nevermind the oxymoron that > becomes); > Are you supposed to `pass init --path $PASSWORD_STORE_DIR>` within an already established > PASSWORD_STORE_DIR? Yes. You can even add/edit that .gpg-id manually, but then you have to handle the reencryption yourself. Be also aware, that (as you have that in git) if a user was able to decrypt passes in the past, he will be in the future too. (just go back the git history) So, if you plan to have limited access for a subtree than in the main, then you have to start with that so. Keep also in mind, that anybody with write access to git could write a .gpg-id with his key included to let him access all furture stored passes in that tree. I had that this way: - my private main password-store with main .gpg-id - ... - gesch?ftlich (a git submodule synced from different machine) That dir includes its own .gpg-id. There was even trees with more or less keys inside. Have fun. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 688 bytes Desc: not available URL: From knighttemplar5 at protonmail.com Sun Jun 13 16:06:22 2021 From: knighttemplar5 at protonmail.com (knighttemplar5 at protonmail.com) Date: Sun, 13 Jun 2021 14:06:22 +0000 Subject: Big curiosity Message-ID: Hi, I have been contemplating subscribing to an email forwarding service that will encrypt all the forwarded mails to me with my public key. Lets imagine the country where the forwarding takes place can see all my emails in plain text and at the same time the same emails PGP encrypted, can enough of this data pose a threat to my private key?I mean in theory at list? I just love learning about this stuff but I m not good enough in math to have an informed opinion. Thanks KT Sent with ProtonMail Secure Email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - knighttemplar5 at protonmail.com - 0x654EA1A0.asc Type: application/pgp-keys Size: 1876 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From johanw at vulcan.xs4all.nl Sun Jun 13 18:58:54 2021 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Sun, 13 Jun 2021 18:58:54 +0200 Subject: Big curiosity In-Reply-To: References: Message-ID: <86f06055-9db7-1204-7e20-30f8254704c3@vulcan.xs4all.nl> On 13-06-2021 16:06, knighttemplar5--- via Gnupg-users wrote: > I have been contemplating subscribing to an email forwarding service > that will encrypt all the forwarded mails to me with my public key. > Lets imagine the country where the forwarding takes place can see all my > emails in plain text and at the same time the same emails PGP encrypted, > can enough of this data pose a threat to my private key? What you describe is in cryptography known as a known-plaintext attack. It can happen in a less obvious way. For example I remember the old Word Perfect 5 for DOS that had the option to encrypt its files. It did that by XORing the entire file with your password. However, because the first few bytes of a WP file were always the same it was trivial to deduct the password from a file that was encrypted with this method. So XOR is vulnerable to a known-plaintext attack. However, since this is a well-known attack (it was already used against the German Enigma code in WW2), all modern encryption algorithms are tested against this and will certainly not be put in GnuPG is they are vulnerable to it. So, in short, the answer to your question is "no, it is not a threat". -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From please.post at publicly.invalid Sun Jun 13 19:42:01 2021 From: please.post at publicly.invalid (Andreas Mattheiss) Date: Sun, 13 Jun 2021 17:42:01 +0000 (UTC) Subject: Big curiosity References: <86f06055-9db7-1204-7e20-30f8254704c3@vulcan.xs4all.nl> Message-ID: Hello, a bit of elaborating on this one. Am Sun, 13 Jun 2021 18:58:54 +0200 schrieb Johan Wevers : > On 13-06-2021 16:06, knighttemplar5--- via Gnupg-users wrote: > >> I have been contemplating subscribing to an email forwarding service >> that will encrypt all the forwarded mails to me with my public key. >> Lets imagine the country where the forwarding takes place can see all my >> emails in plain text and at the same time the same emails PGP encrypted, >> can enough of this data pose a threat to my private key? > > What you describe is in cryptography known as a known-plaintext attack. > Correct. > It can happen in a less obvious way. For example I remember the old Word > Perfect 5 for DOS that had the option to encrypt its files. It did that > by XORing the entire file with your password. However, because the first > few bytes of a WP file were always the same it was trivial to deduct the > password from a file that was encrypted with this method. > Yet let us keep in mind that gpg (or any practical assymetric encryption kit out there) consists of two elements: an asymmetric encryption and a symmetric encryption. The XOR is the symmetric part, and there is a lot of discussion on the resilience of a symmetric cipher to chosen plaintext attacks when it is being reviewed. XOR is a good example here because it is so poor in this respect. Modern variants are thought to be resilient against this type of attacs - typical reviews might tell you that in order to break a 128 bit key one would need 2**90 or so texts and their encrypted equivalent. The actual number for gpg security is practically not relevant, since for gpg you'll get a different symmetric key each time you encrypt another file. This is because gpg actually only encrypts this symmetric key with the assymetric code, like RSA - typically not more than 256 bit of arbitrary nature. For the assymetric code the world is different - anybody who has access to the public key can generate as many plaintext/ciphertext pairs as he wants. Yet I am not aware of any (relevant) choosen plaintext attacs against RSA & friends - this would immediately render it useless, for any application. > > So, in short, the answer to your question is "no, it is not a threat". > Absolutely right. You should be more concerned to understand what this type of incoming mail encryption is good for - and what it can't prevent. It is not as useful as you may think; the mail provider could still read your plaintext mail, even though he may promise you to encrypt things directly after receiving. The link from your email provider to you is, these days, already encrypted, so no benefit there neither. The one benefit is that if someone hacks your mail provider he can't do anything with your mails he may find there, since they are all encrypted. So yes it is useful, but only in a specific way. Hope this helps, regards Andreas -- Lister: Everything?s really nice there. They even shampoo the rats. Groom their tails and everything! From mgorny at gentoo.org Sun Jun 13 19:14:22 2021 From: mgorny at gentoo.org (=?UTF-8?Q?Micha=C5=82_G=C3=B3rny?=) Date: Sun, 13 Jun 2021 19:14:22 +0200 Subject: Big curiosity In-Reply-To: References: Message-ID: <143ad8b124264942d542828be23da05f8876efa2.camel@gentoo.org> On Sun, 2021-06-13 at 14:06 +0000, knighttemplar5--- via Gnupg-users wrote: > I have been contemplating subscribing to an email forwarding service that will encrypt all the forwarded mails to me with my public key. > Lets imagine the country where the forwarding takes place can see all my emails in plain text and at the same time the same emails PGP encrypted, can enough of this data pose a threat to my private key?I mean in theory at list? I just love learning about this stuff but I m not good enough in math to have an informed opinion. > Let me answer from a little different perspective. Anyone can generate some piece of text and encrypt it using your public key. There is nothing special about encrypting your mails vs encrypting arbitrary data. So if that were a problem, access to your mails would be entirely irrelevant to it. -- Best regards, Micha? G?rny From aajaxx at gmail.com Wed Jun 16 18:29:32 2021 From: aajaxx at gmail.com (Ajax) Date: Wed, 16 Jun 2021 16:29:32 +0000 Subject: Where is swdb.lst Message-ID: With gnuupg-2.3.1 make -f build-aux/speedo.mk native gives "download of swdb.lst failed" The above is on a Debian 10 buster box. I've not been able to find swdb.lst nor how to work without it; I'd be grateful for any help. Thank you. -- --ajax From wk at gnupg.org Wed Jun 16 20:45:01 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 16 Jun 2021 20:45:01 +0200 Subject: Where is swdb.lst In-Reply-To: (Ajax via Gnupg-users's message of "Wed, 16 Jun 2021 16:29:32 +0000") References: Message-ID: <87sg1hsl76.fsf@wheatstone.g10code.de> On Wed, 16 Jun 2021 16:29, Ajax said: > With gnuupg-2.3.1 > > make -f build-aux/speedo.mk native > > gives "download of swdb.lst failed" Checkout build-aux/getswdb.sh which does the work. For example --8<---------------cut here---------------start------------->8--- $ build-aux/getswdb.sh gpgv: Signature made Fri 11 Jun 2021 06:51:01 PM CEST gpgv: using RSA key 5B80C5754298F0CB55D8ED6ABCEF7E294B092E28 gpgv: Good signature from "Andre Heinecke (Release Signing Key)" GnuPG version in swdb.lst is less than this version! This version: 2.3.2-beta93 SWDB version: 2.3.1 --8<---------------cut here---------------end--------------->8--- Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From konstantin at linuxfoundation.org Wed Jun 16 20:07:05 2021 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Wed, 16 Jun 2021 14:07:05 -0400 Subject: Where is swdb.lst In-Reply-To: References: Message-ID: <20210616180705.s5snfgfsngbrxjbk@nitro.local> On Wed, Jun 16, 2021 at 04:29:32PM +0000, Ajax via Gnupg-users wrote: > With gnuupg-2.3.1 > > make -f build-aux/speedo.mk native > > gives "download of swdb.lst failed" > > The above is on a Debian 10 buster box. > > I've not been able to find swdb.lst nor how to work without it; I'd be > grateful for any help. https://versions.gnupg.org/swdb.lst -K From aajaxx at gmail.com Wed Jun 16 23:18:19 2021 From: aajaxx at gmail.com (Ajax) Date: Wed, 16 Jun 2021 21:18:19 +0000 Subject: Where is swdb.lst In-Reply-To: <87sg1hsl76.fsf@wheatstone.g10code.de> References: <87sg1hsl76.fsf@wheatstone.g10code.de> Message-ID: On Wed, Jun 16, 2021 at 6:50 PM Werner Koch wrote: .... > Checkout build-aux/getswdb.sh which does the work. > For example > > --8<---------------cut here---------------start------------->8--- > $ build-aux/getswdb.sh Which gave : ... No such file or directory ajax From wk at gnupg.org Thu Jun 17 11:22:42 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 17 Jun 2021 11:22:42 +0200 Subject: Where is swdb.lst In-Reply-To: (Ajax via Gnupg-users's message of "Wed, 16 Jun 2021 21:18:19 +0000") References: <87sg1hsl76.fsf@wheatstone.g10code.de> Message-ID: <87czsksv4t.fsf@wheatstone.g10code.de> On Wed, 16 Jun 2021 21:18, Ajax said: >> $ build-aux/getswdb.sh > > Which gave : > ... No such file or directory $ tar tjvf gnupg-2.2.28.tar.bz2 | grep getswdb.sh -rwxr-xr-x 1000/1000 4831 2021-05-21 07:35 gnupg-2.2.28/build-aux/getswdb.sh Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From aajaxx at gmail.com Thu Jun 17 18:19:24 2021 From: aajaxx at gmail.com (Ajax) Date: Thu, 17 Jun 2021 16:19:24 +0000 Subject: Where is swdb.lst In-Reply-To: <87czsksv4t.fsf@wheatstone.g10code.de> References: <87sg1hsl76.fsf@wheatstone.g10code.de> <87czsksv4t.fsf@wheatstone.g10code.de> Message-ID: On Thu, Jun 17, 2021 at 9:25 AM Werner Koch wrote: > > On Wed, 16 Jun 2021 21:18, Ajax said: > > >> $ build-aux/getswdb.sh > > > > Which gave : > > ... No such file or directory > > $ tar tjvf gnupg-2.2.28.tar.bz2 | grep getswdb.sh > -rwxr-xr-x 1000/1000 4831 2021-05-21 07:35 gnupg-2.2.28/build-aux/getswdb.sh On my debian box $ tar tjvf gnupg-2.2.28.tar.bz2 | grep getswdb.sh gets tar (child): gnupg-2.2.28.tar.bz2: Cannot open: No such file or directory .... What should I try next? Ajax -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From konstantin at linuxfoundation.org Thu Jun 17 19:28:17 2021 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Thu, 17 Jun 2021 13:28:17 -0400 Subject: Where is swdb.lst In-Reply-To: References: <87sg1hsl76.fsf@wheatstone.g10code.de> <87czsksv4t.fsf@wheatstone.g10code.de> Message-ID: <20210617172817.ly22i3uh2ospkrzv@nitro.local> On Thu, Jun 17, 2021 at 04:19:24PM +0000, Ajax via Gnupg-users wrote: > > >> $ build-aux/getswdb.sh > > > > > > Which gave : > > > ... No such file or directory > > > > $ tar tjvf gnupg-2.2.28.tar.bz2 | grep getswdb.sh > > -rwxr-xr-x 1000/1000 4831 2021-05-21 07:35 gnupg-2.2.28/build-aux/getswdb.sh > > On my debian box > > $ tar tjvf gnupg-2.2.28.tar.bz2 | grep getswdb.sh > > gets > > tar (child): gnupg-2.2.28.tar.bz2: Cannot open: No such file or directory .... > > What should I try next? You seem to be wholly unfamiliar with Unix commands and operations. Are you sure you should be trying to build gnupg by hand? It sounds like a task well beyond your comfort zone. What are you trying to get accomplished? -K From kloecker at kde.org Fri Jun 18 11:01:40 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 18 Jun 2021 11:01:40 +0200 Subject: Where is swdb.lst In-Reply-To: <87czsksv4t.fsf@wheatstone.g10code.de> References: <87czsksv4t.fsf@wheatstone.g10code.de> Message-ID: <3859586.GprQZrpM6H@breq> On Donnerstag, 17. Juni 2021 11:22:42 CEST Werner Koch via Gnupg-users wrote: > On Wed, 16 Jun 2021 21:18, Ajax said: > >> $ build-aux/getswdb.sh > > > > Which gave : > > ... No such file or directory > > $ tar tjvf gnupg-2.2.28.tar.bz2 | grep getswdb.sh > -rwxr-xr-x 1000/1000 4831 2021-05-21 07:35 > gnupg-2.2.28/build-aux/getswdb.sh And, for completeness and since Ajax seems to try to build 2.3.1: $ tar tjvf gnupg-2.3.1.tar.bz2 | grep getswdb.sh -rwxr-xr-x 1000/1000 4836 2021-04-09 18:48 gnupg-2.3.1/build-aux/ getswdb.sh @Ajax: If you want us to help you, then you need to tell us exactly what you tried, e.g. what did you download or clone from where. Are you probably trying to build gnupg on a machine that has no Internet access? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From matthew-l at itconsult.co.uk Sun Jun 20 18:52:53 2021 From: matthew-l at itconsult.co.uk (Matthew Richardson) Date: Sun, 20 Jun 2021 17:52:53 +0100 Subject: Detaching signature from signed object Message-ID: Is there any way in GnuPG to detach (or extract) a signature from a signed object? For example, a signed object is created with:- >gpg --armor --output signedfile.asc --sign inputfile.txt where what is wanted is a detached signature which would verify against inputfile.txt. This feature is in PGP 2:- >pgp -sa inputfile.txt -o signedfile.asc >pgp -b signedfile.asc -o verified.txt which also produces verified.pgp as the detached signature. The feature is described (briefly) in the PGP 2 documentation thus:- >To detach a signature certificate from a signed message: > pgp -b ciphertextfile The reason for asking is that I operate a service [1], which currently used PGP 2, and which would benefit from more recent crypto, but which also uses "pgp -b" extensively. Best wishes, Matthew [1] http://www.itconsult.co.uk/stamper.htm From mailinglist at chiraag.me Sun Jun 20 20:22:53 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Sun, 20 Jun 2021 18:22:53 +0000 Subject: Detaching signature from signed object In-Reply-To: References: Message-ID: 12021/04/10 05:36.72 ?????, Matthew Richardson via Gnupg-users ??????: > Is there any way in GnuPG to detach (or extract) a signature from a signed > object? For example, a signed object is created with:- > > >gpg --armor --output signedfile.asc --sign inputfile.txt > > where what is wanted is a detached signature which would verify against > inputfile.txt. > > This feature is in PGP 2:- > > >pgp -sa inputfile.txt -o signedfile.asc > >pgp -b signedfile.asc -o verified.txt > > which also produces verified.pgp as the detached signature. The feature is > described (briefly) in the PGP 2 documentation thus:- > > >To detach a signature certificate from a signed message: > > pgp -b ciphertextfile > > The reason for asking is that I operate a service [1], which currently used > PGP 2, and which would benefit from more recent crypto, but which also uses > "pgp -b" extensively. > > Best wishes, > Matthew > > [1] http://www.itconsult.co.uk/stamper.htm > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users I believe you're looking for the -sb option, which creates a detached signature. HTH! - Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From mailinglisten at posteo.de Sun Jun 20 20:57:26 2021 From: mailinglisten at posteo.de (mailinglisten at posteo.de) Date: Sun, 20 Jun 2021 18:57:26 +0000 Subject: safe curves in openPGP smartcard Message-ID: Hi there, is there any educated guess, when some safe curve (25519?) will find their ways into openPGP smart cards? regards From jscott at posteo.net Sun Jun 20 21:27:21 2021 From: jscott at posteo.net (John Scott) Date: Sun, 20 Jun 2021 19:27:21 +0000 Subject: safe curves in openPGP smartcard In-Reply-To: References: Message-ID: <3f0a3e191a7d70ecb25a1a0f737e8c82678f5061.camel@posteo.net> On Sun, 2021-06-20 at 18:57 +0000, mailinglisten--- via Gnupg-users wrote: > is there any educated guess, when some safe curve (25519?) will find > their ways into openPGP smart cards? Some cards already support Curve25519; I'm signing this with my Nitrokey Start (which is really a Gnuk) using my ed25519 subkey. Nitrokey advertises support for this [1], so I presume it's reliable as it has been for me. [1] https://www.nitrokey.com/#comparison -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: This is a digitally signed message part URL: From brandon753.ba at gmail.com Mon Jun 21 04:52:37 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Sun, 20 Jun 2021 19:52:37 -0700 Subject: Long Term Key Management With Hardware Tokens Message-ID: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> Hey everyone, I have a question regarding using secure hardware such as Yubikey/Nitrokey, GPG smartcards, and the handling of encryption key rotation and replacement. I currently have a GPG key with a 4096 bit RSA key generated on a GPG smart card version 2.1. I have recently acquired two Yubikey 5's, both of which support curve25519. It is unclear if version 3.4 of the GPG smart card supports this curve, but if it does, I would be interested in using it as well. As I am looking to generate a new key that uses the curve25519, I was trying to plan out how I should handle key management and revocation. I was thinking that sub-signing keys could be generated on the secure hardware and a sub decryption key could be generated and imported onto each of these devices with an air-gapped system. Then the non-secure copy of the key is destroyed. Ideally, these subkeys would only ever exist on the secure hardware. When either a token is lost, a new one is added, or enough time has passed that I want to roll the keys, I would revoke the subkey in use, generate a new one via the same process and add it to the security tokens in use. The problem, of course, comes when I need to decrypt old messages signed with the revoked key or if someone at a later point sends an encrypted message to the revoked key. Ideally, I would keep one security token that is assigned the encryption subkey simultaneously as the others before it is destroyed from the computer.This token's job would be to store historic encryption keys if I ever needed to decrypt messages with the older encryption keys. PIV smartcards, including the Yubikey implementation, support Slots 82-95: Retired Key Management which is specifically built for the purpose of key rotation while letting a user store many old encryption keys before they need to acquire new hardware. As neat as this is, the GPG smart card implementations seem to offer no such similar feature. The GPG keys on the smartcards seem specialized specifically for the type of key, be it signing or encryption; you cant even store 3~4 encryption keys per card. Is there a proper way to do this similar to the PIV retired key management scheme? Most people say to just backup offline the encryption keys. Still, I feel like security is lost if that key is ever recoverable in a form other than the secure hardware (e.g., it somehow leaks, resulting in old messages being able to be decrypted). Is there a reason the GPG smart card system does not have retired key slots as part of the design? How is one supposed to best go about this without getting new cards everytime you rotate encryption subkeys? Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Mon Jun 21 09:53:42 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 21 Jun 2021 09:53:42 +0200 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> Message-ID: <10576988.H2Em2vhVcb@breq> On Montag, 21. Juni 2021 04:52:37 CEST Brandon Anderson via Gnupg-users wrote: > The problem, of course, comes when I need to decrypt old messages signed > with the revoked key or if someone at a later point sends an encrypted > message to the revoked key. If you know the recipient, then solving the latter is easy. Ask the recipient to resend the message encrypted with your new key. > Ideally, I would keep one security token > that is assigned the encryption subkey simultaneously as the others > before it is destroyed from the computer.This token's job would be to > store historic encryption keys if I ever needed to decrypt messages with > the older encryption keys. PIV smartcards, including the Yubikey > implementation, support Slots 82-95: Retired Key Management which is > specifically built for the purpose of key rotation while letting a user > store many old encryption keys before they need to acquire new hardware. > As neat as this is, the GPG smart card implementations seem to offer no > such similar feature. The GPG keys on the smartcards seem specialized > specifically for the type of key, be it signing or encryption; you cant > even store 3~4 encryption keys per card. Is there a proper way to do > this similar to the PIV retired key management scheme? GnuPG 2.3 does support PIV smartcards and you can create OpenPGP keys (and X.509 certificates/certificate requests) for those card keys. So far, only the standard key slots are supported, but I guess adding support for retired keys wouldn't be too hard. So, you could consider using PIV tokens as hardware tokens. > Most people say > to just backup offline the encryption keys. Still, I feel like security > is lost if that key is ever recoverable in a form other than the secure > hardware (e.g., it somehow leaks, resulting in old messages being able > to be decrypted). Is there a reason the GPG smart card system does not > have retired key slots as part of the design? How is one supposed to > best go about this without getting new cards everytime you rotate > encryption subkeys? Well, you could re-encrypt everything encrypted to the retired keys with the new keys. This will make sure that you can still decrypt everything even if you kept tokens with the retired keys and those tokens die. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From matthew-l at itconsult.co.uk Mon Jun 21 11:04:37 2021 From: matthew-l at itconsult.co.uk (Matthew Richardson) Date: Mon, 21 Jun 2021 10:04:37 +0100 Subject: Detaching signature from signed object In-Reply-To: References: Message-ID: On Sun, 20 Jun 2021 18:22:53 +0000, ?????? ?????? via Gnupg-users wrote:- >12021/04/10 05:36.72 ?????, Matthew Richardson via Gnupg-users ??????: >> Is there any way in GnuPG to detach (or extract) a signature from a signed >> object? For example, a signed object is created with:- >> >> >gpg --armor --output signedfile.asc --sign inputfile.txt >> >> where what is wanted is a detached signature which would verify against >> inputfile.txt. >> >> This feature is in PGP 2:- >> >> >pgp -sa inputfile.txt -o signedfile.asc >> >pgp -b signedfile.asc -o verified.txt >> >> which also produces verified.pgp as the detached signature. The feature is >> described (briefly) in the PGP 2 documentation thus:- >> >> >To detach a signature certificate from a signed message: >> > pgp -b ciphertextfile >> >> The reason for asking is that I operate a service [1], which currently used >> PGP 2, and which would benefit from more recent crypto, but which also uses >> "pgp -b" extensively. >> >> Best wishes, >> Matthew >> [1] http://www.itconsult.co.uk/stamper.htm > >I believe you're looking for the -sb option, which creates a detached signature. Unless I have misunderstood (and please correct me if I have), "-sb" SIGNS producing a detached signature, whereas I am wanting to detach an EXISTING signature from an already signed object. Best wishes, Matthew From wk at gnupg.org Mon Jun 21 11:05:51 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Jun 2021 11:05:51 +0200 Subject: safe curves in openPGP smartcard In-Reply-To: (mailinglisten's message of "Sun, 20 Jun 2021 18:57:26 +0000") References: Message-ID: <87a6njr3io.fsf@wheatstone.g10code.de> On Sun, 20 Jun 2021 18:57, mailinglisten--- said: > is there any educated guess, when some safe curve (25519?) will find > their ways into openPGP smart cards? Yubikeys and the Gnuk token support 25519 for a long time now. For the Zeitcontrol card, I can't give a concrete timeline. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From vedaal at nym.hush.com Mon Jun 21 18:47:19 2021 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Mon, 21 Jun 2021 12:47:19 -0400 Subject: Detaching signature from signed object In-Reply-To: Message-ID: <20210621164719.C715A80E2C2@smtp.hushmail.com> On 6/20/2021 at 2:13 PM, "Matthew Richardson via Gnupg-users" wrote:Is there any way in GnuPG to detach (or extract) a signature from a signed object? For example, a signed object is created with:- >gpg --armor --output signedfile.asc --sign inputfile.txt where what is wanted is a detached signature which would verify against inputfile.txt. This feature is in PGP 2:- >pgp -sa inputfile.txt -o signedfile.asc >pgp -b signedfile.asc -o verified.txt which also produces verified.pgp as the detached signature. The feature is described (briefly) in the PGP 2 documentation thus:- >To detach a signature certificate from a signed message: > pgp -b ciphertextfile ===== Don't know how to do this in GnuPG. Cannot be done in the PGP commandlines later than 2.x with the -b command. Using the -b command in later PGP commandline versions, just decrypts, but does not save the signature. There is a program that can do this for DH keys, using the -b command but only when encrypted with AES or 3DES: Filecrypt https://m.majorgeeks.com/files/details/filecrypt.html (n.b I have NOT used 'this' version, but I did use the original Filecrypt when it first came out , to successfully use the -b command): https://www.angelfire.com/pr/pgpf/fcs.html The developer of Filecrypt is accessible in a link when downloading the Filecrypt on the majorgeeks site mentioned above. You might consider discussing a version of Filecrypt with him for your detached signature use. vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon753.ba at gmail.com Tue Jun 22 08:47:47 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Mon, 21 Jun 2021 23:47:47 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> Message-ID: <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> > If you know the recipient, then solving the latter is easy. Ask the > recipient > to resend the message encrypted with your new key. > In my setup, when something is sent, only the encrypted mail is sent to my sent folder, so if I were asked as you suggest, I would have no way to send the letter without rewriting it; I assume this is true for others as well. But even so, if it's old mail, the request may be impossible. > GnuPG 2.3 does support PIV smartcards and you can create OpenPGP keys > (and > X.509 certificates/certificate requests) for those card keys. So far, > only the > standard key slots are supported, but I guess adding support for > retired keys > wouldn't be too hard. So, you could consider using PIV tokens as hardware > tokens. > I will look into that. Do you know of any PIV cards that support the 25519 curve? Unfortunately, while the Yubikey supports 25519 for GPG, the PIV functions only support 2048 RSA and NIST curves. The only card I see so far that supports this is https://www.cardlogix.com/product/l-plus-hardware-security-module-hsm-card/, but I am unsure what would be involved in getting it to work as I doubt it would be compatible out the box with GPG; I will try to obtain one and experiment. What would it take to add support for retirement key slots into the GPG smartcard specification? If retirement slots were added to the smartcard spec, then after several years, other smartcard implementations might add support for it over time. Is that something I could help contribute with? > Well, you could re-encrypt everything encrypted to the retired keys > with the > new keys. This will make sure that you can still decrypt everything > even if > you kept tokens with the retired keys and those tokens die. > I thought about this as well. Having an encrypted offline copy of the decryption keys encrypted with a smartcard would have the same benefits as the limited password attempts and hardware security around the key. The problem is that whenever I need/want to decrypt old messages, I would have to set up an air-gapped system and, on that system, load the decryption key on a token, a rather tedious process. That being said, I will probably go with this option in the interim unless others have a better suggestion on how to do this. I would like to help if I could on adding key retirement slots to the smartcard specification if possible. Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Tue Jun 22 11:00:48 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Jun 2021 11:00:48 +0200 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> (Brandon Anderson via Gnupg-users's message of "Mon, 21 Jun 2021 23:47:47 -0700") References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> Message-ID: <87sg1anuin.fsf@wheatstone.g10code.de> On Mon, 21 Jun 2021 23:47, Brandon Anderson said: > the PIV functions only support 2048 RSA and NIST curves. The only card That's per PIV specs. > What would it take to add support for retirement key slots into the > GPG smartcard specification? If retirement slots were added to the > smartcard spec, then after several years, other smartcard Frankly, I am not convinced about the retirement slots on the card. They are of course useful if you rotate you key. But the question is why you want to do this given that the keys are anyway securely stored on a card. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From andrewg at andrewg.com Tue Jun 22 11:13:52 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 22 Jun 2021 10:13:52 +0100 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> Message-ID: <993d3d50-ed3b-d11f-8e23-1320b756d1fa@andrewg.com> On 22/06/2021 07:47, Brandon Anderson via Gnupg-users wrote: > >> If you know the recipient, then solving the latter is easy. Ask the >> recipient >> to resend the message encrypted with your new key. >> > In my setup, when something is sent, only the encrypted mail is sent to > my sent folder, so if I were asked as you suggest, I would have no way > to send the letter without rewriting it; I assume this is true for > others as well. But even so, if it's old mail, the request may be > impossible. For the benefit of the archives, it is possible to encrypt outgoing emails to your own key as well as the recipient's key, which ensures that the sent-mail folder is readable by the sender. Most email clients will do so by default (e.g. mutt, thunderbird/enigmail), and in most such clients all you need to do to re-encrypt to the recipient's new subkey is "Edit" -> "Send" or similar. So in the general case this is a reasonable request, although it cannot be relied upon (of course). -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Tue Jun 22 18:53:57 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Tue, 22 Jun 2021 09:53:57 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <87sg1anuin.fsf@wheatstone.g10code.de> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> <87sg1anuin.fsf@wheatstone.g10code.de> Message-ID: > For the benefit of the archives, it is possible to encrypt outgoing > emails to your own key as well as the recipient's key, which ensures > that the sent-mail folder is readable by the sender. Most email > clients will do so by default (e.g. mutt, thunderbird/enigmail), and > in most such clients all you need to do to re-encrypt to the > recipient's new subkey is "Edit" -> "Send" or similar. So in the > general case this is a reasonable request, although it cannot be > relied upon (of course). Good to know; I will look into my settings. >> the PIV functions only support 2048 RSA and NIST curves. The only card > That's per PIV specs. I assumed as much; otherwise, there would be more offerings. There are x509 certificate cards/HSM smartcards like the one I posted that offer more than the PIV spec, but again it's a question of how compatible they are to work with GPG; my initial guess is it would be a lot of work. > Frankly, I am not convinced about the retirement slots on the card. > They are of course useful if you rotate you key. But the question is > why you want to do this given that the keys are anyway securely stored > on a card. If a key truly lived and died on a single secure device, and that was your only concern, then yes, it would not be helpful. I am thinking about my situation: I have two Yubikeys in everyday use and a GPG smartcard in a safe. I imagine a scenario where one of the Yubikeys dies, is lost or is stolen. In all of those situations, the encryption key and the other device-specific keys would need to be revoked and a new one issued. The GPG card in the safe would store the old encryption key in a retired key slot so I can decrypt old emails. If I did, for example, annual key rotations and only stored the retired keys on the card in the safe, then in the event one of my Yubikey's was stolen, and the thief could guess or know the pin, the only data at risk would be what was encrypted since the last key rotation. Whether it is reasonable to assume that a thief could know your pin or not is purely a matter of your risk tolerance (a keylogger on one of the computers you used, etc.). Another reason the encryption key might want to be rolled is if you are adding another new secure device to your existing set and you want it to be able to decrypt messages. Since ideally, the encryption key would only exist on the secure hardware, and there would be no way to give a new token the existing encryption key so that you would roll a new encryption key on all the devices. Many tutorials, examples, and articles that are talking about using Yubikeys and smartcards currently suggest making paper backups of the encryption key so you can add it to new devices if needed. But this, at least to me, feels like it's significantly reducing the value of using secure hardware like smartcards in the first place. Having the keys only ever exist on secure hardware, including the backups, would make this unnecessary. Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Tue Jun 22 20:20:51 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Tue, 22 Jun 2021 19:20:51 +0100 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> <87sg1anuin.fsf@wheatstone.g10code.de> Message-ID: <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> On 22/06/2021 17:53, Brandon Anderson via Gnupg-users wrote: > Many tutorials, examples, and articles that are talking about using > Yubikeys and smartcards currently suggest making paper backups of the > encryption key so you can add it to new devices if needed. But this, at > least to me, feels like it's significantly reducing the value of using > secure hardware like smartcards in the first place. Having the keys only > ever exist on secure hardware, including the backups, would make this > unnecessary. The disadvantage of only ever storing secret key material on a finite number of secure hardware devices is that all such devices have a lifetime, and once they're all dead your information is gone. You'll still find yourself re-encrypting all your data to a new encryption (sub)key when you get down to your last working hardware device. Having a non-secure offline backup does not negate all the advantages of secure hardware. It depends on the threat model of course, but *most* people are much more likely to have their laptop compromised remotely than have their safe cracked and the paper backup stolen. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Tue Jun 22 20:47:45 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Tue, 22 Jun 2021 11:47:45 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> <87sg1anuin.fsf@wheatstone.g10code.de> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> Message-ID: >> Many tutorials, examples, and articles that are talking about using >> Yubikeys and smartcards currently suggest making paper backups of the >> encryption key so you can add it to new devices if needed. But this, at > >> least to me, feels like it's significantly reducing the value of >> using secure hardware like smartcards in the first place. Having the >> keys only ever exist on secure hardware, including the backups, would >> make this unnecessary. > > The disadvantage of only ever storing secret key material on a finite > number of secure hardware devices is that all such devices have a > lifetime, and once they're all dead your information is gone. You'll > still find yourself re-encrypting all your data to a new encryption > (sub)key when you get down to your last working hardware device. > > Having a non-secure offline backup does not negate all the advantages > of secure hardware. It depends on the threat model of course, but > *most* people are much more likely to have their laptop compromised > remotely than have their safe cracked and the paper backup stolen. I agree that for most people having a paper backup stolen is unlikely, but then again, most people are not using GPG, to begin with, let alone GPG with smartcards or security tokens. There are several security concerns which having retirement keyslots can address. They can also improve the user experience as you won't have to air-gap a machine to view old records with revoked keys. All in all, it's about providing the option of having only security token access, not requiring it. I would expect any smartcard stored in a safe and only used infrequently during key changes and the occasional old record decryptions to last well over a decade. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From kloecker at kde.org Tue Jun 22 21:21:13 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 22 Jun 2021 21:21:13 +0200 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> Message-ID: <4115287.pJxuMPT6TE@breq> On Dienstag, 22. Juni 2021 20:47:45 CEST Brandon Anderson via Gnupg-users wrote: > I agree that for most people having a paper backup stolen is unlikely, > but then again, most people are not using GPG, to begin with, let alone > GPG with smartcards or security tokens. There are several security > concerns which having retirement keyslots can address. They can also > improve the user experience as you won't have to air-gap a machine to > view old records with revoked keys. All in all, it's about providing the > option of having only security token access, not requiring it. I would > expect any smartcard stored in a safe and only used infrequently during > key changes and the occasional old record decryptions to last well over > a decade. I really fail to see your point. I can accept that you do not want to have a not-hardware-token-secured copy of your encryption keys. But what is the problem with having one OpenPGP smartcard for each retired key? Why do you want to cram all retired keys on a single OpenPGP card? Is your motivation the environment (less retired still functional hardware tokens -> less wasted resources)? I'd applaud that, but I also question it. Deleting all those old and probably mostly useless encrypted emails might be better for the environment than keeping them in an archive (with several backups), which needs to be refreshed/copied to new archive storage every few years. Or is it money? Something else? If this single OpenPGP smartcard which holds all of your keys of the last decade breaks, what then? Then you have lost access to all encrypted documents of the last decade. If you'd use separate OpenPGP smartcards instead, then you'd lose access to only one key rotation interval worth of old encrypted documents. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From brandon753.ba at gmail.com Wed Jun 23 06:53:13 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Tue, 22 Jun 2021 21:53:13 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <4115287.pJxuMPT6TE@breq> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> <4115287.pJxuMPT6TE@breq> Message-ID: <8931c888-1ca0-da45-0547-237db72b643f@gmail.com> > > Or is it money? Something else? Money and usability are certain factors here. Most of these tokens are in the realm of $50 apiece; the GPG smart card, while closer to $20, is still another $30 in shipping, so it would be costly unless I purchased all ten upfront. Not to mention the user experience suffers; if I search my email archive for some old record, I have to look through ten different cards to find the correct one. > If this single OpenPGP smartcard which holds all of your keys of the last > decade breaks, what then? Then you have lost access to all encrypted documents > of the last decade. If you'd use separate OpenPGP smartcards instead, then > you'd lose access to only one key rotation interval worth of old encrypted > documents. > > Regards, > Ingo Having retirement key slots makes it easier, not harder, to have redundancy to protect against this. In my particular case, I would use two smart cards at the initial state as safe backups. If one was very concerned, you could use three. The probability that one card out of ten will have a failure in a decade is far higher than the chance that all two or three cards will have a failure. Allowing retirement key slots means you can easily choose your level of redundancy while still keeping your keys on secure hardware only. Sincerely, Brandon Anderson From x10an14 at gmail.com Wed Jun 23 11:38:16 2021 From: x10an14 at gmail.com (Christian Chavez) Date: Wed, 23 Jun 2021 11:38:16 +0200 Subject: GPG agent forwarding multiple yubikeys with distinct public keys/subkeys over SSH Message-ID: Hi! # Background Ref: https://lists.gnupg.org/pipermail/gnupg-users/2021-June/065212.html, I'm now in a situation where I've got a GPG pub/priv (not subkeys) key-pair used for work-purposes, and one for personal/private purposes (read: separate identities). Each GPG pub/priv key-pair resides on each their own yubikey, and I bring the yubikeys with me when I move from say work laptop to personal laptop. # Motivation I would like to be able to connect multiple yubikeys representing multiple opengpg pub/priv key-pairs/identities to the same _client_, and make use of _both_ on a remote I've SSH'ed to (using one of the yubikeys), without having to reboot/restart machine/gpg-agent/ssh connection. # Initial research effort Is this possible? None of the guides/how-to's I've found seem to cover this use-case where you've got multiple GPG identities on multiple yubikeys where you'd like to encrypt/authenticate/sign with both on a remote over SSH. There many guides online describing how to enable gpg agent forwarding, like: - https://mlohr.com/gpg-agent-forwarding/ - https://superuser.com/a/884602 - https://github.com/drduh/YubiKey-Guide#using-multiple-keys None of the above (IIUC) describe/cover my use-case, is this even supported? And if so, how? -- Med vennlig hilsen/Kind regards, Christian Chavez Phone/Tlf: +47 922 22 603 -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaus+gnupg at ethgen.ch Wed Jun 23 12:55:05 2021 From: klaus+gnupg at ethgen.ch (Klaus Ethgen) Date: Wed, 23 Jun 2021 11:55:05 +0100 Subject: decrypt mail archive Message-ID: Hi, I am experience with imapfilter to decrypt old mail archives but keeping signatures. The reason is that I lost already access to old mails that was encrypted to a key which is only on a, now broken, GPG card. As the relevant mailserver is mine and the file system is encrypted, I can accept to have that mails unencrypted in storage. I have the following approach at the moment: for _, msg in ipairs(result) do mbox, uid = unpack(msg) header = mbox[uid]:fetch_header() body = mbox[uid]:fetch_body() flags = mbox[uid]:fetch_flags() date = mbox[uid]:fetch_date() if (body:match("BEGIN PGP MESSAGE")) then obody = body:match('(%-%-%-%-%-BEGIN PGP MESSAGE%-%-%-%-%-.*%-%-%-%-%-END PGP MESSAGE%-%-%-%-%-\r\n)') state, nbody = pipe_single(obody, "gpg", "--decrypt", "--unwrap") if (state ~= 0) then print("Error "..state) break end state, nbody = pipe_single(nbody, "gpg", "--enarmor") if (state ~= 0) then print("Error "..state) break end nbody = nbody:gsub('ARMORED FILE', 'MESSAGE') body = body:gsub('(%-%-%-%-%-BEGIN PGP MESSAGE%-%-%-%-%-.*%-%-%-%-%-END PGP MESSAGE%-%-%-%-%-\r\n)', nbody) message = header .. body --print(message) privat['sent-mail']:append_message(message, flags, date) end end But that do not work in mutt as the signed mail must be in separate mime parts for text and for signature. But `gpg --unwrap` generate a PGP binary file with just encryption removed. Thunderbird works just fine but mutt doesn't. Do anybody have any idea how to convert the binary package back to detached signature and eventually how to build mime parts around in lua? Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 688 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 23 13:23:45 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Jun 2021 13:23:45 +0200 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <8931c888-1ca0-da45-0547-237db72b643f@gmail.com> (Brandon Anderson via Gnupg-users's message of "Tue, 22 Jun 2021 21:53:13 -0700") References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> <4115287.pJxuMPT6TE@breq> <8931c888-1ca0-da45-0547-237db72b643f@gmail.com> Message-ID: <87y2b0n7su.fsf@wheatstone.g10code.de> On Tue, 22 Jun 2021 21:53, Brandon Anderson said: > concerned, you could use three. The probability that one card out of > ten will have a failure in a decade is far higher than the chance that You should also be concerned that malware bricks your (backup) card. You can only avoid that by using an always air-gaped box which is pretty inconvenient. Paper copies are actually much more reliable. I meanwhile scribble down the key using a pencil and paper. Modern keys are short enough to do that. (you should also note the creation date). > all two or three cards will have a failure. Allowing retirement key > slots means you can easily choose your level of redundancy while still > keeping your keys on secure hardware only. Back to your original request. A new revision of the OpenPGP card is in the works and the plan is to add more key slots. Surely there will be some support for this in GnuPG. If you want support for the extra PIV slots, we first need to find a business case for this (its not just the development effort but also the future maintanence work which I have to consider). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Wed Jun 23 14:38:40 2021 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Jun 2021 14:38:40 +0200 Subject: GPG agent forwarding multiple yubikeys with distinct public keys/subkeys over SSH In-Reply-To: (Christian Chavez via Gnupg-users's message of "Wed, 23 Jun 2021 11:38:16 +0200") References: Message-ID: <87k0mkn4bz.fsf@wheatstone.g10code.de> On Wed, 23 Jun 2021 11:38, Christian Chavez said: > I would like to be able to connect multiple yubikeys representing multiple > opengpg pub/priv key-pairs/identities to the same _client_, and make use of > _both_ on a remote I've SSH'ed to (using one of the yubikeys), without Use gnupg 2.3 and this should work. I am using several tokens in a local setup for years. Not tested with remote; if you run into problems enabled IPC debugging for gpg-agent and watch out for GPG_ERR_FORBIDDEN. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From matthew-l at itconsult.co.uk Wed Jun 23 18:55:26 2021 From: matthew-l at itconsult.co.uk (Matthew Richardson) Date: Wed, 23 Jun 2021 17:55:26 +0100 Subject: Detaching signature from signed object In-Reply-To: References: Message-ID: eThinking about this further, is there any to use the details from "--list-packets" in order to extract the signature. For example, the output from the signing below produces:- >C:\>gpg --list-packets R:\Temp\signedfile.asc ># off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate >:compressed packet: algo=1 ># off=2 ctb=90 tag=4 hlen=2 plen=13 >:onepass_sig packet: keyid DC00AF5F572550CB > version 3, sigclass 0x00, digest 8, pubkey 22, last=1 ># off=17 ctb=ac tag=11 hlen=2 plen=55 >:literal data packet: > mode b (62), created 1624466686, name="inputfile.txt", > raw data: 36 bytes ># off=74 ctb=88 tag=2 hlen=2 plen=117 >:signature packet: algo 22, keyid DC00AF5F572550CB > version 4, created 1624466686, md5len 0, sigclass 0x00 > digest algo 8, begin of digest dc 7e > hashed subpkt 33 len 21 (issuer fpr v4 1797615E1E1CA3357FD23365DC00AF5F572550CB) > hashed subpkt 2 len 4 (sig created 2021-06-23) > subpkt 16 len 8 (issuer key ID DC00AF5F572550CB) > data: [256 bits] > data: [256 bits] Would the:- ># off=74 ctb=88 tag=2 hlen=2 plen=117 provide enough inforation to extract the signature? Does it vary depending upon whether the signature is ASCII armored? Or am I barking up the wrong tree??? Best wishes, Matthew ------ >From: Matthew Richardson via Gnupg-users >To: gnupg-users at gnupg.org >Cc: >Date: Sun, 20 Jun 2021 17:52:53 +0100 >Subject: Detaching signature from signed object >Is there any way in GnuPG to detach (or extract) a signature from a signed >object? For example, a signed object is created with:- > >>gpg --armor --output signedfile.asc --sign inputfile.txt > >where what is wanted is a detached signature which would verify against >inputfile.txt. > >This feature is in PGP 2:- > >>pgp -sa inputfile.txt -o signedfile.asc >>pgp -b signedfile.asc -o verified.txt > >which also produces verified.pgp as the detached signature. The feature is >described (briefly) in the PGP 2 documentation thus:- > >>To detach a signature certificate from a signed message: >> pgp -b ciphertextfile > >The reason for asking is that I operate a service [1], which currently used >PGP 2, and which would benefit from more recent crypto, but which also uses >"pgp -b" extensively. > >Best wishes, >Matthew > >[1] http://www.itconsult.co.uk/stamper.htm From TerrencePierce at westat.com Wed Jun 23 15:31:32 2021 From: TerrencePierce at westat.com (Terry Pierce) Date: Wed, 23 Jun 2021 13:31:32 +0000 Subject: Command line decryption/encryption Message-ID: <128bb89d9ec244c09a88c687bb17bb34@westat.com> Hi, Let me start off with I am totally new to GPG/Kleopatra. We use different encryption tools here and one of our clients uses GPG. I have already automated the processing of files using our tool and now have a need to build in a call to handle the decryption of these files. Looking online, I get the basic usage: gpg -d myfile.dat.gpg Two questions: * I don't see the GPG (GGP4win?) executable anywhere in the GPG4Win folders. How do I generate it? * Is there a way to pass any passphrase/key to it on the command line? Thanks, Terry Pierce 301-610-4831 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xintuition at gmail.com Thu Jun 24 00:14:19 2021 From: xintuition at gmail.com (Wayne Ho) Date: Wed, 23 Jun 2021 15:14:19 -0700 Subject: SHA Hash for DMG Message-ID: <098c8da4-f267-8c29-20ed-18b03e79b7ba@gmail.com> Hi, I was wondering if anyone knows that SHA1 checksum for the MacOS file GnuPG-2.2.28.dmg.? It seems to be missing from https://www.gnupg.org/download/integrity_check.html. Thanks, Wayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Thu Jun 24 09:25:24 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 24 Jun 2021 09:25:24 +0200 Subject: SHA Hash for DMG In-Reply-To: <098c8da4-f267-8c29-20ed-18b03e79b7ba@gmail.com> References: <098c8da4-f267-8c29-20ed-18b03e79b7ba@gmail.com> Message-ID: <7935801.50LNZnyfRP@breq> On Donnerstag, 24. Juni 2021 00:14:19 CEST Wayne Ho via Gnupg-users wrote: > Hi, > > I was wondering if anyone knows that SHA1 checksum for the MacOS file > GnuPG-2.2.28.dmg. It seems to be missing from > https://www.gnupg.org/download/integrity_check.html. It's not missing. The MacOS installer is not an official release by the GnuPG project. It is packaged and released by an independent group of volunteers (Thanks for that!). Assuming that you have downloaded the dmg from https://sourceforge.net/p/gpgosx/docu/Download/ you find there a SHA-256 checksum and a signature file. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From johndoe65534 at mail.com Thu Jun 24 09:41:17 2021 From: johndoe65534 at mail.com (john doe) Date: Thu, 24 Jun 2021 09:41:17 +0200 Subject: Command line decryption/encryption In-Reply-To: <128bb89d9ec244c09a88c687bb17bb34@westat.com> References: <128bb89d9ec244c09a88c687bb17bb34@westat.com> Message-ID: On 6/23/2021 3:31 PM, Terry Pierce wrote: > Hi, > > Let me start off with I am totally new to GPG/Kleopatra. We use different encryption tools here and one of our clients uses GPG. I have already automated the processing of files using our tool and now have a need to build in a call to handle the decryption of these files. > > Looking online, I get the basic usage: gpg -d myfile.dat.gpg > > Two questions: > > * I don't see the GPG (GGP4win?) executable anywhere in the GPG4Win folders. How do I generate it? > The executable is in the subdirectory 'bin' as 'gpg.exe'. > * Is there a way to pass any passphrase/key to it on the command line? > I would not do that but If I'm not mistaking you could use a file descripter instead of specifying a password on the command line. A better idea is to use a file that contains the passthrase if you need to automate d/encryption or to use the agent. -- John Doe From brandon753.ba at gmail.com Thu Jun 24 11:21:35 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 24 Jun 2021 02:21:35 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <87y2b0n7su.fsf@wheatstone.g10code.de> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> <4115287.pJxuMPT6TE@breq> <8931c888-1ca0-da45-0547-237db72b643f@gmail.com> <87y2b0n7su.fsf@wheatstone.g10code.de> Message-ID: >> concerned, you could use three. The probability that one card out of >> ten will have a failure in a decade is far higher than the chance that > You should also be concerned that malware bricks your (backup) card. > You can only avoid that by using an always air-gaped box which is pretty > inconvenient. > > Paper copies are actually much more reliable. I meanwhile scribble down > the key using a pencil and paper. Modern keys are short enough to do > that. (you should also note the creation date). I am not arguing that paper copies are less reliable; of course, they are; however, they are not as secure. I prefer greater security and key protection at the risk of less key reliability. I would be ecstatic if malware on my system chose to brick my smartcard over getting access to decrypted communication that it could be snooping on. I personally would prefer to lose access to my own data than let an adversary gain access to it. That being said, if I could avoid losing access to my data by having a proper redundant setup, I would prefer it. >> all two or three cards will have a failure. Allowing retirement key >> slots means you can easily choose your level of redundancy while still >> keeping your keys on secure hardware only. > Back to your original request. A new revision of the OpenPGP card is in > the works and the plan is to add more key slots. Surely there will be > some support for this in GnuPG. If you want support for the extra PIV > slots, we first need to find a business case for this (its not just the > development effort but also the future maintanence work which I have to > consider). First, if you are working on a new revision of the OpenPGP card, please let me know if I can reasonably do anything to help. While I don't have as much free time as I like, I am a software developer and would love to help get this feature added if possible. With that being said, what do you mean by a business case for this? Is there some format of a proposal that you are particularly expecting, or is anything that outlines options, benefits, risks, etc., sufficient? Sincerely, Brandon Anderson -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Thu Jun 24 11:27:19 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 24 Jun 2021 02:27:19 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> <4115287.pJxuMPT6TE@breq> <8931c888-1ca0-da45-0547-237db72b643f@gmail.com> <87y2b0n7su.fsf@wheatstone.g10code.de> Message-ID: <4d4d84a7-5aea-333b-ec69-51b3c3fd2c8a@gmail.com> > I am not arguing that paper copies are less reliable; of course, they > are; however, they are not as secure. As I reread this email, I realized what I said here may have been unclear. I meant to say, of course, paper copies are more reliable than hardware tokens; they are just less secure. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jun 24 13:12:59 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Jun 2021 13:12:59 +0200 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: (Brandon Anderson via Gnupg-users's message of "Thu, 24 Jun 2021 02:21:35 -0700") References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> <4115287.pJxuMPT6TE@breq> <8931c888-1ca0-da45-0547-237db72b643f@gmail.com> <87y2b0n7su.fsf@wheatstone.g10code.de> Message-ID: <87fsx7ms78.fsf@wheatstone.g10code.de> On Thu, 24 Jun 2021 02:21, Brandon Anderson said: > First, if you are working on a new revision of the OpenPGP card, > please let me know if I can reasonably do anything to help. While I Thanks for your offer. However, it is mainly a spec and hardware thing and the software part is minor. If you are a vendor of an OpenPGp comliant card, you are likely already in contact with Achin Pietig, who is responsible for the specs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Jun 24 13:16:31 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Jun 2021 13:16:31 +0200 Subject: Detaching signature from signed object In-Reply-To: (Matthew Richardson via Gnupg-users's message of "Wed, 23 Jun 2021 17:55:26 +0100") References: Message-ID: <87bl7vms1c.fsf@wheatstone.g10code.de> On Wed, 23 Jun 2021 17:55, Matthew Richardson said: > provide enough inforation to extract the signature? Does it vary depending > upon whether the signature is ASCII armored? Actually gpgsplit can be used to slit an OpenPGP message. In theory it is possible to convert an encrypted and signed mail into a PGP/MIME signed mail. However, this requires that the creator strictly followed the suggestions from RFC-3156. In fact it is better to not use the combined method but do signing and encryption at the MIME level; which makes it trivial to strip the encryption layer. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Thu Jun 24 13:18:39 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Jun 2021 13:18:39 +0200 Subject: Command line decryption/encryption In-Reply-To: (john doe via Gnupg-users's message of "Thu, 24 Jun 2021 09:41:17 +0200") References: <128bb89d9ec244c09a88c687bb17bb34@westat.com> Message-ID: <877dijmrxs.fsf@wheatstone.g10code.de> On Thu, 24 Jun 2021 09:41, john doe said: > The executable is in the subdirectory 'bin' as 'gpg.exe'. Which is usuallay part of the PATH. > A better idea is to use a file that contains the passthrase if you need > to automate d/encryption or to use the agent. An even better idea is not to use a passphrase at all - there is no security win with a passphrase in an automated setting. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From apolcyn at google.com Thu Jun 24 19:19:41 2021 From: apolcyn at google.com (Alexander Polcyn) Date: Thu, 24 Jun 2021 10:19:41 -0700 Subject: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net Message-ID: Starting on the morning of June 21 between ~6am and 9am PDT, one of our CI jobs which fetches gpg keys with: gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys ... .... started failing because of what looks like a failure to resolve the pool name. FWIW the following also fails in the same way: gpg --keyserver hkp://ipv4.pool.sks-keyservers.net --recv-keys ... And testing from my machine, it looks like these names now get NXDOMAIN when attempting to resolve in DNS: $ host ipv4.pool.sks-keyservers.net Host ipv4.pool.sks-keyservers.net not found: 3(NXDOMAIN) $ host pool.sks-keyservers.net Host pool.sks-keyservers.net not found: 3(NXDOMAIN) Did these names get permanently deleted? Any workarounds or suggestions would be appreciated. thanks, Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.bna at nexionengineering.com Thu Jun 24 16:42:46 2021 From: m.bna at nexionengineering.com (=?iso-8859-1?Q?Bn=E0_Marco?=) Date: Thu, 24 Jun 2021 14:42:46 +0000 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start Message-ID: Hi all. I'm having this problem with code that would like to decrypt a large gpg file (252 MB) which is password protected! I set the environment which works whit smaller files but in this case I face 117473366 --> Cannot allocate memory Is there any option that I can set to use something similar auto-expand-secmem? Is there any other way to solve the problem? Thank you very much for your attention! Marco Bna' -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon753.ba at gmail.com Thu Jun 24 23:39:05 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 24 Jun 2021 14:39:05 -0700 Subject: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net In-Reply-To: References: Message-ID: <9df3e97e-6897-e8eb-98e2-6951c7e2915c@gmail.com> > Starting on the morning of June 21 between ~6am and 9am PDT, one of > our CI jobs which fetches gpg keys with: > > gpg --keyserver hkp://pool.sks-keyservers.net > --recv-keys ... > .... started failing because of what looks like a failure to resolve > the pool name. > > FWIW the following also fails in the same way: > > gpg --keyserver hkp://ipv4.pool.sks-keyservers.net > --recv-keys ... > > And testing from my machine, it looks like these names now get > NXDOMAIN when attempting to resolve?in DNS: > > $ host ipv4.pool.sks-keyservers.net > > Host ipv4.pool.sks-keyservers.net > not found: 3(NXDOMAIN) > > > $ host pool.sks-keyservers.net > > Host pool.sks-keyservers.net not > found: 3(NXDOMAIN) > > > > > Did these names get permanently deleted? Any workarounds or > suggestions would be appreciated. > > Hey Alex, From what I can tell a lot of the keyservers are being shutdown. Take a look at the message on the SKS site (the SSL cert is expired) https://sks-keyservers.net/. You can read about some of whats going on from here https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f. Sincerely, Brandon Anderson -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mailinglisten at posteo.de Fri Jun 25 00:04:49 2021 From: mailinglisten at posteo.de (mailinglisten at posteo.de) Date: Thu, 24 Jun 2021 22:04:49 +0000 Subject: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net In-Reply-To: References: Message-ID: <22dda25f-0052-8d0d-083e-ae157f2d8889@posteo.de> Am 24.06.21 um 19:19 schrieb Alexander Polcyn via Gnupg-users: > (....) > Host ipv4.pool.sks-keyservers.net > not found: 3(NXDOMAIN) > (....) > Did these names get permanently deleted? Any workarounds or suggestions > would be appreciated. One alternative could be https://keys.openpgp.org/ This keyserver has one big advantage, when you upload a key there, this server verifies the email address associated with that key is valid and you have actual access to this email address. Fake keys have no chance there. Now, it also has one big disadvantage, this keyserver strips *all* signatures associated to that key. All signatures will bw removed when you upload a key there. And GnuPG seems to have issues to fetch keys from there directly, using e.g. gpg --recv-keys, it may be better to use wget to fetch keys from there. If you have control over your own domain you may learn how to use WKD web key directory, this way your key(s) is stored on your very own host. The keyserver situation seems a bit difficult currently, maybe https://keys.openpgp.org/ is the best (easiest) workaround for now. But WKD is really worth looking at! -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Fri Jun 25 00:14:38 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 24 Jun 2021 15:14:38 -0700 Subject: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net In-Reply-To: <22dda25f-0052-8d0d-083e-ae157f2d8889@posteo.de> References: <22dda25f-0052-8d0d-083e-ae157f2d8889@posteo.de> Message-ID: <24642801-6ed1-5b74-7135-801c0fbb5562@gmail.com> > The keyserver situation seems a bit difficult currently, maybe > https://keys.openpgp.org/ is the best (easiest) workaround for now. > > But WKD is really worth looking at! > My understanding is the Ubuntu Key-server is staying up, I could be wrong, but https://keyserver.ubuntu.com/ seems to be functioning. It is worth noting that the keys.openpgp.org keyserver is not web of trust but explicitly trusting that keyserver to validate a person's identity. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From andrewg at andrewg.com Fri Jun 25 00:59:32 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 24 Jun 2021 23:59:32 +0100 Subject: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net In-Reply-To: <9df3e97e-6897-e8eb-98e2-6951c7e2915c@gmail.com> References: <9df3e97e-6897-e8eb-98e2-6951c7e2915c@gmail.com> Message-ID: On 24/06/2021 22:39, Brandon Anderson via Gnupg-users wrote: > >> $ host pool.sks-keyservers.net >> >> Host pool.sks-keyservers.net not >> found: 3(NXDOMAIN) >> >> Did these names get permanently deleted? Any workarounds or >> suggestions would be appreciated. > > Hey Alex, > > From what I can tell a lot of the keyservers are being shutdown. Take a > look at the message on the SKS site (the SSL cert is expired) > https://sks-keyservers.net/. The keyserver *pools* at sks-keyservers.net are no longer maintained for legal reasons. sks-keyservers.net was receiving GDPR requests, e.g. for RTBF, that it could not satisfy because the pools had no formal structure that could compel individual operators to comply with legal requests. While sks-keyservers.net did not host personal data, it was providing a DNS round-robin service for keyservers that did, and the distinction was poorly understood. Most of the individual keyservers that used to be in the pools are still working, however. There is a service at https://sks-status.gwolf.org/ that monitors the known keyservers. Scroll to the bottom and click on the latest "Success" link to see a graph of keyservers that are currently responsive. What to do next depends on your use case. If your CI is searching for a key that is under your own control, then you have more freedom of choice. If it is searching for someone else's key then you may need to use whatever keyserver they use. keys.openpgp.org is the default keyserver for most new installs, and many long-time users have also switched to it. If you don't have a particular reason to choose one, this is probably the safest bet. The main caveat is that it does not serve third-party sigs, and so you won't be able to verify a downloaded key by its signatures. keyserver.ubuntu.com is reliable, but is not widely used outside the Ubuntu developer community. It doesn't get key updates particularly often, so you may find yourself with a stale copy of your correspondent's key. If you need continuity of dataset with the sks-keyservers pool, then you may prefer to use a Hockeypuck server that was formerly part of the pool, such as pgpkeys.eu, keyserver.trifence.ch or keys.andreas-puls.de (other keyservers are available, see https://sks-status.gwolf.org/). Note that Hockeypuck is generally more reliable than SKS due to limitations in SKS's design. Due to the fragmented nature of the keyserver ecosystem at the moment, you may want to try all of the above. And as mentioned in an earlier reply, you should probably also search WKD. -- Andrew Gallagher -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From brandon753.ba at gmail.com Fri Jun 25 08:57:19 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Thu, 24 Jun 2021 23:57:19 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <87fsx7ms78.fsf@wheatstone.g10code.de> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <4c057f9b-d960-1b12-dc41-e92ab4b2a010@andrewg.com> <4115287.pJxuMPT6TE@breq> <8931c888-1ca0-da45-0547-237db72b643f@gmail.com> <87y2b0n7su.fsf@wheatstone.g10code.de> <87fsx7ms78.fsf@wheatstone.g10code.de> Message-ID: > Thanks for your offer. However, it is mainly a spec and hardware thing > and the software part is minor. > > If you are a vendor of an OpenPGp comliant card, you are likely already > in contact with Achin Pietig, who is responsible for the specs. > Yea, I am not a vendor of an OpenPGP card, just an interested user. Have the old GPGcard 2.1, but I want to wait until 25519 support and more slots are available before I buy new ones. That being said, please reach out if you need help. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bna.marco at gmail.com Fri Jun 25 09:39:55 2021 From: bna.marco at gmail.com (Marco) Date: Fri, 25 Jun 2021 09:39:55 +0200 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start Message-ID: Hi all. I?m having this problem with code that would like to decrypt a large gpg file (252 MB) which is password protected! I set the environment which works whit smaller files but in this case I face 117473366 --> Cannot allocate memory Is there any option that I can set to use something similar auto-expand-secmem? Is there any other way to solve the problem? Thank you very much for your attention! *Code sample below:* *-------------------------------------------* bool res(false); gpgme_ctx_t ctx; gpgme_error_t err(GPG_ERR_NO_ERROR); gpgme_data_t in; gpgme_data_t out; gpgme_engine_info_t engineInfo; size_t inFileSize(fs::file_size(input)); std::ostringstream oss; oss << std::dec << inFileSize; std::string fileSizeStr(oss.str()); VCIUpdaterWrapper wrap; wrap.setObj(const_cast(this)); wrap.setFileSize(fs::file_size(input)); memset(&ctx, 0, sizeof(ctx)); memset(&in, 0, sizeof(in)); memset(&out, 0, sizeof(out)); memset(&engineInfo, 0, sizeof(engineInfo)); setlocale(LC_ALL, ""); gpgme_check_version(NULL); gpgme_set_locale(NULL, LC_CTYPE, setlocale(LC_CTYPE, NULL)); err = gpgme_new(&ctx); if (err) { GENERIC_LOG_MESSAGE(LogLevel::error, (boost::format("Failed to create GPG context with error: %1% --> %2%") % err % gpgme_strerror(err)).str()) return res; } engineInfo = gpgme_ctx_get_engine_info(ctx); err = gpgme_ctx_set_engine_info(ctx, engineInfo->protocol, engineInfo->file_name, VCIUpdateConfigurations::getInstance().getVciUpdateBaseFolder().c_str()); if (err) { GENERIC_LOG_MESSAGE(LogLevel::error, (boost::format("Failed to set engine info with error: %1% --> %2%") % err % gpgme_strerror(err)).str()) return res; } gpgme_set_armor(ctx, 0); gpgme_set_pinentry_mode(ctx, GPGME_PINENTRY_MODE_LOOPBACK); gpgme_set_passphrase_cb(ctx, &passwfFuncCb, NULL); err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); if (err) { GENERIC_LOG_MESSAGE( LogLevel::error, (boost::format("Failed to set input file %1% for GPG with error: %2% --> %3%") % input.string() % err % gpgme_strerror(err)).str()) return res; } // else { // err = gpgme_data_set_flag(in, "size-hint", fileSizeStr.c_str()); // // if (err) { // GENERIC_LOG_MESSAGE( // LogLevel::error, // (boost::format("Failed to set size hint for input file %1% for GPG with error: %2% --> %3%") % input.string() % err // % gpgme_strerror(err)).str()) // return res; // } // } FILE *outFile(::fopen(output.string().c_str(), "w+")); if (outFile) { err = gpgme_data_new_from_stream(&out, outFile); if (err) { GENERIC_LOG_MESSAGE( LogLevel::error, (boost::format("Failed to set output file %1% for GPG with error: %2% --> %3%") % output.string() % err % gpgme_strerror(err)).str()) return res; } // else { // err = gpgme_data_set_flag(out, "size-hint", fileSizeStr.c_str()); // // if (err) { // GENERIC_LOG_MESSAGE( // LogLevel::error, // (boost::format("Failed to set size hint for output file %1% for GPG with error: %2% --> %3%") % output.string() % err // % gpgme_strerror(err)).str()) // return res; // } // } } else { GENERIC_LOG_MESSAGE(LogLevel::error, "Failed to open out file " + output.string()); return res; } gpgme_set_progress_cb(ctx, &VCIUpdaterWrapper::progress, NULL); gpgme_decrypt_result_t dec_result; err = gpgme_op_decrypt_start(ctx, in, out); if (err) { GENERIC_LOG_MESSAGE(LogLevel::error, (boost::format("Failed to execute GPG decryption: %1% --> %2%") % err % gpgme_strerror(err)).str()) dec_result = gpgme_op_decrypt_result(ctx); return res; } else { gpgme_wait(ctx, &err, 1); if (err) { GENERIC_LOG_MESSAGE(LogLevel::error, (boost::format("Failed to execute GPG decryption: %1% --> %2%") % err % gpgme_strerror(err)).str()) dec_result = gpgme_op_decrypt_result(ctx); return res; } dec_result = gpgme_op_decrypt_result(ctx); if (dec_result->unsupported_algorithm) { GENERIC_LOG_MESSAGE(LogLevel::error, dec_result->unsupported_algorithm); return res; } } gpgme_data_release(in); gpgme_data_release(out); ::fclose(outFile); gpgme_release(ctx); mSignalUpdateProgress(mWholeUpdatePackages, mDoneUpdates + 1, 100, UpdatePhase::gpg_decripth); res = true; return res; *---------------------------------------* *Marco Bna?* -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Jun 25 15:04:20 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Jun 2021 15:04:20 +0200 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start In-Reply-To: (Marco via Gnupg-users's message of "Fri, 25 Jun 2021 09:39:55 +0200") References: Message-ID: <87eecqksdn.fsf@wheatstone.g10code.de> On Fri, 25 Jun 2021 09:39, Marco said: > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); The 1 means copy the data to an internal buffer. Use 0 here to stream the data. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From malte.gell at posteo.de Fri Jun 25 00:33:49 2021 From: malte.gell at posteo.de (Malte Gell) Date: Thu, 24 Jun 2021 22:33:49 +0000 Subject: gpg: keyserver receive failed: No name - for gpg --keyserver hkp://pool.sks-keyservers.net In-Reply-To: <24642801-6ed1-5b74-7135-801c0fbb5562@gmail.com> References: <22dda25f-0052-8d0d-083e-ae157f2d8889@posteo.de> <24642801-6ed1-5b74-7135-801c0fbb5562@gmail.com> Message-ID: Am 25.06.21 um 00:14 schrieb Brandon Anderson via Gnupg-users: > >> The keyserver situation seems a bit difficult currently, maybe >> https://keys.openpgp.org/ is the best (easiest) workaround for now. >> >> But WKD is really worth looking at! >> > > My understanding is the Ubuntu Key-server is staying up, I could be > wrong, but https://keyserver.ubuntu.com/ seems to be functioning. It is > worth noting that the keys.openpgp.org keyserver is not web of trust but > explicitly trusting that keyserver to validate a person's identity. I think it?s good to distribute a key thru several channels, keys.openpgp.org is a good way to establish some trust in a key when fetching it for the first time. Afterwards you can still get the same key from a different source with WoT signatures added. If you have no fountain at all for a key to establish a chain(web) of trust, keys.openpgp.org is the only way to have some trust in a key. The WoT works only if you have some fountain for the trust. From bna.marco at gmail.com Fri Jun 25 15:15:04 2021 From: bna.marco at gmail.com (Marco) Date: Fri, 25 Jun 2021 15:15:04 +0200 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start In-Reply-To: <87eecqksdn.fsf@wheatstone.g10code.de> References: <87eecqksdn.fsf@wheatstone.g10code.de> Message-ID: After reading the documentation I supposed it was not correct because says to be not implemented. I'll give a try immediately and I'll let you know (but I expect it will work!) Thank you!!! Il giorno ven 25 giu 2021 alle ore 15:05 Werner Koch ha scritto: > On Fri, 25 Jun 2021 09:39, Marco said: > > > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); > > The 1 means copy the data to an internal buffer. Use 0 here to stream > the data. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bna.marco at gmail.com Fri Jun 25 15:26:24 2021 From: bna.marco at gmail.com (Marco) Date: Fri, 25 Jun 2021 15:26:24 +0200 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start In-Reply-To: References: <87eecqksdn.fsf@wheatstone.g10code.de> Message-ID: I've switched 1 to 0 for > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); as suggested. The error is: Failed to set input file with error: 117440567 --> Invalid value Il giorno ven 25 giu 2021 alle ore 15:15 Marco ha scritto: > After reading the documentation I supposed it was not correct because > says to be not implemented. > > I'll give a try immediately and I'll let you know (but I expect it will > work!) > > Thank you!!! > > Il giorno ven 25 giu 2021 alle ore 15:05 Werner Koch ha > scritto: > >> On Fri, 25 Jun 2021 09:39, Marco said: >> >> > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); >> >> The 1 means copy the data to an internal buffer. Use 0 here to stream >> the data. >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bna.marco at gmail.com Fri Jun 25 16:21:42 2021 From: bna.marco at gmail.com (Marco) Date: Fri, 25 Jun 2021 16:21:42 +0200 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start In-Reply-To: References: <87eecqksdn.fsf@wheatstone.g10code.de> Message-ID: I've found a workaround using gpgme_data_cbs implementing my own read and write functions. If any other way is available or you have any suggestions please let me know! Thanks, Marco Il giorno ven 25 giu 2021 alle ore 15:26 Marco ha scritto: > I've switched 1 to 0 for > > > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); > > as suggested. > The error is: > Failed to set input file with error: 117440567 --> Invalid value > > > > > Il giorno ven 25 giu 2021 alle ore 15:15 Marco ha > scritto: > >> After reading the documentation I supposed it was not correct because >> says to be not implemented. >> >> I'll give a try immediately and I'll let you know (but I expect it will >> work!) >> >> Thank you!!! >> >> Il giorno ven 25 giu 2021 alle ore 15:05 Werner Koch ha >> scritto: >> >>> On Fri, 25 Jun 2021 09:39, Marco said: >>> >>> > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); >>> >>> The 1 means copy the data to an internal buffer. Use 0 here to stream >>> the data. >>> >>> >>> Salam-Shalom, >>> >>> Werner >>> >>> -- >>> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Fri Jun 25 16:52:20 2021 From: wk at gnupg.org (Werner Koch) Date: Fri, 25 Jun 2021 16:52:20 +0200 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start In-Reply-To: (Marco via Gnupg-users's message of "Fri, 25 Jun 2021 15:26:24 +0200") References: <87eecqksdn.fsf@wheatstone.g10code.de> Message-ID: <87a6nekndn.fsf@wheatstone.g10code.de> On Fri, 25 Jun 2021 15:26, Marco said: > Failed to set input file with error: 117440567 --> Invalid value Sorry. I missed that we did not implement that (because it is actually a legacy compatibility function). Thus I can't offer you any function which takes a file name. You need to open the file yourself and use one of these functions: gpgme_error_t gpgme_data_new_from_cbs (gpgme_data_t *dh, gpgme_data_cbs_t cbs, void *handle); That is the most flexible one. But there are some convenience functions which relieves you from implementing the callbacks: gpgme_error_t gpgme_data_new_from_fd (gpgme_data_t *dh, int fd); This takes a file descriptior; i.e. open(3). gpgme_error_t gpgme_data_new_from_stream (gpgme_data_t *dh, FILE *stream); This takes an stdio stream; i.e. fopen(3). gpgme_error_t gpgme_data_new_from_estream (gpgme_data_t *r_dh, gpgrt_stream_t stream); This takes a estream_t, i.e. gpgrt_fopen (aka es_fopen). For an example how to use the see gpgme/tests/run-decrypt.c Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bna.marco at gmail.com Fri Jun 25 17:12:57 2021 From: bna.marco at gmail.com (Marco) Date: Fri, 25 Jun 2021 17:12:57 +0200 Subject: GPGME Cannot allocate memory on gpgme_op_decrypt_start (Werner Koch) In-Reply-To: References: Message-ID: Il giorno ven 25 giu 2021 alle ore 16:55 ha scritto: > Send Gnupg-users mailing list submissions to > gnupg-users at gnupg.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnupg.org/mailman/listinfo/gnupg-users > or, via email, send a message with subject or body 'help' to > gnupg-users-request at gnupg.org > > You can reach the person managing the list at > gnupg-users-owner at gnupg.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gnupg-users digest..." > Today's Topics: > > 1. Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start > (Werner Koch) > 2. Re: gpg: keyserver receive failed: No name - for gpg > --keyserver hkp://pool.sks-keyservers.net (Malte Gell) > 3. Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start (Marco) > 4. Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start (Marco) > 5. Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start (Marco) > 6. Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start > (Werner Koch) > > > > ---------- Forwarded message ---------- > From: Werner Koch > To: Marco via Gnupg-users > Cc: Marco > Bcc: > Date: Fri, 25 Jun 2021 15:04:20 +0200 > Subject: Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start > On Fri, 25 Jun 2021 09:39, Marco said: > > > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); > > The 1 means copy the data to an internal buffer. Use 0 here to stream > the data. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > > > > ---------- Forwarded message ---------- > From: Malte Gell > To: gnupg-users at gnupg.org > Cc: > Bcc: > Date: Thu, 24 Jun 2021 22:33:49 +0000 > Subject: Re: gpg: keyserver receive failed: No name - for gpg --keyserver > hkp://pool.sks-keyservers.net > Am 25.06.21 um 00:14 schrieb Brandon Anderson via Gnupg-users: > > > >> The keyserver situation seems a bit difficult currently, maybe > >> https://keys.openpgp.org/ is the best (easiest) workaround for now. > >> > >> But WKD is really worth looking at! > >> > > > > My understanding is the Ubuntu Key-server is staying up, I could be > > wrong, but https://keyserver.ubuntu.com/ seems to be functioning. It is > > worth noting that the keys.openpgp.org keyserver is not web of trust but > > explicitly trusting that keyserver to validate a person's identity. > > I think it?s good to distribute a key thru several channels, > keys.openpgp.org is a good way to establish some trust in a key when > fetching it for the first time. Afterwards you can still get the same > key from a different source with WoT signatures added. > > If you have no fountain at all for a key to establish a chain(web) of > trust, keys.openpgp.org is the only way to have some trust in a key. The > WoT works only if you have some fountain for the trust. > > > > > > ---------- Forwarded message ---------- > From: Marco > To: Marco via Gnupg-users > Cc: > Bcc: > Date: Fri, 25 Jun 2021 15:15:04 +0200 > Subject: Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start > After reading the documentation I supposed it was not correct because > says to be not implemented. > > I'll give a try immediately and I'll let you know (but I expect it will > work!) > > Thank you!!! > > Il giorno ven 25 giu 2021 alle ore 15:05 Werner Koch ha > scritto: > >> On Fri, 25 Jun 2021 09:39, Marco said: >> >> > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); >> >> The 1 means copy the data to an internal buffer. Use 0 here to stream >> the data. >> >> >> Salam-Shalom, >> >> Werner >> >> -- >> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >> > > > > ---------- Forwarded message ---------- > From: Marco > To: Marco via Gnupg-users > Cc: > Bcc: > Date: Fri, 25 Jun 2021 15:26:24 +0200 > Subject: Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start > I've switched 1 to 0 for > > > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); > > as suggested. > The error is: > Failed to set input file with error: 117440567 --> Invalid value > > > > > Il giorno ven 25 giu 2021 alle ore 15:15 Marco ha > scritto: > >> After reading the documentation I supposed it was not correct because >> says to be not implemented. >> >> I'll give a try immediately and I'll let you know (but I expect it will >> work!) >> >> Thank you!!! >> >> Il giorno ven 25 giu 2021 alle ore 15:05 Werner Koch ha >> scritto: >> >>> On Fri, 25 Jun 2021 09:39, Marco said: >>> >>> > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); >>> >>> The 1 means copy the data to an internal buffer. Use 0 here to stream >>> the data. >>> >>> >>> Salam-Shalom, >>> >>> Werner >>> >>> -- >>> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >>> >> > > > ---------- Forwarded message ---------- > From: Marco > To: Marco via Gnupg-users > Cc: > Bcc: > Date: Fri, 25 Jun 2021 16:21:42 +0200 > Subject: Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start > I've found a workaround using gpgme_data_cbs implementing my own read and > write functions. > > If any other way is available or you have any suggestions please let me > know! > > Thanks, > Marco > > Il giorno ven 25 giu 2021 alle ore 15:26 Marco ha > scritto: > >> I've switched 1 to 0 for >> >> > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); >> >> as suggested. >> The error is: >> Failed to set input file with error: 117440567 --> Invalid value >> >> >> >> >> Il giorno ven 25 giu 2021 alle ore 15:15 Marco ha >> scritto: >> >>> After reading the documentation I supposed it was not correct because >>> says to be not implemented. >>> >>> I'll give a try immediately and I'll let you know (but I expect it will >>> work!) >>> >>> Thank you!!! >>> >>> Il giorno ven 25 giu 2021 alle ore 15:05 Werner Koch ha >>> scritto: >>> >>>> On Fri, 25 Jun 2021 09:39, Marco said: >>>> >>>> > err = gpgme_data_new_from_file(&in, input.string().c_str(), 1); >>>> >>>> The 1 means copy the data to an internal buffer. Use 0 here to stream >>>> the data. >>>> >>>> >>>> Salam-Shalom, >>>> >>>> Werner >>>> >>>> -- >>>> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. >>>> >>> > > > ---------- Forwarded message ---------- > From: Werner Koch > To: Marco via Gnupg-users > Cc: Marco > Bcc: > Date: Fri, 25 Jun 2021 16:52:20 +0200 > Subject: Re: GPGME Cannot allocate memory on gpgme_op_decrypt_start > On Fri, 25 Jun 2021 15:26, Marco said: > > > Failed to set input file with error: 117440567 --> Invalid value > > Sorry. I missed that we did not implement that (because it is actually > a legacy compatibility function). Thus I can't offer you any function > which takes a file name. You need to open the file yourself and use one > of these functions: > > gpgme_error_t gpgme_data_new_from_cbs (gpgme_data_t *dh, > gpgme_data_cbs_t cbs, > void *handle); > > That is the most flexible one. But there are some convenience functions > which relieves you from implementing the callbacks: > > gpgme_error_t gpgme_data_new_from_fd (gpgme_data_t *dh, int fd); > > This takes a file descriptior; i.e. open(3). > > gpgme_error_t gpgme_data_new_from_stream (gpgme_data_t *dh, FILE > *stream); > > This takes an stdio stream; i.e. fopen(3). > > gpgme_error_t gpgme_data_new_from_estream (gpgme_data_t *r_dh, > gpgrt_stream_t stream); > > This takes a estream_t, i.e. gpgrt_fopen (aka es_fopen). > > For an example how to use the see gpgme/tests/run-decrypt.c > > > Shalom-Salam, > > Werner > > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users I'll try the stream version also! Mine implementation with cbs was successful but I had some "warning", let say,logging activity. Thank you very much! Best regards, Marco Bna' -------------- next part -------------- An HTML attachment was scrubbed... URL: From vuori at notcom.org Sat Jun 26 00:08:33 2021 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Sat, 26 Jun 2021 01:08:33 +0300 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <87sg1anuin.fsf@wheatstone.g10code.de> (Werner Koch via Gnupg-users's message of "Tue, 22 Jun 2021 11:00:48 +0200") References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> <87sg1anuin.fsf@wheatstone.g10code.de> Message-ID: <87wnqhr40u.fsf@notcom.org> Werner Koch via Gnupg-users writes: > Frankly, I am not convinced about the retirement slots on the card. > They are of course useful if you rotate you key. But the question is > why you want to do this given that the keys are anyway securely stored > on a card. Whatever the merits of retired key slots for their intended use, there's another use case for them which was probably not considered by NIST: alternate certificates for X.509, SSH and similar authorization applications to work around deficiencies in existing systems. Examples: - Github allows associating one SSH public key with one account. If you need to operate multiple Github accounts, you need multiple SSH keys. - Support for EC certificates in the Samba KDC was broken at least as of version 4.10. If you need an EC certificate for SSH, you can't use the key associated with your AD/Kerberos X.509 certificate, since only RSA works for Kerberos. - Similarly, the OS on Mikrotik routers at least before version 7.x supports only RSA SSH keys. Hence, having multiple key slots available for authorization keys is quite convenient. It might be better to call these something else than "retired" slots unless aiming for total terminological consistency with PIV though. I'm currently using pivy with Yubikeys and JavaCards with PivApplet PIV for this kind of multi-key scenarios. It would be convenient if all external applications could go through gpg-agent/scute in the future instead of having to deal with pcsc-shared or similar workarounds. -Valtteri From brandon753.ba at gmail.com Sat Jun 26 08:10:03 2021 From: brandon753.ba at gmail.com (Brandon Anderson) Date: Fri, 25 Jun 2021 23:10:03 -0700 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <87wnqhr40u.fsf@notcom.org> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> <87sg1anuin.fsf@wheatstone.g10code.de> <87wnqhr40u.fsf@notcom.org> Message-ID: <72bd705a-8f9d-7d81-ada9-8efcada145b5@gmail.com> > Whatever the merits of retired key slots for their intended use, there's > another use case for them which was probably not considered by NIST: > alternate certificates for X.509, SSH and similar authorization > applications to work around deficiencies in existing systems. > > Examples: > > - Github allows associating one SSH public key with one account. If > you need to operate multiple Github accounts, you need multiple SSH > keys. > > - Support for EC certificates in the Samba KDC was broken at least as > of version 4.10. If you need an EC certificate for SSH, you can't > use the key associated with your AD/Kerberos X.509 certificate, > since only RSA works for Kerberos. > > - Similarly, the OS on Mikrotik routers at least before version 7.x > supports only RSA SSH keys. > > Hence, having multiple key slots available for authorization keys is > quite convenient. It might be better to call these something else than > "retired" slots unless aiming for total terminological consistency with > PIV though. > > I'm currently using pivy with Yubikeys > and JavaCards with PivApplet PIV for this kind of multi-key > scenarios. It would be convenient if all external applications could go > through gpg-agent/scute in the future instead of having to deal with > pcsc-shared or similar workarounds. > > -Valtteri > Those are great points; I had not thought of those use-cases! I only used the term retirement slots because it was an existing term used in PIV smartcards, but we could just call them alternative slots, supplemental slots, auxiliary slots, peripheral slots, secondary slots, or anything really, so long they can hold old keys decryption keys; my use-case is met. Thanks for posting about the PivApplet project. I was looking for something like that for either the basic cards or java cards as I wanted to tinker around with them. Do you have a specific Java card model you are using? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x255837AEF812E87E.asc Type: application/pgp-keys Size: 9076 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From listofactor at mail.ru Sat Jun 26 08:36:07 2021 From: listofactor at mail.ru (LisToFacTor) Date: Sat, 26 Jun 2021 08:36:07 +0200 Subject: Long Term Content Protection In-Reply-To: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> Message-ID: There is, perhaps, a wider perspective on the problem discussed in this thread. GPG is a reasonable tool for the protection and verification of content exchanged between two parties. Once a message reaches the recipient's operational environment, it should be decrypted, and its further protection is best addressed as part and parcel of the protection of that complete environment. After all, a message of any consequence will likely result on secondary content generated by and on the recipient's computer, that needs as much (or more) protection as the message content in transit. There are many tools and techniques for achieving that, but their use and best practices are beyond the scope of this list. From andrewg at andrewg.com Sat Jun 26 10:12:21 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 26 Jun 2021 09:12:21 +0100 Subject: Long Term Content Protection In-Reply-To: References: Message-ID: <5C372C97-92B6-4BDC-B6AB-71BD70612FD1@andrewg.com> > On 26 Jun 2021, at 08:26, LisToFacTor via Gnupg-users wrote: > > Once a message reaches > the recipient's operational environment, it should be decrypted, > and its further protection is best addressed as part and parcel > of the protection of that complete environment. But this is not the way many people use email now. It is quite common to use multiple ?operational environments? to access a common user mailbox, and that mailbox may not be under the user?s sole control. Any security model must take into account how people lready behave in practice? otherwise they will use insecure workarounds. A From vuori at notcom.org Sat Jun 26 14:24:14 2021 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Sat, 26 Jun 2021 15:24:14 +0300 Subject: Long Term Key Management With Hardware Tokens In-Reply-To: <72bd705a-8f9d-7d81-ada9-8efcada145b5@gmail.com> (Brandon Anderson via Gnupg-users's message of "Fri, 25 Jun 2021 23:10:03 -0700") References: <295fb980-3386-dfa0-2e51-52d184007bf8@gmail.com> <82db03e3-67c5-4af5-608b-b7d290d203b9@gmail.com> <87sg1anuin.fsf@wheatstone.g10code.de> <87wnqhr40u.fsf@notcom.org> <72bd705a-8f9d-7d81-ada9-8efcada145b5@gmail.com> Message-ID: <87pmw8rez5.fsf@notcom.org> Brandon Anderson via Gnupg-users writes: > Thanks for posting about the PivApplet project. I was looking for > something like that for either the basic cards or java cards as I > wanted to tinker around with them. Do you have a specific Java card > model you are using? You'll want something that implements at least JavaCard 3.0.4, since that's the first version with useful EC operations. This came out in 2011 but because smartcards move at a glacial place there are still a lot of 2.x cards on the market. The NXP J3H145 appears to be a popular and widely available dual-interface card. There is some discussion regarding cards on the SmartPGP applet issue tracker: https://github.com/ANSSI-FR/SmartPGP/issues/17 . I haven't tried other Javacards besides the J3H145. They work well, though a caveat is that they are quite slow compared to for example a Yubikey 5: operations take approximately twice as long. The J2H145 should be pretty much identical but lacks the contactless interface and is a bit cheaper. The newer J3R180 is supposedly quite a bit faster. Unless you're buying large quantities and are prepared to deal with weighty NDAs, make sure that the seller performs card initialization/pre-personalization. GlobalPlatform tools won't be able to access the card before this step. Most stores that sell single cards will do this by default, but eBay/Aliexpress sellers might not. -Valtteri From stefan.vasilev at posteo.ru Sun Jun 27 18:56:15 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Sun, 27 Jun 2021 16:56:15 +0000 Subject: Ditching OpenPGP, a new approach to signing APT repositories Message-ID: Hello, maybe interesting for some of you. https://wiki.debian.org/Teams/Apt/Spec/AptSign Regards Stefan From stefan.vasilev at posteo.ru Sun Jun 27 19:30:40 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Sun, 27 Jun 2021 17:30:40 +0000 Subject: piknik with GnuPG Message-ID: <0774f233a312d75533b688830d6fa1b9@posteo.de> Hello, some of you maybe know piknik, https://github.com/jedisct1/piknik, which allows users to copy/paste data over the Internet. I have installed the software on a VPS so you can try out piknik with GnuPG messages, prior installing it on an own server. The installed version is 0.10.1. Here are the client paramters: Passphrase: model-narrow-chief-often-under-avocado-dance-course-list-battle -----BEGIN PGP MESSAGE----- jA0EBwMCcgIY9heG7BVg0sDdAXWuViY7V7OKvPJqdRJVMV5oifxiF/ZxwOLzaQyP QUDYCItfWL+V6KKqCMyxJDJ5wOstb8EAM14BNWP4TqrqobO9GQJLHYoh1L8Gr0/W drXWp6kCs/tuHegeES36vUkz17J4APnSvKy40c/GtABcZTniSGfRI65PzUOqa9He xCtLQcRZEUNcHMPHs1fe2h593OBjteGEdY7bYNQTh0dwuIZzCxqM1sFPeiZR0wCh PUcHt8jM8oT04BszeVzMaSe9JH5NtNIE44Vzwzl9NoEn4Ef0PQ/W4xS8m0MfhAED FnGxVUMmJBGTKoXRG1dlnMlm/W4Q8+L4NF3D+HKaSeqX1ThGDyzS4P6UudsnNLN7 Frr0YUb8L53ftumJUXkuwrGddT725uZIkGpFrtoPfvLOHk0ya3h8CWXEsycE6BiJ Wao/ofieEbqU71+xUAbek4qK/aZprRr/LYGBHXNn2t6lRpB9KWw10esF8b/EQnNs ubMFRAz81IbkbRKZZcPxxpQKprFOtSUL6Fd/Zc38biNGPWSr9WvliSOL4Q0DjrM= =WOWk -----END PGP MESSAGE----- Regards Stefan From jharris at widomaker.com Mon Jun 28 01:41:16 2021 From: jharris at widomaker.com (Jason Harris) Date: Sun, 27 Jun 2021 19:41:16 -0400 Subject: recommendation for key servers In-Reply-To: References: Message-ID: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> There are still SKS servers running, but several are unsynchronized, including, apparently, pgp.mit.edu. Of course, they have the same key import/poisoning problems already mentioned on these lists? Here are the hockeypuck servers I could find, all synchronizing properly and apparently exchanging data (minus the unwanted packets) with the SKS servers that are synchronized: http://keys.andreas-puls.de/pks/lookup?op=stats http://keys2.andreas-puls.de/pks/lookup?op=stats http://keys3.andreas-puls.de/pks/lookup?op=stats http://pgp.cyberbits.eu/pks/lookup?op=stats http://pgp.re:11371/pks/lookup?op=stats https://pgpkeys.eu/pks/lookup?op=stats https://keybath.trifence.ch/pks/lookup?op=stats https://keyserver.trifence.ch/pks/lookup?op=stats HTH. (Please excuse the HTML.) Sent from my iPad > On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel wrote: > > ? > Hi, we heard that sks-keyservers.net will be depreciated > so we were wondering what service we should use in the application default settings > We I mean TDE devs > > where do we go from here? > > thank you in advance > BR > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.vasilev at posteo.ru Mon Jun 28 19:00:09 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Mon, 28 Jun 2021 17:00:09 +0000 Subject: recommendation for key servers In-Reply-To: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> References: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> Message-ID: Jason Harris wrote: > There are still SKS servers running, but several are unsynchronized, > including, apparently, pgp.mit.edu. Of course, they have the same key > import/poisoning problems already mentioned on these lists? > > Here are the hockeypuck servers I could find, all synchronizing > properly and apparently exchanging data (minus the unwanted packets) > with the SKS servers that are synchronized: > > * http://keys.andreas-puls.de/pks/lookup?op=stats > * http://keys2.andreas-puls.de/pks/lookup?op=stats > * http://keys3.andreas-puls.de/pks/lookup?op=stats > * http://pgp.cyberbits.eu/pks/lookup?op=stats > * http://pgp.re:11371/pks/lookup?op=stats > * https://pgpkeys.eu/pks/lookup?op=stats > * https://keybath.trifence.ch/pks/lookup?op=stats > * https://keyserver.trifence.ch/pks/lookup?op=stats Thanks for the info. When looking at the stats, why are there IMHO such high numbers (daily) on updated pub keys, compared to submitted ones? Regards Stefan From andrewg at andrewg.com Mon Jun 28 19:42:02 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 28 Jun 2021 18:42:02 +0100 Subject: recommendation for key servers In-Reply-To: References: Message-ID: > On 28 Jun 2021, at 18:02, ?????? ???????? via Gnupg-users wrote: > > When looking at the stats, why are there IMHO such high numbers > (daily) on updated pub keys, compared to submitted ones? It?s not clear, but it may be due to a lack of canonical ordering of packets. Say Alice and Bob have both signed my key, but keyserver A and keyserver B have different copies of my key with Alice and Bob?s signatures in opposite order from each other. These keys will have different checksums, even though they contain the same functional information. If the sync process doesn?t result in A and B reordering the sigs in the same way, then they will keep syncing (successfully!) forever, incrementing the number of changes each time. A From stefan.vasilev at posteo.ru Mon Jun 28 21:46:43 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Mon, 28 Jun 2021 19:46:43 +0000 Subject: recommendation for key servers In-Reply-To: References: Message-ID: Andrew Gallagher wrote: >> On 28 Jun 2021, at 18:02, ?????? ???????? via Gnupg-users >> wrote: >> >> When looking at the stats, why are there IMHO such high numbers >> (daily) on updated pub keys, compared to submitted ones? > > It?s not clear, but it may be due to a lack of canonical ordering of > packets. Say Alice and Bob have both signed my key, but keyserver A > and keyserver B have different copies of my key with Alice and Bob?s > signatures in opposite order from each other. These keys will have > different checksums, even though they contain the same functional > information. If the sync process doesn?t result in A and B reordering > the sigs in the same way, then they will keep syncing (successfully!) > forever, incrementing the number of changes each time. Ah, thanks. That makes sense, but could be then considered, software wise, as unwanted behaviour. Regards Stefan From sven.schultschik at siemens.com Mon Jun 28 21:37:58 2021 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Mon, 28 Jun 2021 19:37:58 +0000 Subject: AW: gpgme_op_decrypt segfault In-Reply-To: <202106141059.05559.bernhard@intevation.de> References: <202106141059.05559.bernhard@intevation.de> Message-ID: Hello all together, I have created a small Applikation to zip and encrypte and vise versa. I struggle at the point of err = gpgme_op_decrypt(ctx, in, out); Which terminates with an segfault if not sufficient access rights are available. If I run with sudo it works as expected. The segfault is not catchable, I tried. Am I doing something wrong or is this a bug in the lib? I would expect a catchable exception. Here is a little code snippet from the application. int decryptBackup(string backupname, string webpw) { fprintf(stderr, "Decrypte backup start\n"); filesystem::path encryptedFullBackupPath; try { encryptedFullBackupPath = getFullBackupPath(backupname, true); } catch (exception &ex) { if (webpw != "") { throw ex; } return false; } gpgme_check_version(NULL); gpgme_ctx_t ctx; gpgme_error_t err; gpgme_data_t in, out; gpgme_decrypt_result_t result; init_gpgme(); err = gpgme_new(&ctx); fail_if_err(err); gpgme_set_armor(ctx, 1); fprintf(stderr, "instream\n"); FILE *instream; instream = fopen(encryptedFullBackupPath.c_str(), "r"); if (instream == NULL) { throw runtime_error("Backup archive not found " + encryptedFullBackupPath.string() + "\n"); } err = gpgme_data_new_from_stream(&in, instream); fail_if_err(err, in, out, instream); fprintf(stderr, "outstream\n"); filesystem::path fullBackupPath = getFullBackupPath(backupname, false, false); FILE *outstream; outstream = fopen(fullBackupPath.c_str(), "w"); err = gpgme_data_new_from_stream(&out, outstream); fail_if_err(err, in, out, instream, outstream); if (!(webpw.empty() || webpw == "")) { _pw = webpw; err = gpgme_set_pinentry_mode(ctx, GPGME_PINENTRY_MODE_LOOPBACK); fail_if_err(err, in, out, instream, outstream, fullBackupPath); gpgme_set_passphrase_cb(ctx, passphrase_cb, NULL); } fprintf(stderr, "gpgme_op_decrypt(ctx, in, out)\n"); try{ err = gpgme_op_decrypt(ctx, in, out); }catch (const char *msgc) { string msg = msgc; size_t found = msg.find("Segmentation"); fprintf(stderr, "lib const char. %s\nFound %zi\n", msgc, found); if (found != string::npos) fprintf(stderr, "No permission.\n"); else fprintf(stderr, "%s\n", msgc); exit(EXIT_FAILURE); } catch (const std::exception &e) { string msg = e.what(); size_t found = msg.find("Segmentation"); fprintf(stderr, "lib exception. %s\nFound %zi\n", msg.c_str(), found); if (found != string::npos) fprintf(stderr, "No permission.\n"); else fprintf(stderr, "%s\n", msg.c_str()); exit(EXIT_FAILURE); } catch (...) { fprintf(stderr, "Unexcpected error!\n"); exit(EXIT_FAILURE); } fail_if_err(err, in, out, instream, outstream); fprintf(stderr, "gpgme_op_decrypt_result(ctx)"); result = gpgme_op_decrypt_result(ctx); if (result->unsupported_algorithm) { string err(result->unsupported_algorithm); throw runtime_error("Unsupported algorithm: " + err + "\n"); } fprintf(stderr, "Decrypte backup closing"); fclose(instream); fclose(outstream); gpgme_data_release(in); gpgme_data_release(out); gpgme_release(ctx); fprintf(stderr, "Decrypte backup return"); return true; } Thank you Regards Sven -----Urspr?ngliche Nachricht----- Von: Gnupg-de Im Auftrag von Bernhard Reiter Gesendet: Montag, 14. Juni 2021 10:59 An: gnupg-de at gnupg.org Betreff: Re: gpgme_op_decrypt segfault Hallo Am Freitag 11 Juni 2021 17:12:58 schrieb Schultschik, Sven: > err = gpgme_op_decrypt(ctx, in, out); einen nicht catchbaren > Segmentation fault schmei?t, wenn die user rechte nicht ausreichend sind. > > Sollte gpgme_op_decrypt nicht den err zur?ckgeben, wenn etwas schief geht? prinzipiell w?rde ich das auch erwarten. Es kommt aber auch darauf an, da es ja unendlich viele spannende Problemf?lle geben kann, ist bei manchen ein komplettes Aussteigen nicht ganz verkehrt. Manchmal ist auch soviel kaputt, dass ein sinnvolles Fehlerberichten nicht m?glich ist. Wenn Du ein leicht nachvollziehbares Beispiel hast, dann lohnt es sich vielleicht, das auf dev.gnupg.org zu berichten. Gru?, Bernhard -- https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.intevat ion.de%2F~bernhard&data=04%7C01%7Csven.schultschik%40siemens.com%7C7fe8a 2cb993f47eccb0908d92f12b183%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637 592580044549461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=M9pAUowNtoP0mEgnegAWPeF2wEYm AEKfCU3bRgg2FCI%3D&reserved=0 ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 14944 bytes Desc: not available URL: From jeanjacquesbrucker at gmail.com Mon Jun 28 11:41:43 2021 From: jeanjacquesbrucker at gmail.com (Jean-Jacques Brucker) Date: Mon, 28 Jun 2021 11:41:43 +0200 Subject: recommendation for key servers In-Reply-To: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> References: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> Message-ID: <9db62a14-4605-0636-bd61-83ceafb1d271@gmail.com> "Hell is paved with good intention." GDPR came from the laudable intention of limiting the power of GAFAMs and other data brokers, inside our private lives. But the text maintains a confusion between personal data and private data. Some personal data is not and should not be private. Email could be one of them, if everyone used a web of trust, which would allow us to know more precisely who is the sender, and to fight more effectively against SPAM. (NB: In addition, the text annoys small organizations more than large groups which have the means to circumvent it, via internationalization and lobbying) I have a public email, and i would like to have a email service or client which may delete automatically unsigned messages, and give me the feature to order received email depending from a "proximity" regarding the WOT, or a "confidence" regarding my trustdb. About the keystore, I imagined 9 years ago that a key server receiving a certificate update, not signed by its owner, could send a message to the owner (by default 1 time per day), in order to ask it to validate, or not, the modifications, before synchronizing the updated certificate, signed by its owner, on other key servers. So I had to write a draft and start implementing a new MIME type for HTTP for these purposes, to upgrade HKP protocol : https://github.com/Open-UDC/open-udc/blob/master/docs/rfc/HTTP_OpenPGP_Authentication.draft.txt https://github.com/Open-UDC/thttpgpd But unfortunately I was perhaps too shy to talk about these ideas on an international mailing list, and they received little echo in my French environment : https://linuxfr.org/users/jbar/journaux/thttpgpd-ou-comment-openudc-a-ressuscite-le-bon-vieux-thttpd Today WKD / WKS seems to me a good compromise for the trilemma keystore, and probably the best way to get the last version of "first-party-attested" certificates, which fresh uid / sub-keys updates and revocations. But it's only today that I discovered your git repository https://gitlab.com/openpgp-wg/rfc4880bis and your idea of ??"first-party-attested third-party certifications" (1pa3pc). I therefore apologize if I do not add anything new or interesting to the debate today. ---- Jean-Jacques B. Le 28/06/2021 ? 01:41, Jason Harris via Gnupg-devel a ?crit?: > > There are still SKS servers running, but several are unsynchronized, > including, apparently, pgp.mit.edu. ?Of course, they have the same key > import/poisoning problems already mentioned on these lists? > > Here are the hockeypuck servers I could find, all synchronizing > properly and apparently exchanging data (minus the unwanted packets) > with the SKS servers that are synchronized: > > * http://keys.andreas-puls.de/pks/lookup?op=stats > * http://keys2.andreas-puls.de/pks/lookup?op=stats > * http://keys3.andreas-puls.de/pks/lookup?op=stats > * http://pgp.cyberbits.eu/pks/lookup?op=stats > * http://pgp.re:11371/pks/lookup?op=stats > * https://pgpkeys.eu/pks/lookup?op=stats > * https://keybath.trifence.ch/pks/lookup?op=stats > * https://keyserver.trifence.ch/pks/lookup?op=stats > > HTH. ?(Please excuse the HTML.) > > Sent from my iPad > >> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel >> wrote: >> >> ? >> Hi, we heard that sks-keyservers.net will >> be depreciated >> so we were wondering what service we should use in the application >> default settings >> We I mean TDE devs >> >> where do we go from here? >> >> thank you in advance >> BR >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xA3983A40D1458443.asc Type: application/pgp-keys Size: 40225 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From cjac at colliertech.org Tue Jun 29 01:33:48 2021 From: cjac at colliertech.org (C.J. Collier) Date: Mon, 28 Jun 2021 16:33:48 -0700 Subject: recommendation for key servers In-Reply-To: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> References: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> Message-ID: I was thinking of build a keystone out of perl and bigquery, but I haven't gotten around to it yet. At least not the bigquery part. I'll share the perl http listener and dispatch server if anyone's interested. On Sun, Jun 27, 2021, 18:04 Jason Harris via Gnupg-users < gnupg-users at gnupg.org> wrote: > > There are still SKS servers running, but several are unsynchronized, > including, apparently, pgp.mit.edu. Of course, they have the same key > import/poisoning problems already mentioned on these lists? > > Here are the hockeypuck servers I could find, all synchronizing properly > and apparently exchanging data (minus the unwanted packets) with the SKS > servers that are synchronized: > > - http://keys.andreas-puls.de/pks/lookup?op=stats > - http://keys2.andreas-puls.de/pks/lookup?op=stats > - http://keys3.andreas-puls.de/pks/lookup?op=stats > - http://pgp.cyberbits.eu/pks/lookup?op=stats > - http://pgp.re:11371/pks/lookup?op=stats > - https://pgpkeys.eu/pks/lookup?op=stats > - https://keybath.trifence.ch/pks/lookup?op=stats > - https://keyserver.trifence.ch/pks/lookup?op=stats > > HTH. (Please excuse the HTML.) > > Sent from my iPad > > On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel < > gnupg-devel at gnupg.org> wrote: > > ? > Hi, we heard that sks-keyservers.net will be depreciated > so we were wondering what service we should use in the application default > settings > We I mean TDE devs > > where do we go from here? > > thank you in advance > BR > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From cjac at colliertech.org Tue Jun 29 02:52:21 2021 From: cjac at colliertech.org (C.J. Collier) Date: Mon, 28 Jun 2021 17:52:21 -0700 Subject: recommendation for key servers In-Reply-To: References: <2E8218E9-5680-4F4B-BE6F-3F7EE7CD96EA@widomaker.com> Message-ID: *keyserver of course. Please excuse my html, typos and use of soft keyboards. On Mon, Jun 28, 2021, 16:33 C.J. Collier wrote: > I was thinking of build a keystone out of perl and bigquery, but I haven't > gotten around to it yet. At least not the bigquery part. I'll share the > perl http listener and dispatch server if anyone's interested. > > On Sun, Jun 27, 2021, 18:04 Jason Harris via Gnupg-users < > gnupg-users at gnupg.org> wrote: > >> >> There are still SKS servers running, but several are unsynchronized, >> including, apparently, pgp.mit.edu. Of course, they have the same key >> import/poisoning problems already mentioned on these lists? >> >> Here are the hockeypuck servers I could find, all synchronizing properly >> and apparently exchanging data (minus the unwanted packets) with the SKS >> servers that are synchronized: >> >> - http://keys.andreas-puls.de/pks/lookup?op=stats >> - http://keys2.andreas-puls.de/pks/lookup?op=stats >> - http://keys3.andreas-puls.de/pks/lookup?op=stats >> - http://pgp.cyberbits.eu/pks/lookup?op=stats >> - http://pgp.re:11371/pks/lookup?op=stats >> - https://pgpkeys.eu/pks/lookup?op=stats >> - https://keybath.trifence.ch/pks/lookup?op=stats >> - https://keyserver.trifence.ch/pks/lookup?op=stats >> >> HTH. (Please excuse the HTML.) >> >> Sent from my iPad >> >> On Jun 24, 2021, at 7:19 PM, deloptes via Gnupg-devel < >> gnupg-devel at gnupg.org> wrote: >> >> ? >> Hi, we heard that sks-keyservers.net will be depreciated >> so we were wondering what service we should use in the application >> default settings >> We I mean TDE devs >> >> where do we go from here? >> >> thank you in advance >> BR >> _______________________________________________ >> Gnupg-devel mailing list >> Gnupg-devel at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-devel >> >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> http://lists.gnupg.org/mailman/listinfo/gnupg-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Tue Jun 29 08:37:56 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 29 Jun 2021 08:37:56 +0200 Subject: Ditching OpenPGP, a new approach to signing APT repositories In-Reply-To: References: Message-ID: <202106290838.03087.bernhard@intevation.de> Am Sonntag 27 Juni 2021 18:56:15 schrieb ?????? ???????? via Gnupg-users: > maybe interesting for some of you. > https://wiki.debian.org/Teams/Apt/Spec/AptSign This does not have references on the problems it is claiming to address. No description of the context where it is supposed to be used and what part it will play in the security. Also there is no mention of how the trust relation of the public keys will be established. So not yet possible to evaluate the page, it looke like a 0.2 draft in a wiki and probably gets to the point of being an interesting proposal later. Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From kloecker at kde.org Tue Jun 29 09:20:19 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 29 Jun 2021 09:20:19 +0200 Subject: gpgme_op_decrypt segfault In-Reply-To: References: <202106141059.05559.bernhard@intevation.de> Message-ID: <17864897.AEEdZQRVtZ@breq> Hi, On Montag, 28. Juni 2021 21:37:58 CEST Schultschik, Sven via Gnupg-users wrote: > Hello all together, > > I have created a small Applikation to zip and encrypte and vise versa. > > I struggle at the point of err = gpgme_op_decrypt(ctx, in, out); > Which terminates with an segfault if not sufficient access rights are > available. If I run with sudo it works as expected. It would be really helpful if you'd give us the backtrace you get for the segfault. Moreover, it is unclear what you mean by "not sufficient access rights are available". Is the input file only readable by root? Or is only root allowed to write to fullBackupPath? Quite frankly, it's up to you, the caller/user of gpgme, to check whether the fopen() calls succeeded before you pass the streams to gpgme. You do check instream for being NULL, but apparently you forgot to check outstream. Should gpgme_data_new_from_stream() check for a null pointer passed to it? Maybe. Should you pass a NULL pointer to gpgme_data_new_from_stream()? Definitely not. It makes no sense because how should gpgme_data_new_from_stream() know the reason for the NULL pointer? FWIW, I just checked. gpgme_data_new_from_stream() does not check for a NULL pointer. I guess this could be changed. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From sven.schultschik at siemens.com Tue Jun 29 11:59:14 2021 From: sven.schultschik at siemens.com (Schultschik, Sven) Date: Tue, 29 Jun 2021 09:59:14 +0000 Subject: AW: gpgme_op_decrypt segfault In-Reply-To: <17864897.AEEdZQRVtZ@breq> References: <202106141059.05559.bernhard@intevation.de> <17864897.AEEdZQRVtZ@breq> Message-ID: Hi Ingo, you were totally right. I looked now for days at the code and didn't saw this trivial fault. The Nullpoint check for the outstream was missing. So I check now the outstream for nullpointer and catch it. But a null point check for gpgme wouldn't be a bad idea. This way it could be a catchable exception. Thank you for your two fresh eyes and the hint. Regards Sven -----Urspr?ngliche Nachricht----- Von: Gnupg-users Im Auftrag von Ingo Kl?cker Gesendet: Dienstag, 29. Juni 2021 09:20 An: gnupg-users at gnupg.org Betreff: Re: gpgme_op_decrypt segfault Hi, On Montag, 28. Juni 2021 21:37:58 CEST Schultschik, Sven via Gnupg-users wrote: > Hello all together, > > I have created a small Applikation to zip and encrypte and vise versa. > > I struggle at the point of err = gpgme_op_decrypt(ctx, in, out); > Which terminates with an segfault if not sufficient access rights are > available. If I run with sudo it works as expected. It would be really helpful if you'd give us the backtrace you get for the segfault. Moreover, it is unclear what you mean by "not sufficient access rights are available". Is the input file only readable by root? Or is only root allowed to write to fullBackupPath? Quite frankly, it's up to you, the caller/user of gpgme, to check whether the fopen() calls succeeded before you pass the streams to gpgme. You do check instream for being NULL, but apparently you forgot to check outstream. Should gpgme_data_new_from_stream() check for a null pointer passed to it? Maybe. Should you pass a NULL pointer to gpgme_data_new_from_stream()? Definitely not. It makes no sense because how should gpgme_data_new_from_stream() know the reason for the NULL pointer? FWIW, I just checked. gpgme_data_new_from_stream() does not check for a NULL pointer. I guess this could be changed. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 14944 bytes Desc: not available URL: From konstantin at linuxfoundation.org Tue Jun 29 14:44:39 2021 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Tue, 29 Jun 2021 08:44:39 -0400 Subject: Ditching OpenPGP, a new approach to signing APT repositories In-Reply-To: <202106290838.03087.bernhard@intevation.de> References: <202106290838.03087.bernhard@intevation.de> Message-ID: <20210629124439.jklys4ibqqei5fih@nitro.local> On Tue, Jun 29, 2021 at 08:37:56AM +0200, Bernhard Reiter wrote: > Am Sonntag 27 Juni 2021 18:56:15 schrieb ?????? ???????? via Gnupg-users: > > maybe interesting for some of you. > > https://wiki.debian.org/Teams/Apt/Spec/AptSign > > This does not have references on the problems it is claiming to address. > > No description of the context where it is supposed to be used > and what part it will play in the security. I can fill it in here a bit. Debian doesn't sign individual .deb packages, but instead signs APT repository metadata. Traditionally, a PGP key was used for this, with the public counterpart being distributed either via the distro media itself (e.g. iso images), or via https-based downloads. With this change, they are replacing PGP with ed25519, but everything else remains pretty much the same -- the signing is done by centralized distro infrastructure. > Also there is no mention of how the trust relation of the public > keys will be established. The same as before -- they are downloaded with iso images, or retrieved from the website via https. While there is no built-in mechanics for distributing key revocation for ed25519 keys, this was not really a consideration before either (even if you can publish a revocation certificate for a PGP key used for this purpose now, very few people will know what to do with it). > So not yet possible to evaluate the page, it looke like a 0.2 draft > in a wiki and probably gets to the point of being an interesting proposal > later. Most notably, "Ditching OpenPGP" is wildly inaccurate. OpenPGP is still used for all other Debian maintainer operations -- it's only being replaced in one small area where key management and trust were used in least PGP-like ways. -K From wk at gnupg.org Tue Jun 29 15:56:40 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Jun 2021 15:56:40 +0200 Subject: AW: gpgme_op_decrypt segfault In-Reply-To: (Sven via Gnupg-users Schultschik's message of "Tue, 29 Jun 2021 09:59:14 +0000") References: <202106141059.05559.bernhard@intevation.de> <17864897.AEEdZQRVtZ@breq> Message-ID: <87im1whizr.fsf@wheatstone.g10code.de> On Tue, 29 Jun 2021 09:59, Schultschik, Sven said: > I looked now for days at the code and didn't saw this trivial fault. The > Nullpoint check for the outstream was missing. valgrind is your best friend in such cases. > But a null point check for gpgme wouldn't be a bad idea. This way it could > be a catchable exception. We can do that to make things more robust but other stdio functions also don't check for NULL. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From stefan.vasilev at posteo.ru Tue Jun 29 17:31:43 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Tue, 29 Jun 2021 15:31:43 +0000 Subject: BSI - Why PQC for Thunderbird and not gpg4win in the first =?UTF-8?Q?place=3F?= Message-ID: <392d515b87f6277a59adba7a9eb95c10@posteo.de> Hello Werner and all, I don't understand why the BSI is looking for Post Quantum Cryptography support with OpenPGP for Thunderbird and not for the promoted gpg4win, in the first place? Text in German language: https://www.evergabe-online.de/tenderdetails.html?5&id=397181 As understood, Germany recently passed a law to strengthen authorities to allow the usage of their Government trojan, which tells me that using gpg4win usage on offline devices would be much much more secure than using Thunderbird on online devices, with PQC support. Another thing I do not understand is that the winners of NIST's PQC round three are not yet announced and why is the BSI then not waiting? Any thoughts to share would be very appreciated. Regards Stefan From bernhard at intevation.de Tue Jun 29 17:53:53 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 29 Jun 2021 17:53:53 +0200 Subject: Ditching OpenPGP, a new approach to signing APT repositories In-Reply-To: <20210629124439.jklys4ibqqei5fih@nitro.local> References: <202106290838.03087.bernhard@intevation.de> <20210629124439.jklys4ibqqei5fih@nitro.local> Message-ID: <202106291753.54331.bernhard@intevation.de> Am Dienstag 29 Juni 2021 14:44:39 schrieb Konstantin Ryabitsev via Gnupg-users: > With this change, they are replacing PGP with ed25519, but everything else > remains pretty much the same But OpenPGP so much more than one algorithm, you can even use ed25519 with OpenPGP today. (Again, probably because of the draft or work in progress status, maybe someone with write access to the wiki could clarify the headline.) Thanks for the infos, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From konstantin at linuxfoundation.org Tue Jun 29 19:00:00 2021 From: konstantin at linuxfoundation.org (Konstantin Ryabitsev) Date: Tue, 29 Jun 2021 13:00:00 -0400 Subject: Ditching OpenPGP, a new approach to signing APT repositories In-Reply-To: <202106291753.54331.bernhard@intevation.de> References: <202106290838.03087.bernhard@intevation.de> <20210629124439.jklys4ibqqei5fih@nitro.local> <202106291753.54331.bernhard@intevation.de> Message-ID: <20210629170000.5y62mtfnsb3yyjtp@nitro.local> On Tue, Jun 29, 2021 at 05:53:53PM +0200, Bernhard Reiter wrote: > Am Dienstag 29 Juni 2021 14:44:39 schrieb Konstantin Ryabitsev via > Gnupg-users: > > With this change, they are replacing PGP with ed25519, but everything else > > remains pretty much the same > > But OpenPGP so much more than one algorithm, > you can even use ed25519 with OpenPGP today. Yes, but speaking from personal experience, integrating libsodium into your automation is significantly easier than almost any other option. Let Debian folks do what makes most sense for their needs -- what they are doing is certainly not wrong or heading in the wrong direction. -K From wk at gnupg.org Tue Jun 29 19:08:06 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 29 Jun 2021 19:08:06 +0200 Subject: BSI - Why PQC for Thunderbird and not gpg4win in the first place? In-Reply-To: <392d515b87f6277a59adba7a9eb95c10@posteo.de> (=?utf-8?B?ItCh?= =?utf-8?B?0YLQtdGE0LDQvSDQktCw0YHQuNC70YzQtdCy?= via Gnupg-users"'s message of "Tue, 29 Jun 2021 15:31:43 +0000") References: <392d515b87f6277a59adba7a9eb95c10@posteo.de> Message-ID: <871r8kha4p.fsf@wheatstone.g10code.de> On Tue, 29 Jun 2021 15:31, ?????? ???????? said: > I don't understand why the BSI is looking for Post Quantum Cryptography > support with OpenPGP for Thunderbird and not for the promoted gpg4win, I can't tell you that. I do not have anymore information than you. From reading the tender it is clear that this project is for evaluating new algorithms in a real worl application. The goal is not to kickoff a new standard or feature. > As understood, Germany recently passed a law to strengthen authorities > to allow the usage of their Government trojan, which tells me that using It is quite a problem for the BSI that the gov is trying to shift them into the same trouble the NSA has. Protecting the citizen while at the same time helping to attack them. Will citizens still be able to trust them in a few years? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From stefan.vasilev at posteo.ru Tue Jun 29 20:01:03 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Tue, 29 Jun 2021 18:01:03 +0000 Subject: BSI - Why PQC for Thunderbird and not gpg4win in the first =?UTF-8?Q?place=3F?= In-Reply-To: <871r8kha4p.fsf@wheatstone.g10code.de> References: <392d515b87f6277a59adba7a9eb95c10@posteo.de> <871r8kha4p.fsf@wheatstone.g10code.de> Message-ID: <3e6e531a3bf32d3357405905e93138f9@posteo.de> Werner Koch wrote: > On Tue, 29 Jun 2021 15:31, ?????? ???????? said: > >> I don't understand why the BSI is looking for Post Quantum >> Cryptography >> support with OpenPGP for Thunderbird and not for the promoted gpg4win, > > I can't tell you that. I do not have anymore information than you. > From reading the tender it is clear that this project is for evaluating > new algorithms in a real worl application. The goal is not to kickoff > a > new standard or feature. Ah ok, understand. >> As understood, Germany recently passed a law to strengthen authorities >> to allow the usage of their Government trojan, which tells me that >> using > > It is quite a problem for the BSI that the gov is trying to shift them > into the same trouble the NSA has. Protecting the citizen while at the > same time helping to attack them. Will citizens still be able to trust > them in a few years? True and a good question! Regards Stefan From bernhard at intevation.de Wed Jun 30 09:05:45 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 30 Jun 2021 09:05:45 +0200 Subject: Debian using ed25519 APT repo meta data (Re: Ditching OpenPGP, a new approach to signing APT repositories) In-Reply-To: <20210629170000.5y62mtfnsb3yyjtp@nitro.local> References: <202106291753.54331.bernhard@intevation.de> <20210629170000.5y62mtfnsb3yyjtp@nitro.local> Message-ID: <202106300905.45525.bernhard@intevation.de> Am Dienstag 29 Juni 2021 19:00:00 schrieb Konstantin Ryabitsev via Gnupg-users: > Yes, but speaking from personal experience, integrating libsodium into your > automation is significantly easier than almost any other option. Let Debian > folks do what makes most sense for their needs -- what they are doing is > certainly not wrong or heading in the wrong direction. Sure, there are enough reasons to not use a standardized "packaging" protocol. It comes with risks of course, but if it is well understood, it is much simpler. The problem with the draft wiki page is that others use it to push their agenda of antagonising OpenPGP and Debian without understanding the technical matter. So having giving more context and a better fitting headline would clarify this. Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Jun 30 09:19:42 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 30 Jun 2021 09:19:42 +0200 Subject: BSI - Why PQC for Thunderbird and not gpg4win in the first place? In-Reply-To: <3e6e531a3bf32d3357405905e93138f9@posteo.de> References: <392d515b87f6277a59adba7a9eb95c10@posteo.de> <871r8kha4p.fsf@wheatstone.g10code.de> <3e6e531a3bf32d3357405905e93138f9@posteo.de> Message-ID: <202106300919.48478.bernhard@intevation.de> Am Dienstag 29 Juni 2021 20:01:03 schrieb ?????? ???????? via Gnupg-users: > Werner Koch wrote: > > On Tue, 29 Jun 2021 15:31, ?????? ???????? said: > >> I don't understand why the BSI is looking for Post Quantum > >> Cryptography support with OpenPGP for Thunderbird and not for the > >> promoted gpg4win, The tender includes implementing the algorithms in libgcrypt as well, so Gpg4win will also get it. When trying to understand how public administration and governments work, it is helpful to think of them as several groups and people. So it is not something that _the_ BSI wants or _the_ German Government. It is about sections, people, parties, ministries that all act within their view on their tasks, duties and also group and personal interests. This is okay, but it means one person, group or ministry may look at a technical aspect differently then others and act accordingly. > >> As understood, Germany recently passed a law to strengthen authorities > >> to allow the usage of their Government trojan, which tells me that > >> using > > > > It is quite a problem for the BSI that the gov is trying to shift them > > into the same trouble the NSA has. Protecting the citizen while at the > > same time helping to attack them. To be more specific, the conservatice party block (CDU/CSU) in Germany has been pushing many years for more suveillance, more rights for secret services and attack capabilities. And the resistance from other parties like SPD, FDP, attornies, journalists has been becoming weaker. (Note that the biggest block of German voters prefer this conservative block, so this is a problem of convincing more people and changing their vote about those topic). Similiar in Europe and the pandemic has shifted public attention away from the downsides. Rumors go that there is a good part that the German BSI may be split up in the future in what I'd call a "good" and "bad" part. This makes sense, as if "security" public administrations have legal rights and obligations, they need technical support and this is typical within the ministry of the interior. On the other hand the protecting part should be more independent maybe in the consumer and economy protection with the ministry of justice or the ministry economy. Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From stefan.vasilev at posteo.ru Wed Jun 30 17:07:25 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Wed, 30 Jun 2021 15:07:25 +0000 Subject: BSI - Why PQC for Thunderbird and not gpg4win in the first =?UTF-8?Q?place=3F?= In-Reply-To: <202106300919.48478.bernhard@intevation.de> References: <392d515b87f6277a59adba7a9eb95c10@posteo.de> <871r8kha4p.fsf@wheatstone.g10code.de> <3e6e531a3bf32d3357405905e93138f9@posteo.de> <202106300919.48478.bernhard@intevation.de> Message-ID: <6fd27efba19c03327e4af0cf20d0d432@posteo.de> Bernhard Reiter wrote: > To be more specific, the conservatice party block (CDU/CSU) in Germany > has > been pushing many years for more suveillance, more rights for secret > services > and attack capabilities. And the resistance from other parties like > SPD, FDP, > attornies, journalists has been becoming weaker. (Note that the biggest > block > of German voters prefer this conservative block, so this is a problem > of > convincing more people and changing their vote about those topic). > Similiar > in Europe and the pandemic has shifted public attention away from the > downsides. > > Rumors go that there is a good part that the German BSI may be split up > in the > future in what I'd call a "good" and "bad" part. This makes sense, as > if "security" public administrations have legal rights and obligations, > they > need technical support and this is typical within the ministry of the > interior. On the other hand the protecting part should be more > independent > maybe in the consumer and economy protection with the ministry of > justice or > the ministry economy. Why not let the BSI play the 'good' guys and ZITiS the 'bad' guys ... ?! Hopefully BSI will play white hat hackers and publish their findings on their website. https://www.zitis.bund.de/DE/Home/home_node.html P.S. Please dear GnuPG community do not see this thread as off-topic, because in the future people inside or outside Germany may think of how to securely and privately communicate globally with their communication partners. Regards Stefan