From tlikonen at iki.fi Tue Jan 1 08:30:20 2019 From: tlikonen at iki.fi (Teemu Likonen) Date: Tue, 01 Jan 2019 09:30:20 +0200 Subject: Key storage In-Reply-To: <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> (justina colmena via Gnupg-users's message of "Mon, 31 Dec 2018 12:06:39 -0900") References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> Message-ID: <87o9904yyb.fsf_-_@iki.fi> justina colmena via Gnupg-users [2018-12-31 12:06:39-09] wrote: > And now the *secret* keys are going in "~/.gnupg/pubring.gpg" with the > false implication by its name that the file contains only public keys > which need not be so carefully guarded against disclosure. Secret keys are in directory ~/.gnupg/private-keys-v1.d and each master key and subkey is in separate file named by key's keygrip (see "gpg -K --with-keygrip"). -- /// Teemu Likonen - .-.. // // PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 /// -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From guru at unixarea.de Tue Jan 1 08:36:58 2019 From: guru at unixarea.de (Matthias Apitz) Date: Tue, 1 Jan 2019 08:36:58 +0100 Subject: OpenPGP card: how to lock the card again so that PIN is required Message-ID: <20190101073658.GA8210@c720-r342378> Hello, This is with gnupg-2.2.12 and pcsc-lite-1.8.23. After an update of the System (FreeBSD CURRENT) the /usr/local/sbin/pcscd does no work anymore with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card Reader) after withdraw and re-insert. It works fine after boot, I have to enter the PIN to unlock the card and all tested functions are working. I have to investigate this further or change the 'scdaemon' to let it directly access the OpenPGP bypassing the 'pcscd' (comments on this are welcome). How can I meanwhile 'reset' the OpenPGP card so that on next request for the secrets (decrypt, signing, ssh) the PIN is requested? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From sac at 300baud.de Tue Jan 1 13:19:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 1 Jan 2019 13:19:34 +0100 Subject: A question about WKD In-Reply-To: References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> Message-ID: <20190101131934.43faeff8@300baud> On Sat, 29 Dec 2018 20:18:54 +0100, Wiktor Kwapisiewicz via Gnupg-users wrote: > On 29.12.2018 15:48, Stefan Claas wrote: > > Hi all, > > > > is it also possible to add manually more pub keys to WKD > > or do i have to install WKS for that purpose? > > > > I ask, because in case i like to add more users to my > > mail server. > > Just create more files in .well-known/openpgpkey/hu directory. Hi Wiktor and all, since my current WKD key is a temporary key i would like to know for best practice the following: In a couple of days i will receive my Kanguru Defender 3000 USB stick and then i will create a new key pair and put it on the stick, along with other things. This key will then also be signed by Governikus. Because WKD currently does not cover revocation certs i would like to know how to continue. Should i upload then my revoked temp key to SKS or should i simply replace the keys. If possible i would like to avoid SKS usage in the future. Does GnuPG detects when i use a new WKD pub key, once i signed a new message? Regards Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From sac at 300baud.de Tue Jan 1 13:27:56 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 1 Jan 2019 13:27:56 +0100 Subject: A question about WKD In-Reply-To: <20190101131934.43faeff8@300baud> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> <20190101131934.43faeff8@300baud> Message-ID: <20190101132756.7bdb3d4d@300baud> On Tue, 1 Jan 2019 13:19:34 +0100, Stefan Claas wrote: > Hi Wiktor and all, I wish everybody a Happy New Year 2019! Best regards Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From dirk.gottschalk1980 at googlemail.com Tue Jan 1 18:40:56 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 01 Jan 2019 18:40:56 +0100 Subject: OpenPGP card: how to lock the card again so that PIN is required In-Reply-To: <20190101073658.GA8210@c720-r342378> References: <20190101073658.GA8210@c720-r342378> Message-ID: <92d825c232d42059c9e22b2073adaa89a2352716.camel@googlemail.com> Hello Matthias. Am Dienstag, den 01.01.2019, 08:36 +0100 schrieb Matthias Apitz: > Hello, > This is with gnupg-2.2.12 and pcsc-lite-1.8.23. After an update of > the System (FreeBSD CURRENT) the /usr/local/sbin/pcscd does no work > anymore with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card > Reader) after withdraw and re-insert. It works fine after boot, I > have to enter the PIN to unlock the card and all tested functions are > working. Did you check the config for pcscd? Probably it was overwrittenby the update process. > I have to investigate this further or change the 'scdaemon' to let it > directly access the OpenPGP bypassing the 'pcscd' (comments on this > are welcome). You can use the internal ccid-reader of scdaemon. This should work with the OmniKey readers, AFAIK. You have to disable PC/SC, oherwise this won't work. > How can I meanwhile 'reset' the OpenPGP card so that on next request > for the secrets (decrypt, signing, ssh) the PIN is requested? For the signature PIN just enable the forcepin option as admin with --card-edit. The for the other functions you need to power cycle the card, easiest done by removal and re-insertion. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dirk.gottschalk1980 at googlemail.com Tue Jan 1 18:48:42 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Tue, 01 Jan 2019 18:48:42 +0100 Subject: A question about WKD In-Reply-To: <20190101131934.43faeff8@300baud> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> <20190101131934.43faeff8@300baud> Message-ID: <995b2bb3440a8cec0ffe12aeb3f9cd0a3922607c.camel@googlemail.com> Hello Stefan. Am Dienstag, den 01.01.2019, 13:19 +0100 schrieb Stefan Claas: > On Sat, 29 Dec 2018 20:18:54 +0100, Wiktor Kwapisiewicz via Gnupg- > users wrote: > > On 29.12.2018 15:48, Stefan Claas wrote: > > > Hi all, > > Just create more files in .well-known/openpgpkey/hu directory. > since my current WKD key is a temporary key i would like to know > for best practice the following: > In a couple of days i will receive my Kanguru Defender 3000 USB stick > and then i will create a new key pair and put it on the stick, along > with other things. This key will then also be signed by Governikus. > Because WKD currently does not cover revocation certs i would like > to know how to continue. Should i upload then my revoked temp > key to SKS or should i simply replace the keys. If possible i would > like to avoid SKS usage in the future. > Does GnuPG detects when i use a new WKD pub key, once i signed > a new message? I would at least publicate the revocation via the SKS servers. GPG searches all keys on the SKS-Servers, regardless of their origin. So during a refresh the revocation is added to the keyring, AFAIK. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From 2017-r3sgs86x8e-lists-groups at riseup.net Wed Jan 2 02:13:43 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Wed, 2 Jan 2019 01:13:43 +0000 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> Message-ID: <253629684.20190102011343@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Monday 31 December 2018 at 9:06:39 PM, in , justina colmena via Gnupg-users wrote:- > Shouldn't an email message (for example) be encrypted > separately to > each BCC recipient, My opinion is that should be the case. However, most MUAs I've used include the BCC recipients' keys in the encryption along with the To and CC recipients' keys, so any email addresses in the user-IDs of these keys are visible to all recipients. As an exception, one MAU I used with an OpenPGP add-on would instead send an individual copy of the message to each BCC recipient, encrypted only to their key. > or is this an intended all-in-one > multiple-recipient encryption which cannot conceal > from the > cryptanalyst the fact that the same message, > encrypted only once, is > being sent to more than one receiving party? With hidden-recipient or hidden-encrypt-to or throw-keyids, it is clear how many keys were encrypted to, but the key IDs and user-IDs are not present. - -- Best regards MFPA Never trust a dog with orange eyebrows -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXCwQUV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +l+qAP4u2Ik4+zBMKk5dQuE/6ZgvBFnBjeqKt79FEQufn92LiAEArbSWuqUsRdiK zD88bQo1AwfqVzSLZ315pCVR+Rg/MASJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXCwQUV8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/6f/D/0eScxxhozcB1TPwVDESl1ZdG4y Ai6e8dmZyh9jVpEmTbiolXTw4IjWkuq26KMGyIdZEn2vSZtHwGm6AkMIWncR8D0A P4rQWw+6Z9evsRLKkW3+J1TyQNQfA6YZ+gxTK6BLoyVqbp520CTNyfibq9PNN+mg HqlxboA61ti2oMzQ0YhIq6H+RKbo7AhfpgQsN/NmVLa1tqbja1gQxbdmXV1axdmQ EHn0VUKTaCYSiC9ulDAnoBVgg6h4zbxxawwa6NJQ03T5YBRzu3aLmlcpHaOj7DKZ 9LM3JTY+HlPWoAwLQhuLVKmDrt60GFobn3SDhgDlrwu1WVT+98jlCr3J+5BJlyOs bAA8vCYpS6gEGtHa00JAd3qnnBfdGvxzs1wa88eHRqHkG6HWUj1qfxE5OCpGqcpy Av4rfyANiRYAGnPb3+48kMCvLEGLyHTWyewrRc4tGbyxIIjjhH/N41Uz8FbjNCuT /baoXoOzHoyzH+O78N8mn+IPyaN5sEwezUFeBZARYS6El9LU5+UsxGM4bW8wKwe+ f4GcKMGFFffQ0BEO5rIZPMwnP0X1HEVLnyOCmS+idUUCdBZ12OyEjApD1EH0B24Y qTwxNAbT6538DhAYFzHi8EJHxUOsQBLMtYKuzTpqZnpBxK6rYDXqdhc17zXylu5U a+4py/6A/kfU7UlBEA== =tUMh -----END PGP SIGNATURE----- From guru at unixarea.de Wed Jan 2 07:02:09 2019 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 2 Jan 2019 07:02:09 +0100 Subject: OpenPGP card: how to lock the card again so that PIN is required In-Reply-To: <92d825c232d42059c9e22b2073adaa89a2352716.camel@googlemail.com> References: <20190101073658.GA8210@c720-r342378> <92d825c232d42059c9e22b2073adaa89a2352716.camel@googlemail.com> Message-ID: <20190102060209.GA3158@c720-r342378> El d?a martes, enero 01, 2019 a las 06:40:56p. m. +0100, Dirk Gottschalk escribi?: > Hello Matthias. > > Am Dienstag, den 01.01.2019, 08:36 +0100 schrieb Matthias Apitz: > > Hello, > > > This is with gnupg-2.2.12 and pcsc-lite-1.8.23. After an update of > > the System (FreeBSD CURRENT) the /usr/local/sbin/pcscd does no work > > anymore with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card > > Reader) after withdraw and re-insert. It works fine after boot, I > > have to enter the PIN to unlock the card and all tested functions are > > working. > > Did you check the config for pcscd? Probably it was overwrittenby the > update process. There is no config file for pcscd, only for serial devices. Interestingly the pcscd started via devd at boot time works fine: $ ps ax | grep pc 536 v0- S 0:00,98 /usr/local/sbin/pcscd --debug --foreground When I disable this start at boot time and start the same command as root from the shell (to investigate/debug), this just hangs. Also system USB commands, like 'ucbconfig list', show the same problem. It looks like something in the boot process after start of the above PID damages the USB stack. > > I have to investigate this further or change the 'scdaemon' to let it > > directly access the OpenPGP bypassing the 'pcscd' (comments on this > > are welcome). > > You can use the internal ccid-reader of scdaemon. This should work with > the OmniKey readers, AFAIK. You have to disable PC/SC, oherwise this > won't work. I did so, it shows (as started after boot) the same problem. > > How can I meanwhile 'reset' the OpenPGP card so that on next request > > for the secrets (decrypt, signing, ssh) the PIN is requested? > > For the signature PIN just enable the forcepin option as admin with > --card-edit. The for the other functions you need to power cycle the > card, easiest done by removal and re-insertion. Yes, this was what I did before the update :-) Thanks for your replay anyway. mattihas -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gnupg at raf.org Wed Jan 2 06:02:03 2019 From: gnupg at raf.org (gnupg at raf.org) Date: Wed, 2 Jan 2019 16:02:03 +1100 Subject: NIST 800-57 compatible unattended encryption? Message-ID: <20190102050203.7psom2s5hqvphxgp@raf.org> Hi, Apologies in advance for my profound ignorance on matters cryptological. I use an RSA 2048 keypair for encrypting and decrypting files, not to send to anyone, just for backups. I'd like to manage my keys according to the recommendations of NIST SP 800-57. Luckily, I don't actually have to fully comply with it but I'd like to get as close as I can (without spending lots of money). Unfortunately, it seems that NIST SP 800-57 only likes symmetric algorithms for data encryption and it only likes asymmetric algorithms for signing and key-agreement. I think they're expecting quantum computing armageddon making asymmetric algorithms useless. For some dumb reason I think I was hoping that the RSA algorithm wasn't really used to encrypt all the data. I thought it was probably used to encrypt a per-file randomly-generated symmetric key which was then used to encrypt the file (and was encrypted along with the file) because it could be faster. But I think I'm confusing it with network protocols like TLS. Is that what happens with RSA in gpg? [Probably not] If so, how can I tell which symmetric algorithm is used to actually encrypt the data or choose that algorithm? If not, is there a way to make that kind of behaviour happen with gpg? Apparently, NIST SP 800-56B describes an approved method of using RSA for key-agreement but it looks hideous (to the untrained brain) and I'm sure that it's of no use to me. And key-agreement shouldn't be necessary, just a cryptographically random per-file key would probably do as long as the file itself were encrypted using a symmetric algorithm. Mind you, NIST 800-57 only likes symmetric keys for encrypting other keys as well so that probably wouldn't be approved either. Symmetric encryption isn't really an option for automated backups as cron can't be expected to enter a passphrase. The passphrase should only be required to decrypt the files. Thanks in advance for any answers or advice, even if the advice is to give up. :-) I'm not going to stop doing automatic backups just to satisfy NIST's recommendations. cheers, raf From dgouttegattat at incenp.org Wed Jan 2 10:47:47 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 2 Jan 2019 09:47:47 +0000 Subject: NIST 800-57 compatible unattended encryption? In-Reply-To: <20190102050203.7psom2s5hqvphxgp@raf.org> References: <20190102050203.7psom2s5hqvphxgp@raf.org> Message-ID: <20190102094747.e5lhhj4rndllufos@aurora.local.incenp.org> Hi, On Wed, Jan 02, 2019 at 04:02:03PM +1100, gnupg at raf.org wrote: > For some dumb reason I think I was hoping that the RSA > algorithm wasn't really used to encrypt all the data. I > thought it was probably used to encrypt a per-file > randomly-generated symmetric key which was then used to > encrypt the file (and was encrypted along with the > file) because it could be faster. But I think I'm > confusing it with network protocols like TLS. > > Is that what happens with RSA in gpg? [Probably not] Actually yes, that?s exactly what happens. The data (in your case, the contents of your file) is symmetrically encrypted using a randomly generated ?session key?, and *that* key is asymmetrically encrypted using the RSA public key. Cheers, - Damien -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wiktor at metacode.biz Wed Jan 2 10:55:08 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 2 Jan 2019 10:55:08 +0100 Subject: NIST 800-57 compatible unattended encryption? In-Reply-To: <20190102094747.e5lhhj4rndllufos@aurora.local.incenp.org> References: <20190102050203.7psom2s5hqvphxgp@raf.org> <20190102094747.e5lhhj4rndllufos@aurora.local.incenp.org> Message-ID: <5504353a-3347-502c-590f-31daf9bd0d7f@metacode.biz> Hello, > On Wed, Jan 02, 2019 at 04:02:03PM +1100, gnupg at raf.org wrote: >> For some dumb reason I think I was hoping that the RSA >> algorithm wasn't really used to encrypt all the data. I >> thought it was probably used to encrypt a per-file >> randomly-generated symmetric key which was then used to >> encrypt the file (and was encrypted along with the >> file) because it could be faster. But I think I'm >> confusing it with network protocols like TLS. >> >> Is that what happens with RSA in gpg? [Probably not] > > Actually yes, that?s exactly what happens. The data (in your > case, the contents of your file) is symmetrically encrypted using > a randomly generated ?session key?, and *that* key is > asymmetrically encrypted using the RSA public key. Yep, to see this behind-the-scenes thing in action check out "--show-session-key" and "--override-session-key" options. Described here: https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html Kind regards, Wiktor -- https://metacode.biz/@wiktor From wiktor at metacode.biz Wed Jan 2 11:18:25 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Wed, 2 Jan 2019 11:18:25 +0100 Subject: A question about WKD In-Reply-To: <20190101131934.43faeff8@300baud> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> <20190101131934.43faeff8@300baud> Message-ID: <340a9134-37ff-2f59-f481-4608fb8d5c9c@metacode.biz> On 01.01.2019 13:19, Stefan Claas wrote: > Hi Wiktor and all, > > since my current WKD key is a temporary key i would like to know > for best practice the following: > > In a couple of days i will receive my Kanguru Defender 3000 USB stick > and then i will create a new key pair and put it on the stick, along > with other things. This key will then also be signed by Governikus. > > Because WKD currently does not cover revocation certs i would like > to know how to continue. Should i upload then my revoked temp > key to SKS or should i simply replace the keys. If possible i would > like to avoid SKS usage in the future. > > Does GnuPG detects when i use a new WKD pub key, once i signed > a new message? Stefan, Revoke your current key locally and generate a new one, now export both binary keys (that includes revocation) to a file. Place it in .well-known/openpgpkey/hu overwriting the old file. Now, when GnuPG does --locate-key it will fetch both keys, revoke your old one and add the new one. If someone already has your old key GnuPG will do the fetch automatically when the old key expires (you didn't use expiry as far as I can see so it won't happen automatically). One can still "force" the WKD refresh using: $ gpg --auto-key-locate clear,wkd,nodefault --locate-key sac at 300baud.de I just tested this all with some dummy key on my end and it worked just fine... hope it works on your end too. As for signing, if you specify signing key using "e-mail notation" GnuPG will embed Signer's UID packet and when the recipient uses --auto-key-retrieve it will grab your key using WKD instead of keyservers. But I didn't test what would happen if the old key is already present in the keyring that doesn't match the signature, probably nothing. (You can inspect this file with pgpdump if you want to see the packet: $ curl https://metacode.biz/.well-known/security.txt | pgpdump ) Happy New Year! Kind regards, Wiktor -- https://metacode.biz/@wiktor From wk at gnupg.org Wed Jan 2 11:36:54 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 02 Jan 2019 11:36:54 +0100 Subject: OpenPGP card: how to lock the card again so that PIN is required In-Reply-To: <20190101073658.GA8210@c720-r342378> (Matthias Apitz's message of "Tue, 1 Jan 2019 08:36:58 +0100") References: <20190101073658.GA8210@c720-r342378> Message-ID: <87ef9ve46x.fsf@wheatstone.g10code.de> On Tue, 1 Jan 2019 08:36, guru at unixarea.de said: > with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card Reader) after Take care: Usual Omnikey problems with creating and using large keys apply. > How can I meanwhile 'reset' the OpenPGP card so that on next request for > the secrets (decrypt, signing, ssh) the PIN is requested? gpgconf --reload scdaemon is the easiest way. You can also use --kill as it is the same for scdaemon. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. gpg-connect-agegpg-connect-agen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From alex at nitrokey.com Wed Jan 2 11:32:11 2019 From: alex at nitrokey.com (Alexander Paetzelt | Nitrokey) Date: Wed, 2 Jan 2019 11:32:11 +0100 Subject: OpenPGP card: how to lock the card again so that PIN is required In-Reply-To: <20190101073658.GA8210@c720-r342378> References: <20190101073658.GA8210@c720-r342378> Message-ID: <63549487-2c52-e5e6-cd4b-3c9e8fbb7528@nitrokey.com> Hi, On 01.01.19 08:36, Matthias Apitz wrote: > How can I meanwhile 'reset' the OpenPGP card so that on next request for > the secrets (decrypt, signing, ssh) the PIN is requested? for key slots 1 and 2 there probably is no way to do this other than unplugging und replugging the device. See also the discussion here [1]. Kind regards Alex From sac at 300baud.de Wed Jan 2 14:50:14 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 2 Jan 2019 14:50:14 +0100 Subject: A question about WKD In-Reply-To: <340a9134-37ff-2f59-f481-4608fb8d5c9c@metacode.biz> References: <43PnxT3yYDz9rxR@submission02.posteo.de> <8d8aed68-441e-dc48-e61f-ebf3a3a37fba@metacode.biz> <43QlHW2JQRz9rxH@submission02.posteo.de> <20190101131934.43faeff8@300baud> <340a9134-37ff-2f59-f481-4608fb8d5c9c@metacode.biz> Message-ID: <20190102145014.4ad9744d@300baud> On Wed, 2 Jan 2019 11:18:25 +0100, Wiktor Kwapisiewicz wrote: Hi Wiktor, > Revoke your current key locally and generate a new one, now export both binary > keys (that includes revocation) to a file. Place it in .well-known/openpgpkey/hu > overwriting the old file. > > Now, when GnuPG does --locate-key it will fetch both keys, revoke your old one > and add the new one. Thank you very much, i did not know that it can be done this way. > If someone already has your old key GnuPG will do the fetch automatically when > the old key expires (you didn't use expiry as far as I can see so it won't > happen automatically). > > One can still "force" the WKD refresh using: > > $ gpg --auto-key-locate clear,wkd,nodefault --locate-key sac at 300baud.de > > I just tested this all with some dummy key on my end and it worked just fine... > hope it works on your end too. I hope so too and i will see once i have the new key. > As for signing, if you specify signing key using "e-mail notation" GnuPG will > embed Signer's UID packet and when the recipient uses --auto-key-retrieve it > will grab your key using WKD instead of keyservers. But I didn't test what would > happen if the old key is already present in the keyring that doesn't match the > signature, probably nothing. That's interesting and i must admit i did not know this either, so thanks again! > (You can inspect this file with pgpdump if you want to see the packet: > $ curl https://metacode.biz/.well-known/security.txt | pgpdump > ) O.k. > Happy New Year! Happy New Year! Best regards Stefan From guru at unixarea.de Wed Jan 2 11:58:50 2019 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 2 Jan 2019 11:58:50 +0100 Subject: OpenPGP card: how to lock the card again so that PIN is required In-Reply-To: <87ef9ve46x.fsf@wheatstone.g10code.de> References: <20190101073658.GA8210@c720-r342378> <87ef9ve46x.fsf@wheatstone.g10code.de> Message-ID: <20190102105850.GA2768@c720-r342378> El d?a mi?rcoles, enero 02, 2019 a las 11:36:54a. m. +0100, Werner Koch escribi?: > On Tue, 1 Jan 2019 08:36, guru at unixarea.de said: > > > with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card Reader) after > > Take care: Usual Omnikey problems with creating and using large keys > apply. Thanks. But I'm using this card and reader for a long time. And the same problem is with the uTrust reader. > > How can I meanwhile 'reset' the OpenPGP card so that on next request for > > the secrets (decrypt, signing, ssh) the PIN is requested? > > gpgconf --reload scdaemon > > is the easiest way. You can also use --kill as it is the same for > scdaemon. THANKS!!! This works and I now at least can disable the card when I go a way from the laptop. BTW: The CCID and the readers have no manuals how, i.e. in which directions, one has to insert the CCID. Yesterday I took pictures to have this clear now :-) matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. -------------- next part -------------- A non-text attachment was scrubbed... Name: uTrust-3512-card.jpg Type: image/jpeg Size: 49595 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: HID-Global-OMNIKEY-6121-card.jpg Type: image/jpeg Size: 52485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From justina at colmena.biz Wed Jan 2 21:56:27 2019 From: justina at colmena.biz (justina colmena) Date: Wed, 02 Jan 2019 11:56:27 -0900 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <253629684.20190102011343@my_localhost_LG> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> <253629684.20190102011343@my_localhost_LG> Message-ID: <170C6A3F-F5D8-4A5A-A56B-57E7B52EBDA5@colmena.biz> On January 1, 2019 4:13:43 PM AKST, MFPA <2017-r3sgs86x8e-lists-groups at riseup.net> wrote: >Hi > > >On Monday 31 December 2018 at 9:06:39 PM, in >, justina >colmena via Gnupg-users wrote:- > > >> Shouldn't an email message (for example) be encrypted >> separately to >> each BCC recipient, > >My opinion is that should be the case. However, most MUAs I've used >include the BCC recipients' keys in the encryption along with the To >and CC recipients' keys, so any email addresses in the user-IDs of >these keys are visible to all recipients. > >As an exception, one MAU I used with an OpenPGP add-on would instead >send an individual copy of the message to each BCC recipient, >encrypted only to their key. This seems like better practice. Also I would want to encrypt the transmitted email message only to the intended recipient, and the copy stored in my "Sent" folder only to myself. >> or is this an intended all-in-one >> multiple-recipient encryption which cannot conceal >> from the >> cryptanalyst the fact that the same message, >> encrypted only once, is >> being sent to more than one receiving party? > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is >clear how many keys were encrypted to, but the key IDs and user-IDs >are not present. I am not terribly comfortable with this situation. It almost seems rather creepy to me to receive an encrypted message that is also encrypted for the benefit or verification of one or more unknown and unidentified third parties. I start suspecting things like a foreign government mandated key escrow or secret government backdoor on behalf of some foreign spy or law enforcement agency. > >-- >Best regards > >MFPA > >Never trust a dog with orange eyebrows -- A well regulated Militia, being necessary to the security of a free State, the right of the people to keep and bear Arms, shall not be infringed. https://www.colmena.biz/~justina/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From sac at 300baud.de Wed Jan 2 22:28:51 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 2 Jan 2019 22:28:51 +0100 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <170C6A3F-F5D8-4A5A-A56B-57E7B52EBDA5@colmena.biz> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> <253629684.20190102011343@my_localhost_LG> <170C6A3F-F5D8-4A5A-A56B-57E7B52EBDA5@colmena.biz> Message-ID: <20190102222851.6311118d@300baud> On Wed, 02 Jan 2019 11:56:27 -0900, justina colmena via Gnupg-users wrote: > On January 1, 2019 4:13:43 PM AKST, MFPA <2017-r3sgs86x8e-lists-groups at riseup.net> wrote: > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is > >clear how many keys were encrypted to, but the key IDs and user-IDs > >are not present. > I am not terribly comfortable with this situation. It almost seems rather creepy to me to receive an encrypted > message that is also encrypted for the benefit or verification of one or more unknown and unidentified third parties. > I start suspecting things like a foreign government mandated key escrow or secret government backdoor on behalf of > some foreign spy or law enforcement agency. When you receive a message which is also encrypted to hidden recipients you will see that in GnuPG, when decrypting the message. It shows additional info of how many keys the message was encrypted to, with key ids showing in the form of ID 0000000000000000. So nothing to worry! This very good feature was probably implemented many moons ago for users of Mixmaster. Regards Stefan From vedaal at nym.hush.com Thu Jan 3 01:02:39 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Wed, 02 Jan 2019 19:02:39 -0500 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <170C6A3F-F5D8-4A5A-A56B-57E7B52EBDA5@colmena.biz> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> <253629684.20190102011343@my_localhost_LG> <170C6A3F-F5D8-4A5A-A56B-57E7B52EBDA5@colmena.biz> Message-ID: <20190103000240.08304C0157@smtp.hushmail.com> On 1/2/2019 at 3:59 PM, "justina colmena via Gnupg-users" wrote: >My opinion is that should be the case. However, most MUAs I've used >include the BCC recipients' keys in the encryption along with the To >and CC recipients' keys, so any email addresses in the user-IDs of >these keys are visible to all recipients. >As an exception, one MAU I used with an OpenPGP add-on would instead >send an individual copy of the message to each BCC recipient, >encrypted only to their key. >This seems like better practice. Also I would want to encrypt the transmitted email message only to the intended recipient, >and the copy stored in my "Sent" folder only to myself. >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is >clear how many keys were encrypted to, but the key IDs and user-IDs >are not present. I am not terribly comfortable with this situation. It almost seems rather creepy to me to receive an encrypted message that is also encrypted for the benefit or verification of one or more unknown and unidentified third parties. I start suspecting things like a foreign government mandated key escrow or secret government backdoor on behalf of some foreign spy or law enforcement agency. ===== you have 3 tedious options, 1 more tedious than the other 8^) : [1] use default-recipient-self, and explain in an n.b. in your plaintext that you want to have a record of what you sent, but don't want to leave it in plaintext, and you will have an encrypted copy in your sent box openable by you (this is very common). [2] encrypt only to the sender, but also encrypt the plaintext only to you, and store the encrypted file in your sent or other convenient folder, with the date and the recipient. [3] only for the overly paranoid who revel in tedious work-arounds 8^) : (a) Encrypt to both yourself and the recipient (b) Remove your own id packet from the ciphertext, (c) Re-calculate the crc of the ciphertext (d) Send the 'hacked' ciphertext along to the original recipient (e) Store the first ciphertext from (a) along with the one from (d), in your sent folder (f) now you will always be able to decrypt and retrieve the original plaintext btw, I don't recommend this, but it is *possible* to add a (not yet done, but not terribly complicated either) patch to gnupg to 'display' the session key in the terminal window, (while you are encrypting only to one recipient), and then you can encrypt that session key to your key, and store it, or a (also not yet done, but not terribly complicated either) patch, to allow gnupg to use a session key supplied by the user as an entry in the command line(i.e. --use-session-key (64 character string from step (a) above) That session key is as random as any done by gnupg, and isn't really being 're-used', it's just being stored in the encrypted file from step (a) and is being sent with the same message encrypted to the same recipient as in step (a) This is just to point out, that if someone wants to think paranoidly about 'who else knows' what is encrypted in your encrypted e-mail that was encrypted only to you, it 'can' be done, (extremely tedious, and afaik , has not been implemented by any open-pgp variant program out there 8^) ) vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From hreba at t-online.de Thu Jan 3 15:25:04 2019 From: hreba at t-online.de (Frank Hrebabetzky) Date: Thu, 3 Jan 2019 15:25:04 +0100 Subject: decryption failed: Bad session key Message-ID: <4416819b-8de9-a413-2c65-6a221bf47193@t-online.de> Hi all, I have 2 encrypted files on my PC, let's call them A and B. Every now and then, they are decrypted, edited and encrypted again with the -c option. This has been working very well for decades, surviving several changes of PCs and Linux flavours. The problem arose after my update from Linux Mint 17 (Ubuntu 14) to Linux Mint 19 (Ubuntu 18) Since then, A wasn't re-encrypted, and I can decrypt it as before. B however was re-encrypted, and now I cannot decrypt it anymore. Each attempt is responded with gpg: AES256 encrypted data gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key Regards, -- Frank Hrebabetzky +49 / 9261 / 950 0565 From 2017-r3sgs86x8e-lists-groups at riseup.net Fri Jan 4 04:09:53 2019 From: 2017-r3sgs86x8e-lists-groups at riseup.net (MFPA) Date: Fri, 4 Jan 2019 03:09:53 +0000 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <20190103000240.08304C0157@smtp.hushmail.com> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> <253629684.20190102011343@my_localhost_LG> <170C6A3F-F5D8-4A5A-A56B-57E7B52EBDA5@colmena.biz> <20190103000240.08304C0157@smtp.hushmail.com> Message-ID: <1317686202.20190104030953@my_localhost_LG> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi On Thursday 3 January 2019 at 12:02:39 AM, in , vedaal via Gnupg-users wrote:- > [2] encrypt only to the sender, but also encrypt the > plaintext only > to you, and store the encrypted file in your sent or > other > convenient folder, with the date and the recipient. I guess if you had an MUA that encrypted separately to BCC recipients, you could achieve this by BCC-ing yourself. > [3] only for the overly paranoid who revel in tedious > work-arounds 8^) : > (a) Encrypt to both yourself and the recipient > (b) Remove your own id packet from the ciphertext, > (c) Re-calculate the crc of the ciphertext > (d) Send the 'hacked' ciphertext along to the > original recipient > (e) Store the first ciphertext from (a) along with > the one from (d), in your sent folder > (f) now you will always be able to decrypt and > retrieve the original plaintext Would the ciphertext at (d) be much different than encrypting to the recipient and hidden-encrypt-to your own key? - -- Best regards MFPA He's an environmentalist - his arguments are 100% recycled -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXC7OkV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju +oXLAP9VS4KkIcC46uXVbRrxMMnMb3uU3DnyWlQAN3BnerHiXQD+Mew6XBCf1Vsy arODK2wCXESbLQGsX+zXveX+bNpzegyJApMEAQEKAH0WIQRSX6konxd5jbM7JygT DfUWES/A/wUCXC7Okl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/139EACpg6S+lm2f56sqJzF4pWkosYFm XzkgfMSIFgL241vmewDNAb54RsDtQ7sxZvy9jhIYVA0BFsRhmYmWNHjUWqEvb+iO Q59yngpjJJkueCfVW6WiC1iCIURVZQ+wrSaQqks1/UyIk8JfwNPMntcjHbMPJt+M hXxsxpBzy3wgbFfIxjNEx9XdcMOkt6wZHt1SmJQIhP2nw8QydqQAphcKEyBp7T/k vRKOxExv6PgCWs93dCVWHhO/ek2BDBm5oDMZ0aFz/ZehhtRQapdQYZ5upWXBFcQc DZgr/G+gDFtEmHjVyYugnBMT9sITau9WYZ+NedhIndwFNHmbd5EfI+i7KNd67kN0 zn0YT21Lh37IMBeki87XcDMiTvNfmejs3ogUgiNwbsr8SGcHpwojKStWJdzlw381 leN5VpLC921BojCgna+2k+xrx+z1+s6b5SZx3FV4118KuXoixRtfWTB52CB9KnzX MRzfTy4IpjKjdpjqoLrQg7H+VlwVgHzU4p52OA0fWJHxDaYDZpl0mWA2ffL1qn4w G2cMJKvOQacu2Me241z/tQ7FvLpZ6oKmeaFNM8wzN0vK2bYlh1PTrEE5hEDbWgIm /J8Qmlg94QqPy7S/lB6BqaWb1lqe48AkdfjFiFwQYcw+3ibsnmhDmQyPe0OkWgqC 1fjyulUQXjXBkJ19bg== =yhZM -----END PGP SIGNATURE----- From stevenschmidt909 at gmail.com Fri Jan 4 19:22:58 2019 From: stevenschmidt909 at gmail.com (steven schmidt) Date: Fri, 4 Jan 2019 13:22:58 -0500 Subject: unsubscibe In-Reply-To: References: Message-ID: On Thu, Jan 3, 2019 at 10:10 PM wrote: > 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: gpg - difference --encrypt-to and --recipient > (justina colmena) > 2. Re: gpg - difference --encrypt-to and --recipient (Stefan Claas) > 3. Re: gpg - difference --encrypt-to and --recipient > (vedaal at nym.hush.com) > 4. decryption failed: Bad session key (Frank Hrebabetzky) > 5. Re: gpg - difference --encrypt-to and --recipient (MFPA) > > > > ---------- Forwarded message ---------- > From: justina colmena > To: MFPA <2017-r3sgs86x8e-lists-groups at riseup.net>, justina colmena via > Gnupg-users on GnuPG-Users > Cc: justina colmena via Gnupg-users > Bcc: > Date: Wed, 02 Jan 2019 11:56:27 -0900 > Subject: Re: gpg - difference --encrypt-to and --recipient > On January 1, 2019 4:13:43 PM AKST, MFPA < > 2017-r3sgs86x8e-lists-groups at riseup.net> wrote: > >Hi > > > > > >On Monday 31 December 2018 at 9:06:39 PM, in > >, justina > >colmena via Gnupg-users wrote:- > > > > > >> Shouldn't an email message (for example) be encrypted > >> separately to > >> each BCC recipient, > > > >My opinion is that should be the case. However, most MUAs I've used > >include the BCC recipients' keys in the encryption along with the To > >and CC recipients' keys, so any email addresses in the user-IDs of > >these keys are visible to all recipients. > > > >As an exception, one MAU I used with an OpenPGP add-on would instead > >send an individual copy of the message to each BCC recipient, > >encrypted only to their key. > > This seems like better practice. Also I would want to encrypt the > transmitted email message only to the intended recipient, and the copy > stored in my "Sent" folder only to myself. > > >> or is this an intended all-in-one > >> multiple-recipient encryption which cannot conceal > >> from the > >> cryptanalyst the fact that the same message, > >> encrypted only once, is > >> being sent to more than one receiving party? > > > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is > >clear how many keys were encrypted to, but the key IDs and user-IDs > >are not present. > I am not terribly comfortable with this situation. It almost seems rather > creepy to me to receive an encrypted message that is also encrypted for the > benefit or verification of one or more unknown and unidentified third > parties. I start suspecting things like a foreign government mandated key > escrow or secret government backdoor on behalf of some foreign spy or law > enforcement agency. > > > >-- > >Best regards > > > >MFPA > > > >Never trust a dog with orange eyebrows > > > -- > A well regulated Militia, being necessary to the security of a free State, > the right of the people to keep and bear Arms, shall not be infringed. > > https://www.colmena.biz/~justina/ > > > ---------- Forwarded message ---------- > From: Stefan Claas > To: gnupg-users at gnupg.org > Cc: > Bcc: > Date: Wed, 2 Jan 2019 22:28:51 +0100 > Subject: Re: gpg - difference --encrypt-to and --recipient > On Wed, 02 Jan 2019 11:56:27 -0900, justina colmena via Gnupg-users wrote: > > On January 1, 2019 4:13:43 PM AKST, MFPA < > 2017-r3sgs86x8e-lists-groups at riseup.net> wrote: > > > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is > > >clear how many keys were encrypted to, but the key IDs and user-IDs > > >are not present. > > I am not terribly comfortable with this situation. It almost seems > rather creepy to me to receive an encrypted > > message that is also encrypted for the benefit or verification of one or > more unknown and unidentified third parties. > > I start suspecting things like a foreign government mandated key escrow > or secret government backdoor on behalf of > > some foreign spy or law enforcement agency. > > When you receive a message which is also encrypted to hidden recipients > you will see that > in GnuPG, when decrypting the message. It shows additional info of how > many keys the > message was encrypted to, with key ids showing in the form of ID > 0000000000000000. > > So nothing to worry! This very good feature was probably implemented many > moons ago > for users of Mixmaster. > > Regards > Stefan > > > > > > ---------- Forwarded message ---------- > From: vedaal at nym.hush.com > To: justina colmena , gnupg-users at gnupg.org > Cc: > Bcc: > Date: Wed, 02 Jan 2019 19:02:39 -0500 > Subject: Re: gpg - difference --encrypt-to and --recipient > > > On 1/2/2019 at 3:59 PM, "justina colmena via Gnupg-users" < > gnupg-users at gnupg.org> wrote: > > > >My opinion is that should be the case. However, most MUAs I've used > >include the BCC recipients' keys in the encryption along with the To > >and CC recipients' keys, so any email addresses in the user-IDs of > >these keys are visible to all recipients. > > >As an exception, one MAU I used with an OpenPGP add-on would instead > >send an individual copy of the message to each BCC recipient, > >encrypted only to their key. > > >This seems like better practice. Also I would want to encrypt the > transmitted email message only to the intended recipient, >and the copy > stored in my "Sent" folder only to myself. > > > >With hidden-recipient or hidden-encrypt-to or throw-keyids, it is > >clear how many keys were encrypted to, but the key IDs and user-IDs > >are not present. > I am not terribly comfortable with this situation. It almost seems rather > creepy to me to receive an encrypted message that is also encrypted for the > benefit or verification of one or more unknown and unidentified third > parties. I start suspecting things like a foreign government mandated key > escrow or secret government backdoor on behalf of some foreign spy or law > enforcement agency. > > ===== > you have 3 tedious options, 1 more tedious than the other 8^) : > > [1] use default-recipient-self, and explain in an n.b. in your plaintext > that you want to have a record of what you sent, but don't want to leave it > in plaintext, and you will have an encrypted copy in your sent box > openable by you > (this is very common). > > [2] encrypt only to the sender, but also encrypt the plaintext only to > you, and store the encrypted file in your sent or other convenient folder, > with the date and the recipient. > > [3] only for the overly paranoid who revel in tedious work-arounds 8^) > : > > (a) Encrypt to both yourself and the recipient > (b) Remove your own id packet from the ciphertext, > (c) Re-calculate the crc of the ciphertext > (d) Send the 'hacked' ciphertext along to the original recipient > (e) Store the first ciphertext from (a) along with the one from (d), in > your sent folder > (f) now you will always be able to decrypt and retrieve the original > plaintext > > btw, > > I don't recommend this, > but it is *possible* to add a (not yet done, but not terribly complicated > either) patch to gnupg to 'display' the session key in the terminal window, > (while you are encrypting only to one recipient), > and then you can encrypt that session key to your key, and store it, > > or > > a (also not yet done, but not terribly complicated either) patch, > to allow gnupg to use a session key supplied by the user as an entry in > the command line > > (i.e. --use-session-key (64 character string from step (a) above) > > That session key is as random as any done by gnupg, and isn't really being > 're-used', > it's just being stored in the encrypted file from step (a) and is being > sent with the same message encrypted to the same recipient as in step (a) > > This is just to point out, that if someone wants to think paranoidly about > 'who else knows' what is encrypted in your encrypted e-mail that was > encrypted only to you, it 'can' be done, > (extremely tedious, and afaik , has not been implemented by any open-pgp > variant program out there 8^) ) > > > vedaal > > > > > > > ---------- Forwarded message ---------- > From: Frank Hrebabetzky > To: gnupg-users at gnupg.org > Cc: > Bcc: > Date: Thu, 3 Jan 2019 15:25:04 +0100 > Subject: decryption failed: Bad session key > Hi all, > > I have 2 encrypted files on my PC, let's call them A and B. Every now > and then, they are decrypted, edited and encrypted again with the -c > option. This has been working very well for decades, surviving several > changes of PCs and Linux flavours. The problem arose after my update > from Linux Mint 17 (Ubuntu 14) > to Linux Mint 19 (Ubuntu 18) > > Since then, A wasn't re-encrypted, and I can decrypt it as before. B > however was re-encrypted, and now I cannot decrypt it anymore. Each > attempt is responded with > > gpg: AES256 encrypted data > gpg: encrypted with 1 passphrase > gpg: decryption failed: Bad session key > > Regards, > -- > Frank Hrebabetzky +49 / 9261 / 950 0565 > > > > > > > ---------- Forwarded message ---------- > From: MFPA <2017-r3sgs86x8e-lists-groups at riseup.net> > To: vedaal via Gnupg-users on GnuPG-Users > Cc: vedaal via Gnupg-users > Bcc: > Date: Fri, 4 Jan 2019 03:09:53 +0000 > Subject: Re: gpg - difference --encrypt-to and --recipient > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi > > > On Thursday 3 January 2019 at 12:02:39 AM, in > , vedaal via > Gnupg-users wrote:- > > > > [2] encrypt only to the sender, but also encrypt the > > plaintext only > > to you, and store the encrypted file in your sent or > > other > > convenient folder, with the date and the recipient. > > I guess if you had an MUA that encrypted separately to BCC recipients, > you could achieve this by BCC-ing yourself. > > > > > [3] only for the overly paranoid who revel in tedious > > work-arounds 8^) : > > > (a) Encrypt to both yourself and the recipient > > (b) Remove your own id packet from the ciphertext, > > (c) Re-calculate the crc of the ciphertext > > (d) Send the 'hacked' ciphertext along to the > > original recipient > > (e) Store the first ciphertext from (a) along with > > the one from (d), in your sent folder > > (f) now you will always be able to decrypt and > > retrieve the original plaintext > > Would the ciphertext at (d) be much different than encrypting to the > recipient and hidden-encrypt-to your own key? > > > - -- > Best regards > > MFPA > > He's an environmentalist - his arguments are 100% recycled > -----BEGIN PGP SIGNATURE----- > > iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXC7OkV8UgAAAAAAuAChp > c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw > Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju > +oXLAP9VS4KkIcC46uXVbRrxMMnMb3uU3DnyWlQAN3BnerHiXQD+Mew6XBCf1Vsy > arODK2wCXESbLQGsX+zXveX+bNpzegyJApMEAQEKAH0WIQRSX6konxd5jbM7JygT > DfUWES/A/wUCXC7Okl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu > cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw > REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/139EACpg6S+lm2f56sqJzF4pWkosYFm > XzkgfMSIFgL241vmewDNAb54RsDtQ7sxZvy9jhIYVA0BFsRhmYmWNHjUWqEvb+iO > Q59yngpjJJkueCfVW6WiC1iCIURVZQ+wrSaQqks1/UyIk8JfwNPMntcjHbMPJt+M > hXxsxpBzy3wgbFfIxjNEx9XdcMOkt6wZHt1SmJQIhP2nw8QydqQAphcKEyBp7T/k > vRKOxExv6PgCWs93dCVWHhO/ek2BDBm5oDMZ0aFz/ZehhtRQapdQYZ5upWXBFcQc > DZgr/G+gDFtEmHjVyYugnBMT9sITau9WYZ+NedhIndwFNHmbd5EfI+i7KNd67kN0 > zn0YT21Lh37IMBeki87XcDMiTvNfmejs3ogUgiNwbsr8SGcHpwojKStWJdzlw381 > leN5VpLC921BojCgna+2k+xrx+z1+s6b5SZx3FV4118KuXoixRtfWTB52CB9KnzX > MRzfTy4IpjKjdpjqoLrQg7H+VlwVgHzU4p52OA0fWJHxDaYDZpl0mWA2ffL1qn4w > G2cMJKvOQacu2Me241z/tQ7FvLpZ6oKmeaFNM8wzN0vK2bYlh1PTrEE5hEDbWgIm > /J8Qmlg94QqPy7S/lB6BqaWb1lqe48AkdfjFiFwQYcw+3ibsnmhDmQyPe0OkWgqC > 1fjyulUQXjXBkJ19bg== > =yhZM > -----END PGP SIGNATURE----- > > > > _______________________________________________ > 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 bereska at hotmail.com Sat Jan 5 05:50:11 2019 From: bereska at hotmail.com (Dmitry Gudkov) Date: Sat, 5 Jan 2019 04:50:11 +0000 Subject: GPG on Ledger Nano S Message-ID: Dear GnuPG Experts, Can I please have your opinion on using Ledger Nano S as a PGP smart card? In search for an optimal PGP smart card for my Android phone I came across this article: https://kaansk.github.io/2018/Hello-World!-and-Using-Ledger-Nano-S-for-PGP/ I would like to set it up the following way on my Android phone: K-9 Mail + OpenKeychain + Ledger Nano S thank you for your help Dmitry -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From guru at unixarea.de Sat Jan 5 09:17:19 2019 From: guru at unixarea.de (Matthias Apitz) Date: Sat, 5 Jan 2019 09:17:19 +0100 Subject: OpenPGP card: how to lock the card again so that PIN is required In-Reply-To: <92d825c232d42059c9e22b2073adaa89a2352716.camel@googlemail.com> References: <20190101073658.GA8210@c720-r342378> <92d825c232d42059c9e22b2073adaa89a2352716.camel@googlemail.com> Message-ID: <20190105081719.GA6970@c720-r342378> El d?a martes, enero 01, 2019 a las 06:40:56p. m. +0100, Dirk Gottschalk escribi?: > Hello Matthias. > > Am Dienstag, den 01.01.2019, 08:36 +0100 schrieb Matthias Apitz: > > Hello, > > > This is with gnupg-2.2.12 and pcsc-lite-1.8.23. After an update of > > the System (FreeBSD CURRENT) the /usr/local/sbin/pcscd does no work > > anymore with the OpenPGP card (HID Global OMNIKEY 6121 Smart Card > > Reader) after withdraw and re-insert. It works fine after boot, I > > have to enter the PIN to unlock the card and all tested functions are > > working. > > Did you check the config for pcscd? Probably it was overwrittenby the > update process. To close this thread: It turned out being an issue in the USB chips in my laptop which was not correctly handeled by the USB driver in the kernel. It is fixed since yesterday with this commit: https://svnweb.freebsd.org/changeset/base/342778 matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jerry at seibercom.net Sat Jan 5 17:58:51 2019 From: jerry at seibercom.net (Jerry) Date: Sat, 5 Jan 2019 11:58:51 -0500 Subject: Removing expired keys Message-ID: <20190105115851.000078be@seibercom.net> I am not sure if this is the best place to ask this question, but it is a start. I am using GPG4WIN 3.1.5 on a Windows 10 machine. Over the years, I have accumulated several keys that are expired. Is there a way to remove those expired keys automatically, either from within Kleopatra or from the command line? I have tried Googling, but nothing useful ever appeared. Thanks! -- Jerry From sac at 300baud.de Sun Jan 6 11:11:42 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 6 Jan 2019 11:11:42 +0100 Subject: Feature proposal - image encryption Message-ID: <20190106111142.22e06138@300baud> Hi Werner and all, while looking for solutions to encrypt images, so that they are still viewable, i thought why not asking if such a feature could be implemented in the future in GnuPG. Here is a sample image, encrypted with the free Software ImageMagick, using the AES Cipher. https://postimg.cc/LJt8NRW2 Regards Stefan From rjh at sixdemonbag.org Sun Jan 6 11:17:14 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 6 Jan 2019 05:17:14 -0500 Subject: Removing expired keys In-Reply-To: <20190105115851.000078be@seibercom.net> References: <20190105115851.000078be@seibercom.net> Message-ID: <01282c3c-e3d8-ec7b-484a-bca30860b5c8@sixdemonbag.org> > or from the command line? I have tried Googling, but nothing useful > ever appeared. Didn't look very hard, did you? :) https://lists.gnupg.org/pipermail/gnupg-users/2017-February/057820.html From rjh at sixdemonbag.org Sun Jan 6 11:23:17 2019 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 6 Jan 2019 05:23:17 -0500 Subject: Removing expired keys In-Reply-To: <01282c3c-e3d8-ec7b-484a-bca30860b5c8@sixdemonbag.org> References: <20190105115851.000078be@seibercom.net> <01282c3c-e3d8-ec7b-484a-bca30860b5c8@sixdemonbag.org> Message-ID: > Didn't look very hard, did you? :) Before anyone accuses me of being less than helpful: Jerry asked this same question two years ago, got an answer on-list, verified that it solved his problem, and then just now asked the same question, got an answer from the same person, and was referred to the earlier thread. A touch of mild ribbing seems to be in order. :) From sac at 300baud.de Sun Jan 6 12:33:34 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 6 Jan 2019 12:33:34 +0100 Subject: Feature proposal - image encryption In-Reply-To: <20190106111142.22e06138@300baud> References: <20190106111142.22e06138@300baud> Message-ID: <20190106123334.74a8a110@300baud> On Sun, 6 Jan 2019 11:11:42 +0100, Stefan Claas wrote: > Hi Werner and all, > > while looking for solutions to encrypt images, so that > they are still viewable, i thought why not asking if such > a feature could be implemented in the future in GnuPG. > > Here is a sample image, encrypted with the free Software > ImageMagick, using the AES Cipher. > > https://postimg.cc/LJt8NRW2 And while thinking about a compromised Computer... Maybe it would be also very nice if the Pinentry program would allow in the future also mouse input via an additional virtual keyboard, like for example the software for the Kanguru Defender 3000 USB stick has. Thus in case of such a scenario one would simply draw a message, in let's say the free Gimp software, encrypt the image and voil? a secret message could still be created and send, imho. Regards Stefan From dirk.gottschalk1980 at googlemail.com Sun Jan 6 22:13:50 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 06 Jan 2019 22:13:50 +0100 Subject: Feature proposal - image encryption In-Reply-To: <20190106123334.74a8a110@300baud> References: <20190106111142.22e06138@300baud> <20190106123334.74a8a110@300baud> Message-ID: Hello Stefan. Am Sonntag, den 06.01.2019, 12:33 +0100 schrieb Stefan Claas: > On Sun, 6 Jan 2019 11:11:42 +0100, Stefan Claas wrote: > > Hi Werner and all, > > > > while looking for solutions to encrypt images, so that > > they are still viewable, i thought why not asking if such > > a feature could be implemented in the future in GnuPG. > > > > Here is a sample image, encrypted with the free Software > > ImageMagick, using the AES Cipher. > > > > https://postimg.cc/LJt8NRW2 > > And while thinking about a compromised Computer... > > Maybe it would be also very nice if the Pinentry program > would allow in the future also mouse input via an additional > virtual keyboard, like for example the software for the > Kanguru Defender 3000 USB stick has. Thus in case of such > a scenario one would simply draw a message, in let's say > the free Gimp software, encrypt the image and voil? a secret > message could still be created and send, imho. A virtual keyboard does not mitigate the vulnerability to key loggers or similar sniffing technologies. One could still be able to observe the data exchange between processes as long they are not isolated. I don't think GPG should start to mangle with other data formats. ImageMagick does the trick. Why should we invent the wheel a second time? Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From sac at 300baud.de Sun Jan 6 23:12:28 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 6 Jan 2019 23:12:28 +0100 Subject: Feature proposal - image encryption In-Reply-To: References: <20190106111142.22e06138@300baud> <20190106123334.74a8a110@300baud> Message-ID: <20190106231228.3c54e3b3@300baud> On Sun, 06 Jan 2019 22:13:50 +0100, Dirk Gottschalk wrote: Hi Dirk, > I don't think GPG should start to mangle with other data formats. > ImageMagick does the trick. Why should we invent the wheel a second > time? My thinking is that people using security tools like GnuPG might not trust tools from graphic tools programmers. And the second thought is in case GnuPG would allow this people like us could promote GnuPG for that in Computer Graphics communities and in other places, which are much bigger than encryption communities. GnuPG is world standard for email and probably file encryption, so why not for image encryption too? :-) At least it would not hurt to have such feature in GnuPG. ;-) Regards Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From dirk.gottschalk1980 at googlemail.com Sun Jan 6 23:19:24 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sun, 06 Jan 2019 23:19:24 +0100 Subject: Feature proposal - image encryption In-Reply-To: <20190106231228.3c54e3b3@300baud> References: <20190106111142.22e06138@300baud> <20190106123334.74a8a110@300baud> <20190106231228.3c54e3b3@300baud> Message-ID: Hi Stefan. Am Sonntag, den 06.01.2019, 23:12 +0100 schrieb Stefan Claas: > On Sun, 06 Jan 2019 22:13:50 +0100, Dirk Gottschalk wrote: > Hi Dirk, > > I don't think GPG should start to mangle with other data formats. > > ImageMagick does the trick. Why should we invent the wheel a second > > time? > My thinking is that people using security tools like GnuPG might > not trust tools from graphic tools programmers. And the second > thought is in case GnuPG would allow this people like us could > promote GnuPG for that in Computer Graphics communities and > in other places, which are much bigger than encryption communities. So, just encrypt a file the usual way with GPG. ^^ I see, what you're talking about. It's the Embedding into websites, what IM mentions. But, why should somebody distrust the aes implementation of an open source tool? Everybody can read the source, if he wants. I believe they just use one of the crypto-libraries available, like libcrypt, or libgcrypt, for example. > GnuPG is world standard for email and probably file encryption, so > why not for image encryption too? :-) > At least it would not hurt to have such feature in GnuPG. ;-) Except for the weeks, months, or years, which were needed to firstly implement the JPeg format, for example and the other ten millions of picture formats out there in the world. ;) I see what you mean regarding to promotion and so on. But, under the line, it's not worth the trouble. ^^ Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From sac at 300baud.de Sun Jan 6 23:42:03 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 6 Jan 2019 23:42:03 +0100 Subject: Feature proposal - image encryption In-Reply-To: References: <20190106111142.22e06138@300baud> <20190106123334.74a8a110@300baud> <20190106231228.3c54e3b3@300baud> Message-ID: <20190106234203.17127fae@300baud> On Sun, 06 Jan 2019 23:19:24 +0100, Dirk Gottschalk wrote: Hi Dirk, > > GnuPG is world standard for email and probably file encryption, so > > why not for image encryption too? :-) > > > At least it would not hurt to have such feature in GnuPG. ;-) > > Except for the weeks, months, or years, which were needed to firstly > implement the JPeg format, for example and the other ten millions of > picture formats out there in the world. ;) PNG is imho the current standard for Internet usage. Jpeg with its compression artifacts and other formats are also mentioned as not recommended to use with ImageMagick encryption. > I see what you mean regarding to promotion and so on. But, under the > line, it's not worth the trouble. ^^ Well, it is Werner's baby, so not my job to decide. It was only a proposal and not meant as a must have request. Regards Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: Digitale Signatur von OpenPGP URL: From dirk.gottschalk1980 at googlemail.com Mon Jan 7 00:02:04 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Mon, 07 Jan 2019 00:02:04 +0100 Subject: Feature proposal - image encryption In-Reply-To: <20190106234203.17127fae@300baud> References: <20190106111142.22e06138@300baud> <20190106123334.74a8a110@300baud> <20190106231228.3c54e3b3@300baud> <20190106234203.17127fae@300baud> Message-ID: Am Sonntag, den 06.01.2019, 23:42 +0100 schrieb Stefan Claas: > On Sun, 06 Jan 2019 23:19:24 +0100, Dirk Gottschalk wrote: > Hi Dirk, > > > GnuPG is world standard for email and probably file encryption, > > > so > > > why not for image encryption too? :-) > > > At least it would not hurt to have such feature in GnuPG. ;-) > > Except for the weeks, months, or years, which were needed to > > firstly implement the JPeg format, for example and the other ten > > millions of picture formats out there in the world. ;) > PNG is imho the current standard for Internet usage. Jpeg with its > compression artifacts and other formats are also mentioned as not > recommended to use with ImageMagick encryption. Yes, I read it earlier. But, the picture formats have to be inplemented anyways. and GPG is not intended to do this kind of file processing. By the way, AFAIT it was you who said, GPG has to much functions and options. ^^ Just kidding. > > I see what you mean regarding to promotion and so on. But, under > > the > > line, it's not worth the trouble. ^^ > Well, it is Werner's baby, so not my job to decide. It was only a > proposal and not meant as a must have request. Yes, it is Werners, and the rest of the core teams, decision. But this does not keep us away from discussing such things. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From vedaal at nym.hush.com Mon Jan 7 00:45:23 2019 From: vedaal at nym.hush.com (vedaal at nym.hush.com) Date: Sun, 06 Jan 2019 18:45:23 -0500 Subject: gpg - difference --encrypt-to and --recipient In-Reply-To: <1317686202.20190104030953@my_localhost_LG> References: <20181230224018.5495b170@300baud> <20181231124544.hlbaorgzkb3wfrom@aurora.local.incenp.org> <3bf3bf9025c0f5ca295dc53a570992741f91fc5d.camel@googlemail.com> <6A39FC9C-3105-451B-BB5E-6D6757337600@colmena.biz> <253629684.20190102011343@my_localhost_LG> <170C6A3F-F5D8-4A5A-A56B-57E7B52EBDA5@colmena.biz> <20190103000240.08304C0157@smtp.hushmail.com> <1317686202.20190104030953@my_localhost_LG> Message-ID: <20190106234523.B7DDE200EF@smtp.hushmail.com> On 1/3/2019 at 10:14 PM, "MFPA" wrote:> [3] only for the overly paranoid who revel in tedious > work-arounds 8^) : > (a) Encrypt to both yourself and the recipient > (b) Remove your own id packet from the ciphertext, > (c) Re-calculate the crc of the ciphertext > (d) Send the 'hacked' ciphertext along to the > original recipient > (e) Store the first ciphertext from (a) along with > the one from (d), in your sent folder > (f) now you will always be able to decrypt and > retrieve the original plaintext Would the ciphertext at (d) be much different than encrypting to the recipient and hidden-encrypt-to your own key? ===== Yes. The ciphertext in (d) would have no indication that it was being encrypted to anyone else. Using 'hidden-encrypt' to your own key, would show that it was encrypted to another key, but undetectable to whom. As a concrete difference, if you used the command: gpg --try-all-secrets on the file encrypted to the recipient and hidden-encrypt-to your own key, it would decrypt to your own key. Even from the ciphertext, it is detectable because it is 'longer' (i.e., has another key-packet). Try encrypting to only one recipient, and the encrypting the same plaintext to the same recipient, while also using hidden-encrypt to, and look at the difference in length. vedaal -------------- next part -------------- An HTML attachment was scrubbed... URL: From guru at unixarea.de Mon Jan 7 13:53:26 2019 From: guru at unixarea.de (Matthias Apitz) Date: Mon, 7 Jan 2019 13:53:26 +0100 Subject: GnuPG: Bad Passphrase (try 2 of 3) Message-ID: <20190107125236.GA3792@c720-r342378> Hello, I've GnuPG 2.1.12 on my mobile device (without any OpenPGP card) and generated there a new secret key to encrypt credentials I'm using on this device. I was a bit surprised reading (after entering a bas passphrase for testing): ?????????????????????????????????????????????????????????????????? ? Please enter the passphrase to unlock the OpenPGP secret key: ? ? "Matthias Apitz (BQ E4.5 key) " ? ? 4096-bit RSA key, ID FA46903FD2B8E5E9, ? ? created 2019-01-07 (main key ID 8F3E3E3C247AB779). ? ? ? ? ? **********> ? Bad Passphrase (try 2 of 3) ? ? ? ? Passphrase: __________________________________________________ ? ? ? ? ? ?????????????????????????????????????????????????????????????????? Note: This is not with the PIN of an OpenPGP-card. What would happen exactly after the 3rd bad value? Destroy of the key or my device? :-) Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dirk.gottschalk1980 at googlemail.com Mon Jan 7 13:59:41 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Mon, 07 Jan 2019 13:59:41 +0100 Subject: GnuPG: Bad Passphrase (try 2 of 3) In-Reply-To: <20190107125236.GA3792@c720-r342378> References: <20190107125236.GA3792@c720-r342378> Message-ID: Hello. Am Montag, den 07.01.2019, 13:53 +0100 schrieb Matthias Apitz: > Hello, > > I've GnuPG 2.1.12 on my mobile device (without any OpenPGP card) and > generated there a new secret key to encrypt credentials I'm using on > this device. I was a bit surprised reading (after entering a bas > passphrase for testing): > > Note: This is not with the PIN of an OpenPGP-card. What would happen > exactly after the 3rd bad value? Destroy of the key or my device? :-) Nothing happens, the running process will just be aborted after the third try. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From gnupg at raf.org Tue Jan 8 04:15:41 2019 From: gnupg at raf.org (gnupg at raf.org) Date: Tue, 8 Jan 2019 14:15:41 +1100 Subject: NIST 800-57 compatible unattended encryption? In-Reply-To: <5504353a-3347-502c-590f-31daf9bd0d7f@metacode.biz> References: <20190102050203.7psom2s5hqvphxgp@raf.org> <20190102094747.e5lhhj4rndllufos@aurora.local.incenp.org> <5504353a-3347-502c-590f-31daf9bd0d7f@metacode.biz> Message-ID: <20190108031541.6f4ziukdpccmcejg@raf.org> Wiktor Kwapisiewicz wrote: > Hello, > > > On Wed, Jan 02, 2019 at 04:02:03PM +1100, gnupg at raf.org wrote: > >> For some dumb reason I think I was hoping that the RSA > >> algorithm wasn't really used to encrypt all the data. I > >> thought it was probably used to encrypt a per-file > >> randomly-generated symmetric key which was then used to > >> encrypt the file (and was encrypted along with the > >> file) because it could be faster. But I think I'm > >> confusing it with network protocols like TLS. > >> > >> Is that what happens with RSA in gpg? [Probably not] > > > > Actually yes, that?s exactly what happens. The data (in your > > case, the contents of your file) is symmetrically encrypted using > > a randomly generated ?session key?, and *that* key is > > asymmetrically encrypted using the RSA public key. > > Yep, to see this behind-the-scenes thing in action check out > "--show-session-key" and "--override-session-key" options. Described here: > > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html > > Kind regards, > Wiktor Thanks for that. Unfortunately, it's still not NIST 800-57 compliant because the session key is encrypted using an asymmetric key. But I guess I'll just have to choose not to worry about that. Another question: I was googling the default symmetric algorithm and https://security.stackexchange.com/questions/86305/what-is-the-default-cipher-algorithm-for-gnupg says: For GnuPG 1.0 and 2.0, default is Cast5, for GnuPG 2.1 it is AES-128 But when I use gpg --list-packets --show-session-key -v on files encrypted via RSA keys with gpg-1.4.23 (macOS/macports) and gpg-2.1.18 (debian9), they both say: gpg: AES256 encrypted data Which is great but why is that? I haven't done anything in gpg.conf to override any defaults. Is the symmetric algorithm used with RSA keys unrelated to the default symmetric algorithm used by gpg when the --symmetric option is used? Hmm, when I encrypt a file with gpg -c and then --list-packets -v, the one encrypted with gpg-1.4.23 says: gpg: AES encrypted data and the one encrypted with gpg-2.1.18 says: gpg: AES256 encrypted data I guess that stackexchange page is wrong or out of date. The manpage for gpg on both systems says that the default symmetric algorithm is AES128 which seems correct for gpg-1.4.23 but incorrect for gpg-2.1.18. cheers, raf From bereska at hotmail.com Tue Jan 8 06:04:41 2019 From: bereska at hotmail.com (Dmitry Gudkov) Date: Tue, 8 Jan 2019 05:04:41 +0000 Subject: GPG on Ledger Nano S In-Reply-To: References: Message-ID: anybody there? On 04/01/2019 22:49, bereska wrote: > Dear GnuPG Experts, > > Can I please have your opinion on using Ledger Nano S as a PGP smart card? > > In search for an optimal PGP smart card for my Android phone I came > across this article: > https://kaansk.github.io/2018/Hello-World!-and-Using-Ledger-Nano-S-for-PGP/ > > I would like to set it up the following way on my Android phone: > K-9 Mail + OpenKeychain + Ledger Nano S > > > thank you for your help > Dmitry > From sac at 300baud.de Tue Jan 8 10:52:40 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 8 Jan 2019 10:52:40 +0100 Subject: gpg > addphoto Message-ID: <20190108105240.6f8d975a@300baud> Hi Werner and all, may i ask who had the brilliant idea to allow super large photos in OpenPGP keys? I ask, because when one likes to add a photo GnuPG recommends the size of 240x288 Pixels, which is a good choice. However when looking at parse-packet.c it says at line 44: #define MAX_ATTR_PACKET_LENGTH ( 16 * 1024*1024) Isn't this not a bit to much? I mean if i am right those numbers mean 16MB for me. To test this out i created a 24bit color gradient image 8000x8000 pixels in size and GnuPG says: [ unbekannt ] (2) [jpeg image of size 3889016] so only little bit lesser than 4MB. Was this large image size requested so that people in crypto circles can hide stuff in images etc. and then use key servers as secret distribution medium? Just curious, because otherwise it would not make to much sense to me. Regards Stefan From peter at digitalbrains.com Tue Jan 8 12:19:53 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 8 Jan 2019 12:19:53 +0100 Subject: gpg > addphoto In-Reply-To: <20190108105240.6f8d975a@300baud> References: <20190108105240.6f8d975a@300baud> Message-ID: On 08/01/2019 10:52, Stefan Claas wrote: > #define MAX_ATTR_PACKET_LENGTH ( 16 * 1024*1024) > [...] > > Was this large image size requested so that people > in crypto circles can hide stuff in images etc. and then > use key servers as secret distribution medium? Well, changing this number to something smaller would do nothing to prevent this. It's probably just a generous upper limit to prevent a DoS on GnuPG. What keyservers accept is not influenced by GnuPG. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Tue Jan 8 14:21:03 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 8 Jan 2019 14:21:03 +0100 Subject: gpg > addphoto In-Reply-To: References: <20190108105240.6f8d975a@300baud> Message-ID: <20190108142022.4c7e46bc@300baud> On Tue, 8 Jan 2019 12:19:53 +0100, Peter Lebbing wrote: > On 08/01/2019 10:52, Stefan Claas wrote: > > #define MAX_ATTR_PACKET_LENGTH ( 16 * 1024*1024) > > [...] > > > > Was this large image size requested so that people > > in crypto circles can hide stuff in images etc. and then > > use key servers as secret distribution medium? > > Well, changing this number to something smaller would do nothing to > prevent this. It's probably just a generous upper limit to prevent a DoS > on GnuPG. What keyservers accept is not influenced by GnuPG. I must admit i don't understand the DoS aspect in this regard, in case a key would only be allowed to a have the suggested* max image size. Larger sizes could be refused by GnuPG, when editing a key. *240x288 or slightly bigger. Regards Stefan From peter at digitalbrains.com Tue Jan 8 14:32:21 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 8 Jan 2019 14:32:21 +0100 Subject: gpg > addphoto In-Reply-To: <20190108142022.4c7e46bc@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> Message-ID: <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> Hello Stefan, On 08/01/2019 14:21, Stefan Claas wrote: > I must admit i don't understand the DoS aspect in this regard I hadn't looked closely, but since this is MAX_..._LENGTH in parse-packet.c, I assumed this is a cutoff while parsing packets. So if GnuPG encounters a packet that declares it is more than 16 MiB in size, instead of trying to gobble up and interpret and output all this data, which could lead to DoS (memory exhaustion, disk space exhaustion, long running time), GnuPG will just error out. So if GnuPG is ever fed crafted data that tries to DoS GnuPG, it will simply refuse to process it. So I assumed this didn't have anything to do with restricting what you can do with your own GnuPG, but what others can do onto your GnuPG. Suppose --edit-key restricted you in some way. This is free software. You just remove the restriction and recompile. Just like some people enjoy making insanely large RSA keys with GnuPG: they just remove the limit and recompile. So restricting --edit-key does not prevent you from bad actors. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Tue Jan 8 15:55:30 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 8 Jan 2019 15:55:30 +0100 Subject: gpg > addphoto In-Reply-To: <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> Message-ID: <20190108155457.78c0be3d@300baud> On Tue, 8 Jan 2019 14:32:21 +0100, Peter Lebbing wrote: Hi Peter, > Suppose --edit-key restricted you in some way. This is free software. > You just remove the restriction and recompile. Just like some people > enjoy making insanely large RSA keys with GnuPG: they just remove the > limit and recompile. So restricting --edit-key does not prevent you from > bad actors. Correct, but still it seems a bit to much if you look at avatars, profile images etc. on social media sites and other places. The images there are always reasonably in size when displayed and do not offer such large image size for usage, IIRC. Regards Stefan From peter at digitalbrains.com Tue Jan 8 16:17:21 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 8 Jan 2019 16:17:21 +0100 Subject: gpg > addphoto In-Reply-To: <20190108155457.78c0be3d@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> Message-ID: <17698ab9-a7cd-7386-e1a2-53f66df58f5f@digitalbrains.com> Hi Stefan, On 08/01/2019 15:55, Stefan Claas wrote: > Correct, but still it seems a bit to much Which is why I think this is not intended as a restriction to the users, but a restriction for DoS. Usually people here complain GnuPG doesn't allow for their use case, it's refreshing to read an opposite complaint ;-). Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jc.gnupg18a at unser.net Tue Jan 8 13:28:04 2019 From: jc.gnupg18a at unser.net (Juergen Christoffel) Date: Tue, 8 Jan 2019 13:28:04 +0100 Subject: Feature proposal - image encryption In-Reply-To: <20190106231228.3c54e3b3@300baud> References: <20190106111142.22e06138@300baud> <20190106123334.74a8a110@300baud> <20190106231228.3c54e3b3@300baud> Message-ID: <20190108122804.GB22290@unser.net> On Sun, Jan 06, 2019 at 11:12:28PM +0100, Stefan Claas wrote: >GnuPG is world standard for email and probably file encryption, so >why not for image encryption too? :-) As Dirk already said, you can encrypt image files with GnuPG already ;-) And why should I trust people less who maintain complicated software like (the fantastic) ImageMagick? >At least it would not hurt to have such feature in GnuPG. ;-) I beg to differ. Given the classic Unix philosophy of chaining small tools which do their job well, GnuPG is already way too complex, especially for casual users. I generally prefer the ImageMagick concept of small tools (convert, identify, mogrify, ...). So using ImageMagick for image encryption (in the way you want to use it) is fine, as using GnuPG for general file encryption is fine too. Creating the "eierlegende Wollmilchsau"[*] (what next: steganography in GnuPG? Or add audio encryption?) rarely does something good in the software world. --jc [*] For reader's who don't know the "concept" take a look at https://de.wikipedia.org/wiki/Eierlegende_Wollmilchsau ;-) -- Doctorow's Law: Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit. From dkg at fifthhorseman.net Tue Jan 8 17:12:41 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 08 Jan 2019 11:12:41 -0500 Subject: gpg > addphoto In-Reply-To: <20190108155457.78c0be3d@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> Message-ID: <87h8eji0w6.fsf@fifthhorseman.net> On Tue 2019-01-08 15:55:30 +0100, Stefan Claas wrote: > it seems a bit to much if you look at avatars, profile images > etc. on social media sites and other places. The images there are always > reasonably in size when displayed and do not offer such large image size for > usage, IIRC. I think you're recommending making a change to that default value. Do you have a new default value that you want to propose for future versions of GnuPG? Have you tried reducing it to your new proposed default value and experimented with it, to let us know what it does to, say, photos larger than that value already stored in your keyring? have you tried looking at statistics of what sizes of images are present in the public keyserver dumps? those would all be reasonable next steps if you want to present a convincing case for action here. regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Tue Jan 8 17:39:28 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 8 Jan 2019 17:39:28 +0100 Subject: gpg > addphoto In-Reply-To: <87h8eji0w6.fsf@fifthhorseman.net> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> Message-ID: <20190108173913.630d343c@300baud> On Tue, 08 Jan 2019 11:12:41 -0500, Daniel Kahn Gillmor wrote: > On Tue 2019-01-08 15:55:30 +0100, Stefan Claas wrote: > > it seems a bit to much if you look at avatars, profile images > > etc. on social media sites and other places. The images there are always > > reasonably in size when displayed and do not offer such large image size for > > usage, IIRC. > > I think you're recommending making a change to that default value. Good question! I think a recommendation is already to late, because like Peter said one can change the values. To be honest i don't understand why this was implemented this way in the first place, but it should be not my business i guess and people might use it as a replacement for Yakamo K's image uploader to SKS, because GnuPG makes it convenient to view then such images. > Do you have a new default value that you want to propose for future > versions of GnuPG? GnuPG itself suggests an image size of 240x288 pixels when doing so. Maybe slightly larger would be fine too. > Have you tried reducing it to your new proposed default value and > experimented with it, to let us know what it does to, say, photos larger > than that value already stored in your keyring? No. > have you tried looking at statistics of what sizes of images are present > in the public keyserver dumps? Not yet, but it should be interesting to parse a dump. > those would all be reasonable next steps if you want to present a > convincing case for action here. I did not ask for action here, even if it sounded like that. I was curious to know why such a large size was implemented. Regards Stefan From peter at digitalbrains.com Tue Jan 8 18:50:12 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Tue, 8 Jan 2019 18:50:12 +0100 Subject: gpg > addphoto In-Reply-To: <20190108173913.630d343c@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> Message-ID: <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> Hi Stefan, On 08/01/2019 17:39, Stefan Claas wrote: > To be honest i don't understand why this was implemented this way in > the first place I'm just guessing, I don't know for sure. But since it seems you're unclear about what I meant, I'm trying to explain that. I don't think this implementation is meant to restrict users in creating image attributes at all. It's not meant as some means to stop a user from creating a mega-large image. So you're coming at it from the wrong direction when you say "isn't this a bit too much to allow". Rather, it's meant as a means to prevent *reading* such a large image. With all software, but with crypto even more, you need to build in defenses against people trying to create a mess for others. So suppose someone created a public key containing some mega-large image, or corrupting a public key to contain nonsense data. In this case, when you import this key and your GnuPG is reading this data it needs to have some safeguards against malfunctioning. You ask why it was implemented this way. The reasoning is: nobody bona fide would ever create an (image) attribute larger than 16 MiB. In fact, it would be much less, but we're being conservative and saying: well, no matter the circumstances, 16 MiB is certainly ridiculous. So if GnuPG ever encounters an attribute larger than 16 MiB, it should just stop and display an error instead of trying to continue. Because clearly something fishy is going on. A real attribute will always be much smaller. That's a reason to halt and give up. So, yes, 16 MiB is ridiculous. That's the point. It's a test to see whether we are doing something that we're supposed to be doing, or whether we're looking at something ridiculous. So when you say "Shouldn't users be forced to limit themselves to something much smaller?", that's simply a different subject as I understand it. This 16 MiB has nothing to do with that, it's a different mechanism. I hope I did a good job of explaining my meaning this time around. But I'd like to tack on even more thoughts :-). Because finally, what GnuPG enforces is again something different from what the keyserver network enforces. If you're worried about big images or other data being uploaded to the keyservers, the place to fix that would be the keyservers, not GnuPG, because a bad actor could just change their own GnuPG. But they can't change the code running in the public keyserver network other than by running their own keyserver. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From hreba at t-online.de Tue Jan 8 19:47:01 2019 From: hreba at t-online.de (Frank Hrebabetzky) Date: Tue, 8 Jan 2019 19:47:01 +0100 Subject: decryption failed: Bad session key In-Reply-To: <4416819b-8de9-a413-2c65-6a221bf47193@t-online.de> References: <4416819b-8de9-a413-2c65-6a221bf47193@t-online.de> Message-ID: Hi there, I had a bad timing with my post, so just as a reminder for those who were absorbed by the holidays. Any hint? Regards, -- Frank Hrebabetzky +49 / 9261 / 950 0565 On 1/3/19 3:25 PM, Frank Hrebabetzky wrote: > Hi all, > > I have 2 encrypted files on my PC, let's call them A and B. Every now > and then, they are decrypted, edited and encrypted again with the -c > option. This has been working very well for decades, surviving several > changes of PCs and Linux flavours. The problem arose after my update > from??? Linux Mint 17 (Ubuntu 14) > to??? Linux Mint 19 (Ubuntu 18) > > Since then, A wasn't re-encrypted, and I can decrypt it as before. B > however was re-encrypted, and now I cannot decrypt it anymore. Each > attempt is responded with > > gpg: AES256 encrypted data > gpg: encrypted with 1 passphrase > gpg: decryption failed: Bad session key > > Regards, From sac at 300baud.de Tue Jan 8 20:16:59 2019 From: sac at 300baud.de (Stefan Claas) Date: Tue, 8 Jan 2019 20:16:59 +0100 Subject: gpg > addphoto In-Reply-To: <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> Message-ID: <20190108201659.7705a0ab@300baud> On Tue, 8 Jan 2019 18:50:12 +0100, Peter Lebbing wrote: Hi Peter, [snip] > I hope I did a good job of explaining my meaning this time around. Yes, i think you did, even if i see things a bit different. But no worries! :-) Since this is an interesting subject, i believe, i may check out how much payload can be put in such large jpeg images, just out of of interest and i may, if time allows, try to get hold of a complete key server dump to try to see if i can find something interesting. > But I'd like to tack on even more thoughts :-). Because finally, what > GnuPG enforces is again something different from what the keyserver > network enforces. If you're worried about big images or other data being > uploaded to the keyservers, the place to fix that would be the > keyservers, not GnuPG, because a bad actor could just change their own > GnuPG. But they can't change the code running in the public keyserver > network other than by running their own keyserver. Yes, agreed! However, as it currently is there is no need for bad actors because people have plenty of image space in a key. Regards Stefan From dirk.gottschalk1980 at googlemail.com Tue Jan 8 21:23:40 2019 From: dirk.gottschalk1980 at googlemail.com (dirk.gottschalk1980 at googlemail.com) Date: Tue, 08 Jan 2019 21:23:40 +0100 Subject: gpg > addphoto In-Reply-To: <20190108201659.7705a0ab@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> Message-ID: <9eff4af9b25434aefc179abc0a290e5be67021b9.camel@googlemail.com> Hello. Am Dienstag, den 08.01.2019, 20:16 +0100 schrieb Stefan Claas: > Yes, agreed! However, as it currently is there is no need for bad > actors because people have plenty of image space in a key. Uh, I think you have found a new place where the guys can hide their porn collections so there wifes don't find it. Sorry, could not resist. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac From wk at gnupg.org Tue Jan 8 22:29:45 2019 From: wk at gnupg.org (Werner Koch) Date: Tue, 08 Jan 2019 22:29:45 +0100 Subject: Feature proposal - image encryption In-Reply-To: <20190108122804.GB22290@unser.net> (Juergen Christoffel's message of "Tue, 8 Jan 2019 13:28:04 +0100") References: <20190106111142.22e06138@300baud> <20190106123334.74a8a110@300baud> <20190106231228.3c54e3b3@300baud> <20190108122804.GB22290@unser.net> Message-ID: <87ef9mn8hi.fsf@wheatstone.g10code.de> On Tue, 8 Jan 2019 13:28, jc.gnupg18a at unser.net said: > I beg to differ. Given the classic Unix philosophy of chaining small tools > which do their job well, GnuPG is already way too complex, especially for > casual users. I generally prefer the ImageMagick concept of small tools I would have send a very simlar answer. Maybe focusing on code complexity instead of complexity as perceived by the user. No rule without exception: We have one tool in GnuPG which kind of violates the Unix philosophy by providing a clone of the tar command. However, we have two reason for that a) There is no tar on Windows and we are not able to use the script we use on Unix and b) the encrypted tar format requires a pretty special version of tar and todays tar tools are not all able to create that variant of the format (ustar). To do image encryption according to whatever standard it is best to either modify an image tool to make use of gpgme (or if really needed of gpg directly) or to write a small tool which does the same using the standard image libraries and gpgme. Libreoffice recently did it in the first way and I wish someone sits down and writes a tool to do the same for PDF. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Wed Jan 9 18:06:52 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 9 Jan 2019 18:06:52 +0100 Subject: gpg > addphoto In-Reply-To: <20190108201659.7705a0ab@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> Message-ID: <20190109180652.3221b6cd@300baud> On Tue, 8 Jan 2019 20:16:59 +0100, Stefan Claas wrote: > Since this is an interesting subject, i believe, i may check out how much > payload can be put in such large jpeg images, just out of of interest > and i may, if time allows, try to get hold of a complete key server dump > to try to see if i can find something interesting. O.k. i did a quick check on github for proper tools and found this very interesting tool, written in Golang. https://github.com/umahmood/steg The provided Chief Wiggum image contains a 2 seconds .mp4 movie clip. Pretty awesome imho! So this means that one can hide in a PGP key movies and other files too, hidden in jpeg images and distribute it securely via SKS... Regards Stefan From dirk.gottschalk1980 at googlemail.com Wed Jan 9 22:25:21 2019 From: dirk.gottschalk1980 at googlemail.com (dirk.gottschalk1980 at googlemail.com) Date: Wed, 09 Jan 2019 22:25:21 +0100 Subject: gpg > addphoto In-Reply-To: <20190109180652.3221b6cd@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> Message-ID: Hi Stefan. Am Mittwoch, den 09.01.2019, 18:06 +0100 schrieb Stefan Claas: > On Tue, 8 Jan 2019 20:16:59 +0100, Stefan Claas wrote: [...] > The provided Chief Wiggum image contains a 2 seconds .mp4 movie > clip. Pretty awesome imho! So this means that one can hide in a PGP > key movies and other files too, hidden in jpeg images and distribute > it securely via SKS... But, this is more a Problem of SKS. When SKS accepts such keys, it's not GPG's fault. Anyways, anybody can generate anything he wants witrh GPG. Such restriction would NOT have any effects, because the key generation is done by the users GPG. Anybody can change the source code of GPG in any way and generate everything. Restictions at the end is senseless in open source world. Thje Servers are controlled by their owners so it is in their hands, what can be distributed. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4571 bytes Desc: not available URL: From sac at 300baud.de Wed Jan 9 22:50:17 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 9 Jan 2019 22:50:17 +0100 Subject: gpg > addphoto In-Reply-To: References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> Message-ID: <20190109225017.1608c8e7@300baud> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, 09 Jan 2019 22:25:21 +0100, dirk.gottschalk1980 at googlemail.com wrote: Hi Dirk, > But, this is more a Problem of SKS. When SKS accepts such keys, it's > not GPG's fault. Forget SKS for a moment, i send you, or distribute, such a key via other mediums and your GnuPG will accept it. :-D I am also not complaining or suggesting here something. I only wanted to know why such a large image size in the first place was chosen, when GnuPG suggest a much much smaller size. :-) Regards Stefan -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTsFcZEw1lI/LR+FYmaI04LDh8f6AUCXDZsmQAKCRCaI04LDh8f 6A9AAQCxUMdjYFbVYfEXyVkpCbT/UDeUDO7ZSD7I0lNBihVvFQD+Kj6T55Du6YAj /rFZ1awzTJSuIER1M8XC1peazzBLbgk= =TzJh -----END PGP SIGNATURE----- From dirk.gottschalk1980 at googlemail.com Wed Jan 9 23:29:06 2019 From: dirk.gottschalk1980 at googlemail.com (dirk.gottschalk1980 at googlemail.com) Date: Wed, 09 Jan 2019 23:29:06 +0100 Subject: gpg > addphoto In-Reply-To: <20190109225017.1608c8e7@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> Message-ID: <0c65b9af34b6600c7d636d8d759cd92e0bd285e2.camel@googlemail.com> Hello Stefan. Am Mittwoch, den 09.01.2019, 22:50 +0100 schrieb Stefan Claas: > On Wed, 09 Jan 2019 22:25:21 +0100, > dirk.gottschalk1980 at googlemail.com wrote: > > Hi Dirk, > > > But, this is more a Problem of SKS. When SKS accepts such keys, > > it's > > not GPG's fault. > Forget SKS for a moment, i send you, or distribute, such a key via > other mediums and your GnuPG will accept it. :-D As long, as the size of the picture doesn't exceed 16M, it surely will be accepted. But this should not take a long time, 16M is nothing, so there is no Problem with this. Nobody says it has to be prevented. Sure, GPG can be "abused" in many ways. I also do this by using it for a purpose it was not invented for. This is not an evil functionality. If dome people like to put HiRes photos or other pictures in their UID, for whatever purpose, so it is not an evil thing. Distributing a key via email is no problem in this case and SKS, WKS and others should oinly prevent storing those key for storage and sanity reasons. > I only wanted to know why such a large image size in the first > place was chosen, when GnuPG suggest a much much smaller > size. :-) I think the 16M are from times, where RAM was nbot measured in GB. In this case it was to avoid long package computation times because the RAM was smaller than 1GB. They had to choose a limit to avoid DDoS attacks to GPG on a users computer. There was no intention to limit the size of the photo because nobody thought about this at the moment of decision. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From gnupg at raf.org Wed Jan 9 23:41:59 2019 From: gnupg at raf.org (gnupg at raf.org) Date: Thu, 10 Jan 2019 09:41:59 +1100 Subject: gpg > addphoto In-Reply-To: <20190109225017.1608c8e7@300baud> References: <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> Message-ID: <20190109224159.7j2eqtod4rlg32gl@raf.org> Stefan Claas wrote: > I only wanted to know why such a large image size in the first > place was chosen, when GnuPG suggest a much much smaller > size. :-) I'd guess that it's not about image size. It's a maximum packet size. Things other than images have to go in there as well (although an image would no doubt usually take up most of the space). It's part of GNU philosophy to not implement unnecessary hard limits in software but one good reason to impose limits is to prevent denial of service conditions. Perhaps a 16MB packet size limit was chosen because it would be more than enough to support keys with a huge number of signatures, and an image, without causing problems for users, and without permitting a denial of service condition. 16MB isn't that much RAM these days. But I am just guessing. I hope it's not to support hi-res iris scans, voice prints and compressed DNA. :-) cheers, raf From dgouttegattat at incenp.org Thu Jan 10 00:13:33 2019 From: dgouttegattat at incenp.org (Damien Goutte-Gattat) Date: Wed, 9 Jan 2019 23:13:33 +0000 Subject: gpg > addphoto In-Reply-To: <0c65b9af34b6600c7d636d8d759cd92e0bd285e2.camel@googlemail.com> References: <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> <0c65b9af34b6600c7d636d8d759cd92e0bd285e2.camel@googlemail.com> Message-ID: <20190109231333.qog25h2o44x4tw5y@aurora.local.incenp.org> On Wed, Jan 09, 2019 at 11:29:06PM +0100, dirk1980ac via Gnupg-users wrote: > > I only wanted to know why such a large image size in the first > > place was chosen, when GnuPG suggest a much much smaller > > size. :-) > > I think the 16M are from times, where RAM was nbot measured in GB. Not quite. If you look at the code?s history, you?ll find that the 16MB limit is actually from 2014 [1]. There was no limitation on the size of user attribute packets before that. It is wise to be careful when you abruptly introduce a limitation that did not exist before; 16MB was chosen because it is big enough to avoid breaking any existing key with a legitimate user attribute packet, while still preventing DoS attempts with deliberately oversized packets. Of note, the OpenPGP RFC does allow arbitrary large attribute packets, which means that strictly speaking, GnuPG is already "wrong" to reject a packet larger than 16MB. - Damien [1] https://dev.gnupg.org/rGbab9cdd971f35ff47e153c00034c95e7ffeaa09a -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From sac at 300baud.de Thu Jan 10 15:56:43 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 10 Jan 2019 15:56:43 +0100 Subject: gpg > addphoto In-Reply-To: <20190109231333.qog25h2o44x4tw5y@aurora.local.incenp.org> References: <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> <0c65b9af34b6600c7d636d8d759cd92e0bd285e2.camel@googlemail.com> <20190109231333.qog25h2o44x4tw5y@aurora.local.incenp.org> Message-ID: <20190110155643.302ca32e@300baud> On Wed, 9 Jan 2019 23:13:33 +0000, Damien Goutte-Gattat wrote: > On Wed, Jan 09, 2019 at 11:29:06PM +0100, dirk1980ac via Gnupg-users wrote: > > > I only wanted to know why such a large image size in the first > > > place was chosen, when GnuPG suggest a much much smaller > > > size. :-) > > > > I think the 16M are from times, where RAM was nbot measured in GB. > > Not quite. If you look at the code?s history, you?ll find that the 16MB > limit is actually from 2014 [1]. There was no limitation on the size of > user attribute packets before that. Thanks for the info! > It is wise to be careful when you abruptly introduce a limitation that > did not exist before; 16MB was chosen because it is big enough to avoid > breaking any existing key with a legitimate user attribute packet, while > still preventing DoS attempts with deliberately oversized packets. Have you or anybody else seen such a large and legitimate attribute packet, also one from before 2014? I really would like to see such a key to get a better understanding. Regards Stefan From sac at 300baud.de Thu Jan 10 16:23:05 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 10 Jan 2019 16:23:05 +0100 Subject: gpg > addphoto In-Reply-To: <20190109224159.7j2eqtod4rlg32gl@raf.org> References: <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> <20190109224159.7j2eqtod4rlg32gl@raf.org> Message-ID: <20190110162305.45c83f83@300baud> On Thu, 10 Jan 2019 09:41:59 +1100, gnupg at raf.org wrote: > Stefan Claas wrote: > > > I only wanted to know why such a large image size in the first > > place was chosen, when GnuPG suggest a much much smaller > > size. :-) > > I'd guess that it's not about image size. It's a > maximum packet size. Sorry, yes you are right it is the maximum packet size, but as understood used for images only. Or are there any more attribute packets like No. 1? (i have to check the draft, i guess.) >Things other than images have to > go in there as well (although an image would no doubt > usually take up most of the space). There are different packets for each purpose, as understood. > It's part of GNU philosophy to not implement unnecessary > hard limits in software but one good reason to impose limits > is to prevent denial of service conditions. What i really don't get with this DoS stuff is when one uses with friends etc. the regular version of GnuPG / PGP and obtains the keys from friends, checks the fingerprint why should one worry? Sure, if i customize the source code I can do such stuff to other keys on SKS key servers, but then people can still ask their friends and say "hi there seems to be something wrong with your key, can you mail me please a copy". Or are there cases when messages are in transient and can those be quickly modified, so that GnuPG crashes (your system)? Regards Stefan From dirk.gottschalk1980 at googlemail.com Thu Jan 10 18:38:36 2019 From: dirk.gottschalk1980 at googlemail.com (dirk.gottschalk1980 at googlemail.com) Date: Thu, 10 Jan 2019 18:38:36 +0100 Subject: gpg > addphoto In-Reply-To: <20190110162305.45c83f83@300baud> References: <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> <20190109224159.7j2eqtod4rlg32gl@raf.org> <20190110162305.45c83f83@300baud> Message-ID: Hello. Am Donnerstag, den 10.01.2019, 16:23 +0100 schrieb Stefan Claas: > > It's part of GNU philosophy to not implement unnecessary > > hard limits in software but one good reason to impose limits > > is to prevent denial of service conditions. > What i really don't get with this DoS stuff is when one uses with > friends etc. the regular version of GnuPG / PGP and obtains the > keys from friends, checks the fingerprint why should one worry? > Sure, if i customize the source code I can do such stuff to other > keys on SKS key servers, but then people can still ask their friends > and say "hi there seems to be something wrong with your key, can you > mail me please a copy". DoS does not necessarily mean crashing the system. A "hanging" process or a process that takes much more time as necessary is also a DoS. Crashing a system is only the hardest variant. And this prevents also prevents an unintended DoS which means a very big key by mistake. It's okay to allow the generation of everything a user wants, especially in open source software where everybody can change the values. A hard limit would make no sense at all. > Or are there cases when messages are in transient and can those > be quickly modified, so that GnuPG crashes (your system)? As said, it's not necessarily a crash, but GPOG takung two hours to process a key which has gigabytes, just for example, could be considered a DOS. ^^ Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From peter at digitalbrains.com Thu Jan 10 19:25:26 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Thu, 10 Jan 2019 19:25:26 +0100 Subject: gpg > addphoto In-Reply-To: <20190110155643.302ca32e@300baud> References: <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> <0c65b9af34b6600c7d636d8d759cd92e0bd285e2.camel@googlemail.com> <20190109231333.qog25h2o44x4tw5y@aurora.local.incenp.org> <20190110155643.302ca32e@300baud> Message-ID: <9842532a-1dc2-82da-04e7-12275272be91@digitalbrains.com> On 10/01/2019 15:56, Stefan Claas wrote: > Have you or anybody else seen such a large and legitimate attribute > packet, also one from before 2014? That would be rather surprising as usually such limits are chosen to be quite conservative, i.e., way above what is legitimately used. That would thus mean that there are no such large legitimate attributes. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Thu Jan 10 19:33:01 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 10 Jan 2019 19:33:01 +0100 Subject: gpg > addphoto In-Reply-To: References: <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> <20190109224159.7j2eqtod4rlg32gl@raf.org> <20190110162305.45c83f83@300baud> Message-ID: <20190110193239.60974b2f@300baud> On Thu, 10 Jan 2019 18:38:36 +0100, dirk.gottschalk1980 at googlemail.com wrote: Hi Dirk, > Am Donnerstag, den 10.01.2019, 16:23 +0100 schrieb Stefan Claas: > And this prevents also prevents an unintended DoS which means a very > big key by mistake. It's okay to allow the generation of everything a > user wants, especially in open source software where everybody can > change the values. A hard limit would make no sense at all. Just wondering, have you ever used other (more modern) open source crypto software, which have hard limits and still get's the job done? Regards Stefan From justina at colmena.biz Thu Jan 10 09:40:02 2019 From: justina at colmena.biz (justina colmena) Date: Wed, 09 Jan 2019 23:40:02 -0900 Subject: gpg > addphoto In-Reply-To: <9eff4af9b25434aefc179abc0a290e5be67021b9.camel@googlemail.com> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <9eff4af9b25434aefc179abc0a290e5be67021b9.camel@googlemail.com> Message-ID: <32E58BE7-D9CE-4765-96BF-7F0467B2AE95@colmena.biz> On January 8, 2019 11:23:40 AM AKST, dirk1980ac via Gnupg-users wrote: >Hello. > >Am Dienstag, den 08.01.2019, 20:16 +0100 schrieb Stefan Claas: > >> Yes, agreed! However, as it currently is there is no need for bad >> actors because people have plenty of image space in a key. > >Uh, I think you have found a new place where the guys can hide their >porn collections so there wifes don't find it. > >Sorry, could not resist. > >Regards, >Dirk It's a peculiar problem with which law enforcement is of little or no assistance. There's a gun and a badge and a gang of dicks with flashlights all over town, and a heavy-breathing warrant to bust your door in on that stuff. Neither the law enforcement credentials nor the color of law excuse the base human desire of cops to indulge their own flesh. A related problem is "image phreaking." People make a game of digitally altering images and obscuring their source. Others make a game of deobfuscating the images and tracking them down. There is a very close-knit community of this sort of thing among disreputable hangers-on to Interpol, Europol, US FBI, Russian FSB, etc. Several times I have been forced to permanently dissociate myself from all images and photos ever to have been associated with me, whether photos I have taken myself or which were found on my computer. Those people were hunting me, and they were led astray by their false assumptions, because *I* usually assume when foreign cops are hunting me that they are hunting to kill, and not to bring criminal or civil charges in court. Wherever there is a photo or image of any sort, cops as well as a certain low-class security apparatchik always _assume_ an unhealthy obsession or morbid desire to memorialize something or someone. I mean, if you're not a professional photographer, you are _assumed_ to be trespassing on their intellectual property in some way or another, however they can twist it around in court to make it appear so. It's all part and parcel of the artsy-fartsy red-light district with the FBI warnings on all the Hollywood movies, actresses accusing male fans of stalking, etc. So digital photos and images become a cop-calling feminists' emotional space where men in general and less privileged women are prohibited by law, but professional necktied gentlemen are perfectly welcome. -- Una Milicia bien regulada, estando necesaria a la seguridad de un Estado libre, el derecho del pueblo de tener y de portar Armas, no ser? infringido. https://www.colmena.biz/~justina/ From sac at 300baud.de Fri Jan 11 23:49:02 2019 From: sac at 300baud.de (Stefan Claas) Date: Fri, 11 Jan 2019 23:49:02 +0100 Subject: gpg > addphoto In-Reply-To: <20190109180652.3221b6cd@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> Message-ID: <20190111234902.452ce36d@300baud> On Wed, 9 Jan 2019 18:06:52 +0100, Stefan Claas wrote: > O.k. i did a quick check on github for proper tools and found this > very interesting tool, written in Golang. > > https://github.com/umahmood/steg Just had the time to test this very nice little tool with GnuPG. I prepared an image 800x571 pixels 72dpi and embedded an mp3 message, created with the macOS say command. Everything works as expected. One only needs to use then: gpg --list-keys --list-options show-photo 359A1872F120F7E7 so that preview from macOS displays the image for saving (with standard settings). Very nice and easy workflow and the resulting key is only 61KB in size. If someone like to look at the key: https://pgp.circl.lu/pks/lookup?op=get&search=0x359A1872F120F7E7 Regards Stefan From idmsdba at nycap.rr.com Fri Jan 11 23:32:35 2019 From: idmsdba at nycap.rr.com (Michael A. Yetto) Date: Fri, 11 Jan 2019 17:32:35 -0500 Subject: gpg > addphoto In-Reply-To: <32E58BE7-D9CE-4765-96BF-7F0467B2AE95@colmena.biz> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <9eff4af9b25434aefc179abc0a290e5be67021b9.camel@googlemail.com> <32E58BE7-D9CE-4765-96BF-7F0467B2AE95@colmena.biz> Message-ID: <20190111173235.52ee08a1@braetac.lighthouse.yetnet> On Wed, 09 Jan 2019 23:40:02 -0900 justina colmena via Gnupg-users writes, and having writ moves on: >It's a peculiar problem with which law enforcement is of little or no >assistance. There's a gun and a badge and a gang of dicks with >flashlights all over town, and a heavy-breathing warrant to bust your >door in on that stuff. Neither the law enforcement credentials nor the >color of law excuse the base human desire of cops to indulge their own >flesh. > I think you are responding to your own view of the world here and not to the tread or anything pertaining to GNUPG. I for one would appreciate it if such vitriol as this is left in a more appropriate venue than this mailing list. Choosing such a venue is left as an exercise for the reader. Mike Yetto -- "It's the job that's never started as takes longest to finish." - Samwise Gamgee From dirk.gottschalk1980 at googlemail.com Sat Jan 12 05:59:47 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Sat, 12 Jan 2019 05:59:47 +0100 Subject: gpg > addphoto In-Reply-To: <20190110193239.60974b2f@300baud> References: <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190109225017.1608c8e7@300baud> <20190109224159.7j2eqtod4rlg32gl@raf.org> <20190110162305.45c83f83@300baud> <20190110193239.60974b2f@300baud> Message-ID: <77061eb4d5ecc6c94ffe19a04a0870f489dcc622.camel@googlemail.com> Hi Stefan. Am Donnerstag, den 10.01.2019, 19:33 +0100 schrieb Stefan Claas: > On Thu, 10 Jan 2019 18:38:36 +0100, > dirk.gottschalk1980 at googlemail.com wrote: > Hi Dirk, > > Am Donnerstag, den 10.01.2019, 16:23 +0100 schrieb Stefan Claas: > > And this prevents also prevents an unintended DoS which means a > > very big key by mistake. It's okay to allow the generation of > > everything a user wants, especially in open source software where > > everybody can change the values. A hard limit would make no sense > > at all. > Just wondering, have you ever used other (more modern) open source > crypto software, which have hard limits and still get's the job done? Yes, there sure is, but, as long as the tool is open source and anybody who wants to change the limit to his own, such limits are useless. Regarding to this, the Parameter is applied to avoid reading larger Packets than 16M for importing and so on, on the client side. So, if a 'bad guy' alters his version of GPG in a way to create such abusive keys, the other users with an unaltered version should not get into trouble with such a key. Okay, it's quite possible to set this read limit down to, let's say, 8M, but I think 16M is a good limit to avoid hanging and other side effects with a way to large key. Regards, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac From sac at 300baud.de Sat Jan 12 20:48:30 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 12 Jan 2019 20:48:30 +0100 Subject: gpg > addphoto In-Reply-To: <20190111234902.452ce36d@300baud> References: <20190108105240.6f8d975a@300baud> <20190108142022.4c7e46bc@300baud> <6c4f3a6e-7707-d7f4-52a4-ccffb30a4aba@digitalbrains.com> <20190108155457.78c0be3d@300baud> <87h8eji0w6.fsf@fifthhorseman.net> <20190108173913.630d343c@300baud> <3c9e75d0-f2bb-1938-1375-023442552ee3@digitalbrains.com> <20190108201659.7705a0ab@300baud> <20190109180652.3221b6cd@300baud> <20190111234902.452ce36d@300baud> Message-ID: <20190112204830.096129c1@300baud> On Fri, 11 Jan 2019 23:49:02 +0100, Stefan Claas wrote: > On Wed, 9 Jan 2019 18:06:52 +0100, Stefan Claas wrote: > > > O.k. i did a quick check on github for proper tools and found this > > very interesting tool, written in Golang. > > > > https://github.com/umahmood/steg > > Just had the time to test this very nice little tool with GnuPG. > > I prepared an image 800x571 pixels 72dpi and embedded an mp3 > message, created with the macOS say command. > > Everything works as expected. One only needs to use then: > > gpg --list-keys --list-options show-photo 359A1872F120F7E7 > > so that preview from macOS displays the image for saving (with > standard settings). > > Very nice and easy workflow and the resulting key is only 61KB in size. > > If someone like to look at the key: > > https://pgp.circl.lu/pks/lookup?op=get&search=0x359A1872F120F7E7 I have quickly compiled steg for 26 OS platforms, so that everybody can test it out. ;-) Regards Stefan From ineiev at gnu.org Sat Jan 12 20:25:02 2019 From: ineiev at gnu.org (Ineiev) Date: Sat, 12 Jan 2019 14:25:02 -0500 Subject: [SOLVED] gpg doesn't import secret keys for me any more In-Reply-To: <20190112191247.GP17246@gnu.org> References: <20190112191247.GP17246@gnu.org> Message-ID: <20190112192501.GQ17246@gnu.org> On Sat, Jan 12, 2019 at 02:12:47PM -0500, Ineiev wrote: > dti at manas:~$ gpg --home h1 --import From ineiev at gnu.org Sat Jan 12 20:12:47 2019 From: ineiev at gnu.org (Ineiev) Date: Sat, 12 Jan 2019 14:12:47 -0500 Subject: gpg doesn't import secret keys for me any more Message-ID: <20190112191247.GP17246@gnu.org> Hello, Does this reproduce for anyone else? dti at manas:~$ uname -a Linux manas 4.4.0-141-generic #167+8.0trisquel2 SMP Tue Jan 1 12:28:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux dti at manas:~$ gpg --version gpg (GnuPG) 2.2.12 libgcrypt 1.8.4 Copyright (C) 2018 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/dti/.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 dti at manas:~$ pinentry-tty --version pinentry-tty (pinentry) 1.1.0 Copyright (C) 2016 g10 Code GmbH License GPLv2+: GNU GPL version 2 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. dti at manas:~$ rm -fr h0 h1;mkdir h0 h1;chmod og= h0 h1;echo "pinentry-program $prefix/bin/pinentry-tty" >h0/gpg-agent.conf;cp h{0,1}/gpg-agent.conf;gpg --home h0 --list-keys;gpg --home h1 --list-keys gpg: keybox '/home/dti/h0/pubring.kbx' created gpg: /home/dti/h0/trustdb.gpg: trustdb created gpg: keybox '/home/dti/h1/pubring.kbx' created gpg: /home/dti/h1/trustdb.gpg: trustdb created dti at manas:~$ gpg --home h0 --quick-gen-key '???? ?????? ' About to create a key for: "???? ?????? " Continue? (Y/n) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. Please enter the passphrase to protect your new key Passphrase: Repeat: Warning: You have entered an insecure passphrase. A passphrase should be at least 8 characters long. A passphrase should contain at least 1 digit or special character. Take this one anyway Enter new passphrase [te]? t We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: key A81CA20F9A70E47B marked as ultimately trusted gpg: directory '/home/dti/h0/openpgp-revocs.d' created gpg: revocation certificate stored as '/home/dti/h0/openpgp-revocs.d/94DCB4A36F4EEDC1A68E95ABA81CA20F9A70E47B.rev' public and secret key created and signed. pub rsa2048 2019-01-12 [SC] [expires: 2021-01-11] 94DCB4A36F4EEDC1A68E95ABA81CA20F9A70E47B uid ???? ?????? sub rsa2048 2019-01-12 [E] dti at manas:~$ gpg --home h0 -a --export >pub.asc dti at manas:~$ gpg --home h0 -a --export-secret-key >sec.asc Please enter the passphrase to export the OpenPGP secret key: "???? ?????? " 2048-bit RSA key, ID A81CA20F9A70E47B, created 2019-01-12. Passphrase: dti at manas:~$ gpg --home h1 --import " imported gpg: Total number processed: 1 gpg: imported: 1 dti at manas:~$ gpg --home h1 --import " not changed gpg: key A81CA20F9A70E47B/A81CA20F9A70E47B: error sending to agent: Invalid IPC response gpg: error building skey array: Invalid IPC response gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From guru at unixarea.de Sun Jan 13 12:57:59 2019 From: guru at unixarea.de (Matthias Apitz) Date: Sun, 13 Jan 2019 12:57:59 +0100 Subject: OpenPGP card: reader with 2 USB connectors Message-ID: <20190113115758.GA7266@c720-r342378> Hello, I'm using an OpenPGP card in my FreeBSD laptop and my Ubuntu mobile phone (see photo http://www.unixarea.de/UbuntuPhone-GnuPG-card2.jpg ) The read is an Identiv uTrust 3512 SAM slot Token which works just fine (after solving an issue in the FreeBSD USB driver). To connect it to the mobile device one needs an small adapter or a cable. See the photo. All this is not very stable, esp. the connector in the mobile device. Are there any readers with two USB connectors like some USB memory sticks have? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub October, 7 -- The GDR was different: Peace instead of Bundeswehr and wars, Druschba instead of Nazis, to live instead of to survive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dkg at fifthhorseman.net Mon Jan 14 21:06:22 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 14 Jan 2019 15:06:22 -0500 Subject: [SOLVED] gpg doesn't import secret keys for me any more In-Reply-To: <20190112192501.GQ17246@gnu.org> References: <20190112191247.GP17246@gnu.org> <20190112192501.GQ17246@gnu.org> Message-ID: <87fttvhum9.fsf@fifthhorseman.net> On Sat 2019-01-12 14:25:02 -0500, Ineiev wrote: > On Sat, Jan 12, 2019 at 02:12:47PM -0500, Ineiev wrote: >> dti at manas:~$ gpg --home h1 --import > Sorry, this is what works: > > gpg --home h1 --import sec.asc to be clear, i think the issue that you were having is that both commands use pinentry-tty, but the former command has stdin coming from the redirected file, not the tty. fwiw, if you use --batch with --import, there will be no attempt to use pinentry, ever, which should make both commands work without complaint. hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ineiev at gnu.org Tue Jan 15 18:05:39 2019 From: ineiev at gnu.org (Ineiev) Date: Tue, 15 Jan 2019 12:05:39 -0500 Subject: [SOLVED] gpg doesn't import secret keys for me any more In-Reply-To: <87fttvhum9.fsf@fifthhorseman.net> References: <20190112191247.GP17246@gnu.org> <20190112192501.GQ17246@gnu.org> <87fttvhum9.fsf@fifthhorseman.net> Message-ID: <20190115170539.GF22949@gnu.org> On Mon, Jan 14, 2019 at 03:06:22PM -0500, Daniel Kahn Gillmor wrote: > On Sat 2019-01-12 14:25:02 -0500, Ineiev wrote: > > On Sat, Jan 12, 2019 at 02:12:47PM -0500, Ineiev wrote: > >> dti at manas:~$ gpg --home h1 --import > > > Sorry, this is what works: > > > > gpg --home h1 --import sec.asc > > to be clear, i think the issue that you were having is that both > commands use pinentry-tty, but the former command has stdin coming from > the redirected file, not the tty. Indeed, with pinentry-gtk-2, it works both ways. > fwiw, if you use --batch with --import, there will be no attempt to use > pinentry, ever, which should make both commands work without complaint. Curiously, when I --export-secret-keys with --batch, it still requests the password. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Digital signature URL: From dkg at fifthhorseman.net Tue Jan 15 21:53:01 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 15 Jan 2019 15:53:01 -0500 Subject: [SOLVED] gpg doesn't import secret keys for me any more In-Reply-To: <20190115170539.GF22949@gnu.org> References: <20190112191247.GP17246@gnu.org> <20190112192501.GQ17246@gnu.org> <87fttvhum9.fsf@fifthhorseman.net> <20190115170539.GF22949@gnu.org> Message-ID: <878szlhccy.fsf@fifthhorseman.net> On Tue 2019-01-15 12:05:39 -0500, Ineiev wrote: > On Mon, Jan 14, 2019 at 03:06:22PM -0500, Daniel Kahn Gillmor wrote: >> fwiw, if you use --batch with --import, there will be no attempt to use >> pinentry, ever, which should make both commands work without complaint. > > Curiously, when I --export-secret-keys with --batch, it still requests > the password. right, that's a requirement for most secret keys, because the secret keys need to be re-encrypted into the OpenPGP-style export format. The standard locked form of the secret keys stored in ~/.gnupg/private-keys-v1.d is not compatible directly with the OpenPGP secret key specification, so decryption and re-encryption is needed. otoh, --batch can work with --import because of a special case, where GnuPG is willing to (temporarily at least) just store the OpenPGP-wrapped secret key in private-keys-v1.d/ without converting it to the standard locked form. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From yannick.vidal.ors at gmail.com Thu Jan 17 10:13:01 2019 From: yannick.vidal.ors at gmail.com (yannick vidal) Date: Thu, 17 Jan 2019 10:13:01 +0100 Subject: Loss of data during encryption Message-ID: Hello everyone, To begin, please excuse my English wich is not as good anymore as it was. I come to you because I have a problem with GPG. I have for habit to encrypt the files I don't use regulary. But recently I needed one of these encrypted files. So I decrypted it and realized that the file didn't contained all the documents it should. These lost documents while encryptin / decrypting have never been found again. Have you ever had this kind of problem ? and if yes how can I fix it ? Thank you in advance for your replies. Yannick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry at seibercom.net Sat Jan 19 13:31:36 2019 From: jerry at seibercom.net (Jerry) Date: Sat, 19 Jan 2019 07:31:36 -0500 Subject: Changing order of ids in key Message-ID: <20190119073136.00005737@seibercom.net> Probably a dumb question, but I thought I would ask regardless. I created a key pair using my name and email address. I then added a new id to the key with the same name but a different email address. Now, when I send an email, the second id is the one displayed no matter what email address I was using when I sent the message. (I hope that this is making sense). Is there any way to switch the position of the ids in the key other than deleting the key and creating a new one? Would I be better off creating two separate keys? I would rather keep things simple if possible. Would creating a sub-key be the way to go? I am sort of lost here. Thanks! -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From dirk.gottschalk1980 at googlemail.com Sat Jan 19 14:24:21 2019 From: dirk.gottschalk1980 at googlemail.com (dirk.gottschalk1980 at googlemail.com) Date: Sat, 19 Jan 2019 14:24:21 +0100 Subject: Changing order of ids in key In-Reply-To: <20190119073136.00005737@seibercom.net> References: <20190119073136.00005737@seibercom.net> Message-ID: Hello Jerry. Am Samstag, den 19.01.2019, 07:31 -0500 schrieb Jerry: > Probably a dumb question, but I thought I would ask regardless. > > I created a key pair using my name and email address. I then added a > new id to the key with the same name but a different email address. > Now, when I send an email, the second id is the one displayed no > matter what email address I was using when I sent the message. (I > hope that this is making sense). Yes, I know what you mean. This behavior depends mostly on the MUA you are using. One UID is marked as primary. Some MUAs only display the primary UID, some display all and some pick the right one from the list. > Is there any way to switch the position of the ids in the key other > than deleting the key and creating a new one? Would I be better off > creating two separate keys? I would rather keep things simple if > possible. Would creating a sub-key be the way to go? I am sort of > lost here. You can set the other UID as primary. But you would have the same problem, when you send with the other address. You should test it with another MUA, what this displays. In my case (evolution), it checks the UIDs and gives an 'okay' if one of the addresses matches the sender. If I check for the signature key by clicking the symbol for the signature details, I see the output of GPG with the primary UID and the other UIDs as aliases, the same way, as gpg does on the command line. Hth, Dirk -- Dirk Gottschalk Paulusstrasse 6-8 52064 Aachen, Germany GPG: DDCB AF8E 0132 AA54 20AB B864 4081 0B18 1ED8 E838 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From jerry at seibercom.net Sat Jan 19 14:49:36 2019 From: jerry at seibercom.net (Jerry) Date: Sat, 19 Jan 2019 08:49:36 -0500 Subject: Changing order of ids in key In-Reply-To: References: <20190119073136.00005737@seibercom.net> Message-ID: <20190119084936.00002242@seibercom.net> On Sat, 19 Jan 2019 14:24:21 +0100, dirk1980ac via Gnupg-users stated: >Hello Jerry. > >Am Samstag, den 19.01.2019, 07:31 -0500 schrieb Jerry: >> Probably a dumb question, but I thought I would ask regardless. >> >> I created a key pair using my name and email address. I then added a >> new id to the key with the same name but a different email address. >> Now, when I send an email, the second id is the one displayed no >> matter what email address I was using when I sent the message. (I >> hope that this is making sense). > >Yes, I know what you mean. This behavior depends mostly on the MUA you >are using. One UID is marked as primary. Some MUAs only display the >primary UID, some display all and some pick the right one from the >list. > >> Is there any way to switch the position of the ids in the key other >> than deleting the key and creating a new one? Would I be better off >> creating two separate keys? I would rather keep things simple if >> possible. Would creating a sub-key be the way to go? I am sort of >> lost here. > >You can set the other UID as primary. But you would have the same >problem, when you send with the other address. You should test it with >another MUA, what this displays. In my case (evolution), it checks the >UIDs and gives an 'okay' if one of the addresses matches the sender. If >I check for the signature key by clicking the symbol for the signature >details, I see the output of GPG with the primary UID and the other >UIDs as aliases, the same way, as gpg does on the command line. > >Hth, >Dirk Thanks, that is pretty much what I thought too. I am using claws-mail. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From brad at fineby.me.uk Sat Jan 19 15:04:24 2019 From: brad at fineby.me.uk (Brad Rogers) Date: Sat, 19 Jan 2019 14:04:24 +0000 Subject: Changing order of ids in key In-Reply-To: <20190119084936.00002242@seibercom.net> References: <20190119073136.00005737@seibercom.net> <20190119084936.00002242@seibercom.net> Message-ID: <20190119140424.333fd49a@abydos.stargate.org.uk> On Sat, 19 Jan 2019 08:49:36 -0500 Jerry wrote: Hello Jerry, >Thanks, that is pretty much what I thought too. I am using claws-mail. CM can be set up to pick a GPG ID based on various criteria. In Account settings, look at Plugins/GPG, and make your choice there. Either; 1) default 2) based on email 3) user specified -- Regards _ / ) "The blindingly obvious is / _)rad never immediately apparent" Just coz they do it in the movies, doesn't mean to say that it's cool Keep It Clean - The Vibrators -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jerry at seibercom.net Sat Jan 19 17:09:12 2019 From: jerry at seibercom.net (Jerry) Date: Sat, 19 Jan 2019 11:09:12 -0500 Subject: showphoto Message-ID: <20190119110912.00004528@seibercom.net> Windows 10 Pro version 1809 gpg (GnuPG) 2.2.11 libgcrypt 1.8.4 I am not sure if this is an error on my part of if something else is wrong. I added a photo to one of my keys. That seemed to work fine. When i view the key, the image is listed as uid 3, which seems correct. The screen looks like this: gpg --edit-key gerard at seibercom.net gpg (GnuPG) 2.2.11; Copyright (C) 2018 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec rsa2048/3873063887DEC564 created: 2019-01-19 expires: never usage: SCA trust: ultimate validity: ultimate ssb rsa2048/881E39D62E6489CA created: 2019-01-19 expires: never usage: E [ultimate] (1). Gerard E. Seibert [ultimate] (2) Gerard E. Seibert [ultimate] (3) [jpeg image of size 88074] gpg> uid 3 sec rsa2048/3873063887DEC564 created: 2019-01-19 expires: never usage: SCA trust: ultimate validity: ultimate ssb rsa2048/881E39D62E6489CA created: 2019-01-19 expires: never usage: E [ultimate] (1). Gerard E. Seibert [ultimate] (2) Gerard E. Seibert [ultimate] (3)* [jpeg image of size 88074] gpg> showphoto Displaying jpeg photo ID of size 88074 for key 3873063887DEC564 (uid 3) After a few seconds, an error message pops up on the screen. C:\Users\Gerard\AppData\Local\Temp\gpg-62cno9\87DEC564.jpg contains an invalid path. I have tried several times with each uid and it always issues an error message. I was only experimenting with the idea of adding a photo, but I would still like to know why it is apparently not working correctly. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sat Jan 19 17:10:38 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 19 Jan 2019 17:10:38 +0100 Subject: Discrepancies in extracted photo-id images from dumps Message-ID: <20190119171038.5eff257e@300baud> Hi all, while inspired by the replies from dkg and Damien, in the "gpg > addphoto" thread, i tried to see if i can see how many images for photo-id's are in a whole key dump and what size the images have. I tried two methods. With GnuPG[1]i saved out 32088 jpeg images from all single dump files, while with method two , were i used jpegextrator[2], i obtained from a joined dump, done with cat, the following result: Extracted 86506 JPEG file(s) with 1236388001 bytes from 1 input file(s). Now i wonder why i have such high discrepancies in the numbers? I would very much appreciate if someone can explain this to me! [1]Method used with GnuPG: In gpg.conf i put: photo-viewer "cat > %K.%t" and then i used this one liner: for filename in ./*.pgp; do gpg --list-keys --list-options show-photo --keyring "${filename}"; done [2]https://www.digiater.nl/openvms/decus/vmslt02a/net/jpeg-extractor.html Regards Stefan From dkg at fifthhorseman.net Sat Jan 19 17:23:33 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 19 Jan 2019 11:23:33 -0500 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <20190119171038.5eff257e@300baud> References: <20190119171038.5eff257e@300baud> Message-ID: <871s588vlm.fsf@fifthhorseman.net> On Sat 2019-01-19 17:10:38 +0100, Stefan Claas wrote: > Now i wonder why i have such high discrepancies in the numbers? jpegextractor looks like it uses a simple heuristic to find jpegs. in particular (quoting from https://www.digiater.nl/openvms/decus/vmslt02a/net/jpeg-extractor.html): jpegextractor uses the fact that valid binary JPEG streams start with the byte sequence ff d8 ff and end with the byte sequence ff d9. It copies all of those streams to new files. As jpegextractor simply looks for the two sequences it does not have to know the format of the encapsulating file and thus works with all formats that embed JPEG streams. consider that a lot of OpenPGP key material is high-entropy -- public keys, cryptographic signatures, etc are all essentially random bytes. hand-wavy approximations follow, i'd be happy if someone wants to make them more rigorus. If we look at triplets of three consecutive octets, each such sequence should appear roughly once every 2^(8*3) == 16777216 triplets. and any specific pair of octets will appear roughly once every 2^(8*2) == 65536 pairs. So about every 16 million octets of high-entropy data, you'll find that starting "ff d8 ff" triplet, and much more frequently you'll find the ending "ff d9" pair. So assuming that the bulk of a 1GiB dump is high-entropy data *with no actual JPEGs in it at all*, you should expect to see jpegextractor have at least 1G/16M == 64 false positive matches. that doesn't quite add up to the number of extras that you're seeing from jpegextractor, but it suggests that there will be a large number of false positives by that mechanism at any rate. have you tried looking at the jpegs that jpegextractor produces? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sac at 300baud.de Sat Jan 19 17:47:42 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 19 Jan 2019 17:47:42 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <871s588vlm.fsf@fifthhorseman.net> References: <20190119171038.5eff257e@300baud> <871s588vlm.fsf@fifthhorseman.net> Message-ID: <20190119174742.0083ba9f@300baud> On Sat, 19 Jan 2019 11:23:33 -0500, Daniel Kahn Gillmor wrote: > On Sat 2019-01-19 17:10:38 +0100, Stefan Claas wrote: > > Now i wonder why i have such high discrepancies in the numbers? > > jpegextractor looks like it uses a simple heuristic to find jpegs. > > in particular (quoting from > https://www.digiater.nl/openvms/decus/vmslt02a/net/jpeg-extractor.html): > > jpegextractor uses the fact that valid binary JPEG streams start > with the byte sequence ff d8 ff and end with the byte sequence ff > d9. It copies all of those streams to new files. As jpegextractor > simply looks for the two sequences it does not have to know the > format of the encapsulating file and thus works with all formats > that embed JPEG streams. > > consider that a lot of OpenPGP key material is high-entropy -- public > keys, cryptographic signatures, etc are all essentially random bytes. > hand-wavy approximations follow, i'd be happy if someone wants to make > them more rigorus. > > If we look at triplets of three consecutive octets, each such sequence > should appear roughly once every 2^(8*3) == 16777216 triplets. and > any specific pair of octets will appear roughly once every 2^(8*2) == > 65536 pairs. > > > So about every 16 million octets of high-entropy data, you'll find that > starting "ff d8 ff" triplet, and much more frequently you'll find the > ending "ff d9" pair. > > So assuming that the bulk of a 1GiB dump is high-entropy data *with no > actual JPEGs in it at all*, you should expect to see jpegextractor have > at least 1G/16M == 64 false positive matches. Thank you very much for your explanation, much appreciated! > that doesn't quite add up to the number of extras that you're seeing > from jpegextractor, but it suggests that there will be a large number of > false positives by that mechanism at any rate. > > have you tried looking at the jpegs that jpegextractor produces? Yes, i scrolled through half of them and you are correct, there are some false positives in it. But not so much that they would explain the difference in the numbers. Could it maybe the case that my old iMac (ten years old) is to slow for this task with GnuPG and cat, so that my rig can't keep up parsing and then writing to disk etc.? To be sure i tried also only to parse a single dump (keydump-sks-0000) and it showed me also (with another tool) more images than GnuPG would have shown me. Regards Stefan From kloecker at kde.org Sat Jan 19 19:56:00 2019 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sat, 19 Jan 2019 19:56:00 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <20190119171038.5eff257e@300baud> References: <20190119171038.5eff257e@300baud> Message-ID: <40742069.b1zaMZMM4r@thufir> On Samstag, 19. Januar 2019 17:10:38 CET Stefan Claas wrote: > Method used with GnuPG: > > In gpg.conf i put: photo-viewer "cat > %K.%t" > > and then i used this one liner: > > for filename in ./*.pgp; do gpg --list-keys --list-options show-photo > --keyring "${filename}"; done This will result in at most 1 image per key because your fake photo-viewer overwrites photos for keys containing multiple photo-ids (%K.%t is identical for all photo-ids of a key). Using photo-viewer "cat > %K.%U.%t" instead should fix this. Regards, Ingo From sac at 300baud.de Sat Jan 19 21:37:33 2019 From: sac at 300baud.de (Stefan Claas) Date: Sat, 19 Jan 2019 21:37:33 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <40742069.b1zaMZMM4r@thufir> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> Message-ID: <20190119213733.79188dc4@300baud> On Sat, 19 Jan 2019 19:56:00 +0100, Ingo Kl?cker wrote: > On Samstag, 19. Januar 2019 17:10:38 CET Stefan Claas wrote: > > Method used with GnuPG: > > > > In gpg.conf i put: photo-viewer "cat > %K.%t" > > > > and then i used this one liner: > > > > for filename in ./*.pgp; do gpg --list-keys --list-options show-photo > > --keyring "${filename}"; done > > This will result in at most 1 image per key because your fake photo-viewer > overwrites photos for keys containing multiple photo-ids (%K.%t is identical > for all photo-ids of a key). Using > photo-viewer "cat > %K.%U.%t" > instead should fix this. Great tip, thanks a lot! Regards Stefan From sac at 300baud.de Sun Jan 20 13:38:14 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 20 Jan 2019 13:38:14 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <20190119213733.79188dc4@300baud> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> Message-ID: <20190120133814.067ed449@300baud> On Sat, 19 Jan 2019 21:37:33 +0100, Stefan Claas wrote: > On Sat, 19 Jan 2019 19:56:00 +0100, Ingo Kl?cker wrote: > > This will result in at most 1 image per key because your fake photo-viewer > > overwrites photos for keys containing multiple photo-ids (%K.%t is identical > > for all photo-ids of a key). Using > > photo-viewer "cat > %K.%U.%t" > > instead should fix this. > > Great tip, thanks a lot! So the new figures are 34390. The smallest image from my list has 177 bytes and is 60x60 pixels in size with 88,9 DPI and the largest image has 3624053 bytes and is 10208x14032 pixels large, 72 DPI. So taking the smallest image and looking at the %U part i am wondering what key data is encoded in this base32 string? 1234567890123456.abcdefghijklmnopqrstuvwxyz123456.jpg [redacted on request] Regards Stefan From peter at digitalbrains.com Sun Jan 20 15:22:08 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 20 Jan 2019 15:22:08 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <20190120133814.067ed449@300baud> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> Message-ID: On 20/01/2019 13:38, Stefan Claas wrote: > So taking the smallest image and looking at the %U part i am > wondering what key data is encoded in this base32 string? From the gpg man page: | --photo-viewer string | This is the command line that should be run to view a photo ID. | "%i" will be expanded to a filename containing the photo. "%I" | does the same, except the file will not be deleted once the | viewer exits. Other flags are "%k" for the key ID, "%K" for the | long key ID, "%f" for the key fingerprint, "%t" for the exten? | sion of the image type (e.g. "jpg"), "%T" for the MIME type of | the image (e.g. "image/jpeg"), "%v" for the single-character | calculated validity of the image being viewed (e.g. "f"), "%V" | for the calculated validity as a string (e.g. "full"), "%U" for | a base32 encoded hash of the user ID, and "%%" for an actual | percent sign. If neither %i or %I are present, then the photo | will be supplied to the viewer on standard input. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sun Jan 20 16:05:21 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 20 Jan 2019 16:05:21 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> Message-ID: <20190120160521.2759e821@300baud> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sun, 20 Jan 2019 15:22:08 +0100, Peter Lebbing wrote: > On 20/01/2019 13:38, Stefan Claas wrote: > > So taking the smallest image and looking at the %U part i am > > wondering what key data is encoded in this base32 string? > > From the gpg man page: > > | --photo-viewer string Thanks, but it is still unclear to me what content of the user id is taken. Here for example an old key from me: uid [ widerrufen] [jpeg image of size 4275] uid [ widerrufen] [jpeg image of size 8569] uid [ widerrufen] [jpeg image of size 30119] 9EF65F552361EA45.gby1yfy5g8uax1jymgyui9cwgn6ej6c7.jpg 9EF65F552361EA45.oqi6jos1z4zxncdq4o8emewtx44exyud.jpg 9EF65F552361EA45.sc3j6x8tiwrpebrqpgzhueoberk3358s.jpg If i base32 encode the string "jpeg image of size blah..." i get not the same results. If i base32 decode the strings i get binary output which i don't understand. Also when using xxd output and then running through a conversion i get output i can't interpret. Regards Stefan -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTsFcZEw1lI/LR+FYmaI04LDh8f6AUCXESOMgAKCRCaI04LDh8f 6Fk7APwJAgWvUsTMR8ihVJZLwe6DTKcx2GLQNwAyTb2TMNcpEQD9GzbbgJOMqEUy W+PbDRR6WLNdJhaAD7t/+oZykvEj7Q4= =iBTT -----END PGP SIGNATURE----- From peter at digitalbrains.com Sun Jan 20 17:07:23 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 20 Jan 2019 17:07:23 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <20190120160521.2759e821@300baud> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> <20190120160521.2759e821@300baud> Message-ID: <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> On 20/01/2019 16:05, Stefan Claas wrote: > Thanks, but it is still unclear to me what content of the user id > is taken. Here for example an old key from me: I had a quick scan through the source code, but couldn't find it. But it seems to me it's likely to be a hash of the User Attribute Packet (RFC 4880), which is an alternative form of a User ID. As such, it would be a unique identifier of the image in question. Does it really matter? > If i base32 decode the strings i get binary output which i don't > understand. It's 32 digits of base32, which makes it 32*2log(32) = 32*5 = 160 bits. So my guess is it's a raw hash and as such not something to be "understood" but high entropy data. Either a 160-bit hash (seems likely) or a truncated longer hash. Oh, note that the base32 is the one from RFC 6189, not the one from 3548. I saw that in the source. I played around a bit, but couldn't quickly home in on what the hash actually is. Maybe you have better luck (or more patience :-). Hashes are rather unforgiving of mistakes you make in the input to it :-). HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Sun Jan 20 17:34:28 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 20 Jan 2019 17:34:28 +0100 Subject: decryption failed: Bad session key In-Reply-To: References: <4416819b-8de9-a413-2c65-6a221bf47193@t-online.de> Message-ID: <63a92bbc-4413-87a8-40aa-dcb99a5291c2@digitalbrains.com> Hi Frank, On 03/01/2019 15:25, Frank Hrebabetzky wrote: > gpg: AES256 encrypted data > gpg: encrypted with 1 passphrase > gpg: decryption failed: Bad session key This is also the error message you get when you specify the wrong passphrase. Perhaps you mistyped the passphrase when encrypting it? That way, no matter how correct you type it when decrypting it... you get it. Other password problems can occur if you use special characters and your OS upgrade changed the handling of those in some way. If this is the case, you could try temporarily running an old backup of your previous OS. Or if that is not available, you could try a live CD, but that might be configured differently than your old OS with regard to special characters. Or you could try purpose-built tools that will try variations on the passphrase you supply brute-force. I don't have any experience with these, I just saw them mentioned now and then. The idea is that it can quickly try all kinds of typo mistakes and see if one of them gets you in. Actually brute-forcing a good passphrase with no specific clues should be impossible by design; the fact that you /almost/ know the correct passphrase is what gives you the edge. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sun Jan 20 17:54:06 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 20 Jan 2019 17:54:06 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> <20190120160521.2759e821@300baud> <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> Message-ID: <20190120175406.0afe1a84@300baud> On Sun, 20 Jan 2019 17:07:23 +0100, Peter Lebbing wrote: > On 20/01/2019 16:05, Stefan Claas wrote: > > Thanks, but it is still unclear to me what content of the user id > > is taken. Here for example an old key from me: > > I had a quick scan through the source code, but couldn't find it. But it > seems to me it's likely to be a hash of the User Attribute Packet (RFC > 4880), which is an alternative form of a User ID. As such, it would be a > unique identifier of the image in question. Does it really matter? Ah, o.k. Well, matter ... i only want to understand how this base32 data is created. :-) > > If i base32 decode the strings i get binary output which i don't > > understand. > > It's 32 digits of base32, which makes it 32*2log(32) = 32*5 = 160 bits. > So my guess is it's a raw hash and as such not something to be > "understood" but high entropy data. Either a 160-bit hash (seems likely) > or a truncated longer hash. Thanks, that makes then sense. > Oh, note that the base32 is the one from RFC 6189, not the one from > 3548. I saw that in the source. I played around a bit, but couldn't > quickly home in on what the hash actually is. Maybe you have better > luck (or more patience :-). Hashes are rather unforgiving of mistakes > you make in the input to it :-). O.k., i will takes a closer look and if i figured out the proper procedure i will post my findings. Regards Stefan From peter at digitalbrains.com Sun Jan 20 19:22:10 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Sun, 20 Jan 2019 19:22:10 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> <20190120160521.2759e821@300baud> <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> Message-ID: On 20/01/2019 17:07, Peter Lebbing wrote: > I had a quick scan through the source code, but couldn't find it. Oops! I was looking at ancient code instead of the current code. That's why I didn't find it. It's a RIPEMD-160 hash of the attribute that contains the JPEG image, but I'm not 100% clear on the exact byte sequence. But it just hashes a representation of the image. You can see the hash in it's hexadecimal form in: --8<---------------cut here---------------start------------->8--- $ gpg --with-colons -k KEYID [...] uat:n::::1497792746::91EC5F9C95BBB125AC85F65C06EF025712FCD036::1 2111: [...] --8<---------------cut here---------------end--------------->8--- The 8th field (91EC...) is the UID hash, and is equal to the base32 encoded string in the %U escape. Or as DETAILS.gz puts it: | *** Field 8 - Certificate S/N, UID hash, trust signature info | | Used for serial number in crt records. For UID and UAT records, | this is a hash of the user ID contents used to represent that | exact user ID. For trust signatures, this is the trust depth | separated by the trust value by a space. Furthermore, 'n' = validity, '1497792746' is creation time, '1 2111' is the number of attribute subpackets followed by the total attribute subpacket size. For more DETAILS, well, see DETAILS.gz. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Sun Jan 20 20:27:33 2019 From: sac at 300baud.de (Stefan Claas) Date: Sun, 20 Jan 2019 20:27:33 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> <20190120160521.2759e821@300baud> <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> Message-ID: <20190120202733.57030778@300baud> On Sun, 20 Jan 2019 19:22:10 +0100, Peter Lebbing wrote: > On 20/01/2019 17:07, Peter Lebbing wrote: > > I had a quick scan through the source code, but couldn't find it. > > Oops! I was looking at ancient code instead of the current code. That's > why I didn't find it. It's a RIPEMD-160 hash of the attribute that > contains the JPEG image, but I'm not 100% clear on the exact byte > sequence. But it just hashes a representation of the image. You can see > the hash in it's hexadecimal form in: > > --8<---------------cut here---------------start------------->8--- > $ gpg --with-colons -k KEYID > [...] > uat:n::::1497792746::91EC5F9C95BBB125AC85F65C06EF025712FCD036::1 2111: > [...] > --8<---------------cut here---------------end--------------->8--- > > The 8th field (91EC...) is the UID hash, and is equal to the base32 > encoded string in the %U escape. Thank you very much! I was able to hash a uid and it gave the proper hash value, same as in the gpg listing. However i am still unable to figure out the proper CLI sequence to get the same hash value and base32 value of a given uat. :-( I guess i must try harder! :-) Regards Stefan From amirkabir.2012 at gmail.com Sun Jan 20 10:56:50 2019 From: amirkabir.2012 at gmail.com (amir 2090) Date: Sun, 20 Jan 2019 13:26:50 +0330 Subject: Gnupg Message-ID: hi i am master student at university of tehran My field is Cryptography how can add a other cipher or Post-Quantum cryptography to GPG ?i change all code like rsa or dsa but i didnt see any change in GPG. thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From hreba at t-online.de Sun Jan 20 22:26:54 2019 From: hreba at t-online.de (Frank Hrebabetzky) Date: Sun, 20 Jan 2019 22:26:54 +0100 Subject: decryption failed: Bad session key In-Reply-To: <63a92bbc-4413-87a8-40aa-dcb99a5291c2@digitalbrains.com> References: <4416819b-8de9-a413-2c65-6a221bf47193@t-online.de> <63a92bbc-4413-87a8-40aa-dcb99a5291c2@digitalbrains.com> Message-ID: <5ab00735-ce88-f93d-e098-3bbca385833f@t-online.de> On 1/20/19 5:34 PM, Peter Lebbing wrote: > Hi Frank, > > On 03/01/2019 15:25, Frank Hrebabetzky wrote: >> gpg: AES256 encrypted data >> gpg: encrypted with 1 passphrase >> gpg: decryption failed: Bad session key > > This is also the error message you get when you specify the wrong > passphrase. Perhaps you mistyped the passphrase when encrypting it? That > way, no matter how correct you type it when decrypting it... you get it. Hi Peter, It took me quite some time until I got aware of this. A term like "key" or "encryption key" would have made it easier for me, the "session" was somewhat misleading. I wrote a simple program which generates the most likely variation of my passphrase, such as omitting single characters, changing upper/lower case and trying the neighbors of each character on the keyboard, but without success. So I probably will follow your hint about existing tools. Thanks a lot for your answer. -- Frank Hrebabetzky +49 / 9261 / 950 0565 From peter at digitalbrains.com Mon Jan 21 11:45:47 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 21 Jan 2019 11:45:47 +0100 Subject: decryption failed: Bad session key In-Reply-To: <5ab00735-ce88-f93d-e098-3bbca385833f@t-online.de> References: <4416819b-8de9-a413-2c65-6a221bf47193@t-online.de> <63a92bbc-4413-87a8-40aa-dcb99a5291c2@digitalbrains.com> <5ab00735-ce88-f93d-e098-3bbca385833f@t-online.de> Message-ID: On 20/01/2019 22:26, Frank Hrebabetzky wrote: > It took me quite some time until I got aware of this. A term like > "key" or "encryption key" would have made it easier for me, the > "session" was somewhat misleading. Yes, it is somewhat unfortunate. It is due to the mechanics of symmetrically-encrypted OpenPGP messages. The passphrase is used to decrypt the session key. A wrong passphrase just results in garbage on decryption. This garbage then leads to the "Bad session key" message. I wrote some stuff about possible changed handling of special characters. But that doesn't really match what you describe, you said it occurred only after you encrypted it with the new system. Unless you're mistaken, it's not likely to be a mismatch in handling special characters then. But it might give some insight if you try to encrypt a new file with the same passphrase: can you encrypt and succesfully decrypt a different file with the same passphrase? In that case, your OS would seem to handle that specific passphrase without problems. I'm not committing to a stronger assertion than "would seem to", though :-). Also, how do you invoke encryption and decryption? Maybe you're doing something that might explain it that I'm not aware of. If you can give the specific commands used (but with the filenames edited for privacy) it might lead to insights. Furthermore, the pinentry passphrase entry mechanism can interact with a keyring manager like GNOME Keyring and such. Maybe this is throwing a spanner into the works? Check your pinentry to see if it indicates some keyring manager is being used or something like that. Do you have a backup of the file before it went wrong, by the way? HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Mon Jan 21 12:46:14 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 21 Jan 2019 12:46:14 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <20190120202733.57030778@300baud> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> <20190120160521.2759e821@300baud> <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> <20190120202733.57030778@300baud> Message-ID: <20190121124614.1011a906@300baud> On Sun, 20 Jan 2019 20:27:33 +0100, Stefan Claas wrote: > On Sun, 20 Jan 2019 19:22:10 +0100, Peter Lebbing wrote: > > On 20/01/2019 17:07, Peter Lebbing wrote: > > > I had a quick scan through the source code, but couldn't find it. > > > > Oops! I was looking at ancient code instead of the current code. That's > > why I didn't find it. It's a RIPEMD-160 hash of the attribute that > > contains the JPEG image, but I'm not 100% clear on the exact byte > > sequence. But it just hashes a representation of the image. You can see > > the hash in it's hexadecimal form in: > > > > --8<---------------cut here---------------start------------->8--- > > $ gpg --with-colons -k KEYID > > [...] > > uat:n::::1497792746::91EC5F9C95BBB125AC85F65C06EF025712FCD036::1 2111: > > [...] > > --8<---------------cut here---------------end--------------->8--- > > > > The 8th field (91EC...) is the UID hash, and is equal to the base32 > > encoded string in the %U escape. > > Thank you very much! I was able to hash a uid and it gave the proper > hash value, same as in the gpg listing. However i am still unable to > figure out the proper CLI sequence to get the same hash value and > base32 value of a given uat. :-( I guess i must try harder! :-) Problem solved. :-) A very good Usenet friend explained it to me. To compute the hash of an image one has to add a 22bytes header to the image and then the hash will be properly computed. To get the proper base32 value i had to use Werner's zb32. Regards Stefan From peter at digitalbrains.com Mon Jan 21 14:21:53 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Mon, 21 Jan 2019 14:21:53 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <20190121124614.1011a906@300baud> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> <20190120160521.2759e821@300baud> <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> <20190120202733.57030778@300baud> <20190121124614.1011a906@300baud> Message-ID: <709031e9-c1ac-c682-153d-8148c6e9f97e@digitalbrains.com> Hello Stefan, On 21/01/2019 12:46, Stefan Claas wrote: > To compute the hash of an image one has to add a 22bytes header > to the image and then the hash will be properly computed. Since I didn't exactly follow the "22 bytes" part I looked at it one more time; I got curious. It turned out I accidentally cut off part of the inner header when I intended to strip the outer header, silly me. I went too quickly. What works for me is: - Take the User Attribute Packet - Strip off the header: 1 byte tag, and in my case, 2 bytes length (lengths are encoded on 1, 2 or 5 bytes) - Hash what's left So: $ gpg --export KEYID | gpgsplit Take a file named *.attribute Is the file smaller than 194 bytes? Wow, small attribute. Drop the first two bytes. Is the file between 194 and 8386 bytes inclusive? Drop the first three. If it's larger than 8386 bytes, drop the first six bytes. And hash the rest of the file. $ dd if=002839-017.attribute bs=1 skip=3 status=none|gpg --print-md RIPEMD160 For a real implementation, it's better to inspect the length field rather than reverse-compute its own length based on the file size. The 22 bytes added goes in reverse: 2 octets encoded length apparently, appropriate for the usual JPEG file smaller than a bit over 8 KiB, and then 01 10 00 01 01 00 00 00 00 00 00 00 00 00 00 00 00 for the header bits before the JPEG file. > To get the proper base32 value i had to use Werner's zb32. Python: --8<---------------cut here---------------start------------->8--- b32s = "ybndrfg8ejkmcpqxot1uwisza345h769" def b32enc(i): s = "" while i: s = b32s[i & 0x1f] + s i >>= 5 return s def b32dec(s): out = 0 for c in s: out = (out << 5) + b32s.index(c) return out --8<---------------cut here---------------end--------------->8--- If the encoded string is shorter than expected, prepend y's :-). It's the simplest code that sort-of works. There might be more issues, it's really bare-bones. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Mon Jan 21 15:10:21 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 21 Jan 2019 15:10:21 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <709031e9-c1ac-c682-153d-8148c6e9f97e@digitalbrains.com> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> <20190119213733.79188dc4@300baud> <20190120133814.067ed449@300baud> <20190120160521.2759e821@300baud> <67510fb4-7d44-a0ed-167b-c6844050689b@digitalbrains.com> <20190120202733.57030778@300baud> <20190121124614.1011a906@300baud> <709031e9-c1ac-c682-153d-8148c6e9f97e@digitalbrains.com> Message-ID: <20190121151021.5b6ebe12@300baud> On Mon, 21 Jan 2019 14:21:53 +0100, Peter Lebbing wrote: Hi Peter, > - Take the User Attribute Packet > - Strip off the header: 1 byte tag, and in my case, 2 bytes length > (lengths are encoded on 1, 2 or 5 bytes) > - Hash what's left > > So: > > $ gpg --export KEYID | gpgsplit > > Take a file named *.attribute > > Is the file smaller than 194 bytes? Wow, small attribute. Drop the first > two bytes. > > Is the file between 194 and 8386 bytes inclusive? Drop the first three. > > If it's larger than 8386 bytes, drop the first six bytes. > > And hash the rest of the file. > > $ dd if=002839-017.attribute bs=1 skip=3 status=none|gpg --print-md RIPEMD160 > > For a real implementation, it's better to inspect the length field > rather than reverse-compute its own length based on the file size. This is very interesting, thanks a lot! So, many things can be explored when using GnuPG ... :-) > Python: > > --8<---------------cut here---------------start------------->8--- > b32s = "ybndrfg8ejkmcpqxot1uwisza345h769" > def b32enc(i): > s = "" > while i: > s = b32s[i & 0x1f] + s > i >>= 5 > return s > > def b32dec(s): > out = 0 > for c in s: > out = (out << 5) + b32s.index(c) > return out > --8<---------------cut here---------------end--------------->8--- > > If the encoded string is shorter than expected, prepend y's :-). It's > the simplest code that sort-of works. There might be more issues, it's > really bare-bones. Nice! Regards Stefan From justina at colmena.biz Mon Jan 21 18:29:35 2019 From: justina at colmena.biz (justina colmena) Date: Mon, 21 Jan 2019 08:29:35 -0900 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: <40742069.b1zaMZMM4r@thufir> References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> Message-ID: On January 19, 2019 9:56:00 AM AKST, "Ingo Kl?cker" wrote: >On Samstag, 19. Januar 2019 17:10:38 CET Stefan Claas wrote: >> Method used with GnuPG: >> >> In gpg.conf i put: photo-viewer "cat > %K.%t" >> >> and then i used this one liner: >> >> for filename in ./*.pgp; do gpg --list-keys --list-options show-photo >> --keyring "${filename}"; done > >This will result in at most 1 image per key because your fake >photo-viewer >overwrites photos for keys containing multiple photo-ids (%K.%t is >identical >for all photo-ids of a key). Using >photo-viewer "cat > %K.%U.%t" >instead should fix this. Yes, I agree it's about time somebody clocked the $#!+ out of some of these EFF f*ckers and called them out on their bull crap, because you're not one of them, as you have so excused yourself. Other than that, well, all we ever get from Gnu/EFF is, "Don't talk to the cops!" And come to find out they have already snitched on us, grossly misrepresented us to the aforementioned cops, and cooked up false police reports against us that go on permanent record without the due process of law, and without any communication to us of our loss of rights and representation. We would like to work with the cops and educate them on due process and civil rights, but the truth is, you're either a criminal or a snitch the minute you talk to a cop, they punish you just the same either way, all the dishonest lawyers, corrupt judges, and stacked juries on their side, and if you haven't "lost your gun rights" already, they just take you in for a mental evaluation and have a doctor declare you irrevocably incompetent to possess a firearm for the rest of your life of cop-calling victimhood. And it's actually ten times worse than that, because when you try to find employment or housing with that on your record, your potential employer sees an unfounded and unproven, but indefeasible accusation of murder on your permanent record. Add to that the off-duty *armed* lynch mob from the local PD, the local NSA neighborhood crime watch with the moms in tennis shoes screaming ch!ld pr0nogr4phy, and we have a full-blown East German DDR Stasi in the USA. Somehow I don't believe the situation in Europe is much if at all better, because that political garbage is all coming from somewhere in the EU. You've got email problems at KDE. X-Authenticated-User? Is KDE high on drugs to pimp out your private email address like that to the whole mailing list? Or is KDE (= "K" DEutscheland) the German equivalent of KKK in the United States? Right, right, right. It's all love and free software and it runs on Ubuntu in Africa, same as everywhere else. >On Samstag, 19. Januar 2019 17:10:38 CET Stefan Claas wrote: Look. I realize it's automatically generated by your email client "reply" function, but is that supposed to be an English-language sentence with a German-language locale time-zone date-stamp mashed into the middle of it? Some of you Germans drink so much beer you can't tell what time the sun is supposed to come up in the morning. Everything is either proprietary and locked down, or too broken and crippled to be usable, and there's no viable free software left anywhere, because of all the bull crap and the H1-B labor Mob from the East Indies. Microsoft is behind this, I'm telling you. They bought out GitHub. The Halloween Documents, the SCO fiasco, the whole Groklaw.net saga, nobody ever got fired for buying Apple, IBM, AT&T, and Cisco, either, and it's all coming back, closed source, slammed shut right in our faces. How can people be so insufferably rude? -- Una Milicia bien regulada, estando necesaria a la seguridad de un Estado libre, el derecho del pueblo de tener y de portar Armas, no ser? infringido. https://www.colmena.biz/~justina/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 683 bytes Desc: not available URL: From kloecker at kde.org Mon Jan 21 19:33:33 2019 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 21 Jan 2019 19:33:33 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> Message-ID: <10985674.v8H6H9g8vK@thufir> On Montag, 21. Januar 2019 18:29:35 CET justina colmena via Gnupg-users wrote: [snip] > You've got email problems at KDE. > > X-Authenticated-User? This header has been added by my email provider, not by KMail. Regards, Ingo From sac at 300baud.de Mon Jan 21 20:04:15 2019 From: sac at 300baud.de (Stefan Claas) Date: Mon, 21 Jan 2019 20:04:15 +0100 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> Message-ID: <20190121200402.3963e1f4@300baud> On Mon, 21 Jan 2019 08:29:35 -0900, justina colmena via Gnupg-users wrote: [flush] Regards Stefan From andrewg at andrewg.com Mon Jan 21 19:05:11 2019 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 21 Jan 2019 18:05:11 +0000 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> Message-ID: <73125086-DE6F-48EF-B3F6-6894A80F08C3@andrewg.com> > On 21 Jan 2019, at 17:29, justina colmena via Gnupg-users wrote: > > How can people be so insufferably rude? O_o A From dkg at fifthhorseman.net Mon Jan 21 19:21:35 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 21 Jan 2019 13:21:35 -0500 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> Message-ID: <878szd7txs.fsf@fifthhorseman.net> On Mon 2019-01-21 08:29:35 -0900, justina colmena via Gnupg-users wrote: > How can people be so insufferably rude? How indeed. Justina, please keep discussion on-topic and friendly for this mailing list. Too many of your posts to the list are full of invective, threating assault, or incoherently off-topic, none of which is appropriate here. Let's keep the list welcoming and relevant to users of GnuPG. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From angel at pgp.16bits.net Mon Jan 21 23:09:10 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 21 Jan 2019 23:09:10 +0100 Subject: showphoto In-Reply-To: <20190119110912.00004528@seibercom.net> References: <20190119110912.00004528@seibercom.net> Message-ID: <1548108550.1009.3.camel@16bits.net> On 2019-01-19 at 11:09 -0500, Jerry wrote: > gpg> showphoto > Displaying jpeg photo ID of size 88074 for key 3873063887DEC564 (uid 3) > > After a few seconds, an error message pops up on the screen. > > C:\Users\Gerard\AppData\Local\Temp\gpg-62cno9\87DEC564.jpg contains an > invalid path. > > I have tried several times with each uid and it always issues an error > message. > > I was only experimenting with the idea of adding a photo, but I would > still like to know why it is apparently not working correctly. showphoto launches an external program to view the photo. Since you are using Windows, the path has backslashes, that the receiving program seems to be treating as escape characters rather than a path (plus, the default of xloadimage is unlikely to be available there) Changing to a different viewer would probably fix it. And it will likely work flawless if you tried the same steps from a *nix machine. Best regards From jerry at seibercom.net Mon Jan 21 23:28:51 2019 From: jerry at seibercom.net (Jerry) Date: Mon, 21 Jan 2019 17:28:51 -0500 Subject: showphoto In-Reply-To: <1548108550.1009.3.camel@16bits.net> References: <20190119110912.00004528@seibercom.net> <1548108550.1009.3.camel@16bits.net> Message-ID: <20190121172851.00002aaf@seibercom.net> On Mon, 21 Jan 2019 23:09:10 +0100, ?ngel stated: >On 2019-01-19 at 11:09 -0500, Jerry wrote: >> gpg> showphoto >> Displaying jpeg photo ID of size 88074 for key 3873063887DEC564 (uid >> 3) >> >> After a few seconds, an error message pops up on the screen. >> >> C:\Users\Gerard\AppData\Local\Temp\gpg-62cno9\87DEC564.jpg contains >> an invalid path. >> >> I have tried several times with each uid and it always issues an >> error message. >> >> I was only experimenting with the idea of adding a photo, but I would >> still like to know why it is apparently not working correctly. > >showphoto launches an external program to view the photo. Since you are >using Windows, the path has backslashes, that the receiving program >seems to be treating as escape characters rather than a path (plus, the >default of xloadimage is unlikely to be available there) > >Changing to a different viewer would probably fix it. And it will >likely work flawless if you tried the same steps from a *nix machine. This sounds more like a bug to me. I'll probably gather all the info I can and submit it and see what happens. -- Jerry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From angel at pgp.16bits.net Mon Jan 21 23:33:43 2019 From: angel at pgp.16bits.net (=?ISO-8859-1?Q?=C1ngel?=) Date: Mon, 21 Jan 2019 23:33:43 +0100 Subject: NIST 800-57 compatible unattended encryption? In-Reply-To: <20190108031541.6f4ziukdpccmcejg@raf.org> References: <20190102050203.7psom2s5hqvphxgp@raf.org> <20190102094747.e5lhhj4rndllufos@aurora.local.incenp.org> <5504353a-3347-502c-590f-31daf9bd0d7f@metacode.biz> <20190108031541.6f4ziukdpccmcejg@raf.org> Message-ID: <1548110023.1009.12.camel@16bits.net> You are missing another point, which is that -in addition to the gpg.conf client preferences- the keys you are encrypting to have preferences, too. In fact, it is noted in the SE answer you linked: > Per default, GnuPG will read the recipient's algorithm preferences and > take the first algorithm in that list it supports (in other words, it > takes the most-preferred supported algorithm the recipient asks for). > https://security.stackexchange.com/questions/86305/what-is-the-default-cipher-algorithm-for-gnupg/86311#86311 The default of Cast5/AES-128 is for the case where you know nothing (in fact, the recipient might not even be able to decrypt it if you used an algorithm it doesn't support, so it can go to eg. 3DES. All keys you are using today should have been generated by non-ancient software and, as such, have this preference set, though) Kind regards From phill at thesusis.net Mon Jan 21 21:10:20 2019 From: phill at thesusis.net (Phillip Susi) Date: Mon, 21 Jan 2019 15:10:20 -0500 Subject: Discrepancies in extracted photo-id images from dumps In-Reply-To: References: <20190119171038.5eff257e@300baud> <40742069.b1zaMZMM4r@thufir> Message-ID: Are you on some sort of drugs? I can not find anything that makes any sense or has anything at all to do with the previous messages in this thread you quoted. I see nothing here but the ramblings of a nutter. What the heck is all of this nonsense and what does it have to do with this thread? On 1/21/2019 12:29 PM, justina colmena via Gnupg-users wrote: > On January 19, 2019 9:56:00 AM AKST, "Ingo Kl?cker" wrote: >> On Samstag, 19. Januar 2019 17:10:38 CET Stefan Claas wrote: >>> Method used with GnuPG: >>> >>> In gpg.conf i put: photo-viewer "cat > %K.%t" >>> >>> and then i used this one liner: >>> >>> for filename in ./*.pgp; do gpg --list-keys --list-options show-photo >>> --keyring "${filename}"; done >> >> This will result in at most 1 image per key because your fake >> photo-viewer >> overwrites photos for keys containing multiple photo-ids (%K.%t is >> identical >> for all photo-ids of a key). Using >> photo-viewer "cat > %K.%U.%t" >> instead should fix this. > > Yes, I agree it's about time somebody clocked the $#!+ out of some of these EFF f*ckers and called them out on their bull crap, because you're not one of them, as you have so excused yourself. > > Other than that, well, all we ever get from Gnu/EFF is, "Don't talk to the cops!" And come to find out they have already snitched on us, grossly misrepresented us to the aforementioned cops, and cooked up false police reports against us that go on permanent record without the due process of law, and without any communication to us of our loss of rights and representation. > > We would like to work with the cops and educate them on due process and civil rights, but the truth is, you're either a criminal or a snitch the minute you talk to a cop, they punish you just the same either way, all the dishonest lawyers, corrupt judges, and stacked juries on their side, and if you haven't "lost your gun rights" already, they just take you in for a mental evaluation and have a doctor declare you irrevocably incompetent to possess a firearm for the rest of your life of cop-calling victimhood. > > And it's actually ten times worse than that, because when you try to find employment or housing with that on your record, your potential employer sees an unfounded and unproven, but indefeasible accusation of murder on your permanent record. > > Add to that the off-duty *armed* lynch mob from the local PD, the local NSA neighborhood crime watch with the moms in tennis shoes screaming ch!ld pr0nogr4phy, and we have a full-blown East German DDR Stasi in the USA. Somehow I don't believe the situation in Europe is much if at all better, because that political garbage is all coming from somewhere in the EU. > > You've got email problems at KDE. > > X-Authenticated-User? Is KDE high on drugs to pimp out your private email address like that to the whole mailing list? Or is KDE (= "K" DEutscheland) the German equivalent of KKK in the United States? Right, right, right. It's all love and free software and it runs on Ubuntu in Africa, same as everywhere else. > >> On Samstag, 19. Januar 2019 17:10:38 CET Stefan Claas wrote: > Look. I realize it's automatically generated by your email client "reply" function, but is that supposed to be an English-language sentence with a German-language locale time-zone date-stamp mashed into the middle of it? Some of you Germans drink so much beer you can't tell what time the sun is supposed to come up in the morning. > > Everything is either proprietary and locked down, or too broken and crippled to be usable, and there's no viable free software left anywhere, because of all the bull crap and the H1-B labor Mob from the East Indies. Microsoft is behind this, I'm telling you. They bought out GitHub. The Halloween Documents, the SCO fiasco, the whole Groklaw.net saga, nobody ever got fired for buying Apple, IBM, AT&T, and Cisco, either, and it's all coming back, closed source, slammed shut right in our faces. > > How can people be so insufferably rude? > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users > From m.vetsch at infotech.li Thu Jan 24 11:45:47 2019 From: m.vetsch at infotech.li (Markus Vetsch) Date: Thu, 24 Jan 2019 10:45:47 +0000 Subject: Calling GnuPG ME library from managed .NET Message-ID: Hello, we have integrated GnuPG via command line interface into our Windows client & server C#.NET application. We are aware that the recommended way to interact with GnuPG is the library GnuPG ME. That's why we would like to switch for better stability and robustness our C#.NET code base to the usage of GnuPG ME API, as we are facing several disturbing issues in a production environment caused by the command line interface calls and the fact that we don't have full control of the called processes. Our crypto system requires support for both OpenPGP and CMS (S/MIME). The GnuPG version in use on our side is 2.1.1.18. Our research in this topic has detected that there already exists an OpenSource C#.NET project wrapping the native C calls from libgpgme-xx.dll. However, the development state of this project indicates that the native calls (method signatures and corresponding data structres) target version 1.1.6 of the libgpgme-xx.dll. https://github.com/wget/gpgme-sharp For us as non C experts, it looks like an awful lot of work to extend this library for our purpose to match a newer target version of GnuPG ME. Our prerequisite is, that our software is developed for commercial use and thus our time/budget resources are strictly limited. Therefore, we have now the following questions: 1. Are you aware of any other commercial / OpenSource projects in .NET that could support us? 2. Which version of libgpgme-xx.dll is compatible to version 2.1.1.18 of GnuPG tool suite? Is this version 1.9.0 or version 1.7.0 according to the release news on page https://www.gnupg.org/news.html? 3. What are the preqrequisites (paths) to build C++ sources of GnuPG ME in Visual Studio for Windows 32 bit platforms? How do we manage to build the sources otherwise on command line? We appreciate any feedback in this matter. Best regards, Markus ------------------------------------------------------------ Markus Vetsch Projektleiter Software-Entwicklung Im alten Riet 125, 9494 Schaan, Liechtenstein Mailto:m.vetsch at infotech.li,? Web: www.infotech.li Phone: +423 380 00 00, direct: +423 380 00 04, Fax: +423 380 00 05 ------------------------------------------------------------ Unsere Produkte: TimeSafe Leistungserfassung (Leistungserfassung und Fakturierung f?r Dienstleister) TimeSafe Zeiterfassung (Pr?senzzeiterfassung mit biometrischer Identifikation) Weitere Infos unter: www.timesafe.ch Oder auf Facebook From m.vetsch at infotech.li Thu Jan 24 14:58:32 2019 From: m.vetsch at infotech.li (Markus Vetsch) Date: Thu, 24 Jan 2019 13:58:32 +0000 Subject: AW: Calling GnuPG ME library from managed .NET In-Reply-To: References: Message-ID: Hi Jeff, > Hope my answer has been at least somewhat helpful, altho I'm sure it's not quite the answer you were hoping for :( I really appreciate your immediate feedback. I was prepared to an answer like that and it confirms my perception of the challenge to integrate GnuPG, as my reapeated research in this area didn't look too promising. I'm not too much disappointed, though. ;-) In this respect your answer was already quite helpful. > I ended up having to use the BouncyCastle crypto library instead (that may be what you guys are already using?). We already use the BouncyCastle API in other projects, but are for a certain reason a bit cautious to just replace GnuPG in this specific project due to certain prerequisites beyond our area of influence. I'm pretty sure that BouncyCastle supports all the stuff we'd actually require (sign, encrypt, verify, decrypt files) based on asymmetric algorithms. The reason, why we're so keen on GnuPG is that a European Union project for multi-national secure file exchange prescribes GnuPG as de facto solution to use by all involved parties. The only setup that is officially being supported by the central project organization is GnuPG, but the technical support is quite poor though ... Since we are not crypto specialists and neither is the central organisation things get complicated. We came across to build up a software system to get rid of all the manual processing via shell scripts and so on. The crypto systems OpenPGP and S/MIME are both in use. The keystores in use are the GnuPG proprietary ones, whereas the keys / certificates in use could of course be migrated to a format such that they're stored in the OS certificate store. Basically our command line interface implementation works more or less, but there are some drawbacks which lead to continuous support that imho is not necessary to this extent. The calls of gpg-agent, gpg, gpgsm ... on command line are a huge black box we can not fully control. > That said, MimeKit can read exported keyrings from gpg 2.1.x. I'm not sure if that is at all helpful to you or not... Unfortunately, this is only part of the functionality we need. We keep on researching. Thx anyway for your support. Markus From fejj at gnome.org Thu Jan 24 14:27:02 2019 From: fejj at gnome.org (Jeffrey Stedfast) Date: Thu, 24 Jan 2019 08:27:02 -0500 Subject: Calling GnuPG ME library from managed .NET In-Reply-To: References: Message-ID: Hi Markus, On 1/24/2019 5:45 AM, Markus Vetsch wrote: > Hello, > > we have integrated GnuPG via command line interface into our Windows client & server C#.NET application. > We are aware that the recommended way to interact with GnuPG is the library GnuPG ME. > That's why we would like to switch for better stability and robustness our C#.NET code base to the usage of GnuPG ME API, as we are facing several disturbing issues in a production environment caused by the command line interface calls and the fact that we don't have full control of the called processes. > > Our crypto system requires support for both OpenPGP and CMS (S/MIME). > The GnuPG version in use on our side is 2.1.1.18. > > Our research in this topic has detected that there already exists an OpenSource C#.NET project wrapping the native C calls from libgpgme-xx.dll. > However, the development state of this project indicates that the native calls (method signatures and corresponding data structres) target version 1.1.6 of the libgpgme-xx.dll. > > https://github.com/wget/gpgme-sharp I came across this project (altho not this particular fork) in my search a few years ago myself and it seemed to be a dead project. Looks like this past year they changed the license from LGPL to MIT. The main problem I had was that this library was tied to a 32-bit version of libgpgme.dll which didn't fit my needs seeing as how I was working on an open source S/MIME & PGP/MIME library: https://github.com/jstedfast/MimeKit I ended up having to use the BouncyCastle crypto library instead (that may be what you guys are already using?). At the time, GnuPG 2.0.x was what all the distros were shipping and was what most Mac and Windows users were also using, so I was able to implement code to load the user's gpg.conf and keyrings. Unfortunately, the file format changed with GnuPG 2.1.x and I have not yet been able to figure out how to load the user's keyrings anymore. That said, MimeKit can read exported keyrings from gpg 2.1.x. I'm not sure if that is at all helpful to you or not... > > For us as non C experts, it looks like an awful lot of work to extend this library for our purpose to match a newer target version of GnuPG ME. > Our prerequisite is, that our software is developed for commercial use and thus our time/budget resources are strictly limited. > > Therefore, we have now the following questions: > > 1. Are you aware of any other commercial / OpenSource projects in .NET that could support us? As I mentioned above, MimeKit is probably your only Open Source alternative (but, as I noted above, my library does not use GnuPG directly). As far as commercial goes, you could look at Rebex (https://www.rebex.net/secure-mail.net/features/s-mime.aspx) and IP*Works (https://www.nsoftware.com/ipworks/smime/), although they have their own crypto libraries and do not make any use of GnuPG as far as I'm aware. > 2. Which version of libgpgme-xx.dll is compatible to version 2.1.1.18 of GnuPG tool suite? Is this version 1.9.0 or version 1.7.0 according to the release news on page https://www.gnupg.org/news.html? I'm pretty sure that 1.7 is compat (my https://github.com/jstedfast/gmime c-library depends only on gpgme 1.7 and works with gnupg 2.1.x). > 3. What are the preqrequisites (paths) to build C++ sources of GnuPG ME in Visual Studio for Windows 32 bit platforms? How do we manage to build the sources otherwise on command line? This is something I can't answer because I've never built GPGME on Windows. Hope my answer has been at least somewhat helpful, altho I'm sure it's not quite the answer you were hoping for :( Jeff From sac at 300baud.de Thu Jan 24 16:51:18 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 24 Jan 2019 16:51:18 +0100 Subject: Advancements in CGI makes video conferences for key signing obsolete imho Message-ID: <20190124165118.4cf76078@300baud> Hi all, while i have studied key signing policies in the past, where some folks suggest also video conferencing, i would say this is no longer a good option. Real time computer graphics and motion capture is nowadays affordable and it should be "easy" in the hand of talented artists to to fake identities easily in the future. To see what i am talking about, please check this video: Regards Stefan From sac at 300baud.de Thu Jan 24 18:14:29 2019 From: sac at 300baud.de (Stefan Claas) Date: Thu, 24 Jan 2019 18:14:29 +0100 Subject: Advancements in CGI makes video conferences for key signing obsolete imho In-Reply-To: <20190124165118.4cf76078@300baud> References: <20190124165118.4cf76078@300baud> Message-ID: <20190124181429.2f2cbe0d@300baud> On Thu, 24 Jan 2019 16:51:18 +0100, Stefan Claas wrote: > To see what i am talking about, please check this video: > > and a second one: Regards Stefan From wk at gnupg.org Thu Jan 24 21:03:46 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 24 Jan 2019 21:03:46 +0100 Subject: Calling GnuPG ME library from managed .NET In-Reply-To: (Markus Vetsch's message of "Thu, 24 Jan 2019 10:45:47 +0000") References: Message-ID: <87r2d1bz6l.fsf@wheatstone.g10code.de> On Thu, 24 Jan 2019 10:45, m.vetsch at infotech.li said: > 2. Which version of libgpgme-xx.dll is compatible to version 2.1.1.18 > of GnuPG tool suite? Is this version 1.9.0 or version 1.7.0 according > to the release news on page https://www.gnupg.org/news.html? The name of the DLL only reflects the compatible ABI version (SO number in Unix parlance), it has not changed for a long time. All GPGME versions since 0.4.x (from 2003) are all upward compatible. For security reasons you should always use the latest vesion of GPGME and never consider to use use an old version (1.1.6 is 11 years old). > 3. What are the preqrequisites (paths) to build C++ sources of GnuPG > ME in Visual Studio for Windows 32 bit platforms? How do we manage to > build the sources otherwise on command line? GnuPG installer for windows comes with a binary version of gpgme and all development files to use it. Take care to use gpgme_free and not a plain free when you release data malloced by gpgme. You may also want to look into gpgme-json tool, which provides a JSON based interface to GPGME and thus GnuPG. It is currently used for native messaging with browsers, but can easily be used for other purposes too; if you have a need for extensions, that can be done easily. 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 pkk at spth.de Wed Jan 30 13:20:01 2019 From: pkk at spth.de (Philipp Klaus Krause) Date: Wed, 30 Jan 2019 13:20:01 +0100 Subject: [OT] Where can I find some papers to read on mail (and envelope) security? Message-ID: There has been plenty of research on email security and the need for encryption is well-known. However, I wonder if there has been any research on mail security. Of course, one could just put a GPG-encrypted letter in an ordinary envelope, but there are more common measures that are meant to give some additional security over the standard mail. I wonder how well those work. Are there any good textbooks, etc? There are a few aspects I can think of (but there is probably more): * Patterns printed on the inside of envelopers. These are meant gainst the use of light to read the contents of an unopened enveloper. How strong are these in the face of image recognition? Did someone study such patters? * Tamper-proof enevelopes, meant to make it hard to open an envelope unnoticed. How well do these work? Does it even make snsne to put much effort into them, as an attacker could use a new envelope (though there might be some difficulties involved to get or fake the right postmark)? * There seems to be some literature on the security of wax seals (e.g. "Licet ad regimen", published in 1198 - does anyone know of a German, French or English translation). Philipp From sac at 300baud.de Wed Jan 30 16:33:27 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 30 Jan 2019 16:33:27 +0100 Subject: [OT] Where can I find some papers to read on mail (and envelope) security? In-Reply-To: References: Message-ID: <20190130163327.3c8a9135@300baud.de> On Wed, 30 Jan 2019 13:20:01 +0100, Philipp Klaus Krause wrote: > There has been plenty of research on email security and the need for > encryption is well-known. > > However, I wonder if there has been any research on mail security. Of > course, one could just put a GPG-encrypted letter in an ordinary > envelope, but there are more common measures that are meant to give some > additional security over the standard mail. I wonder how well those work. > > Are there any good textbooks, etc? Interesting topic, which i am interested in as well. I started, as German citizen, to use also epost Brief and De-Mail a while ago, when communicating sometimes with friends, because i like those paid services much more than the classical email PGP combo. (Does anyone know why GnuPG does not support stealth mode, like old versions of PGP had, to make it harder for procmail?) > There are a few aspects I can think of (but there is probably more): > * Patterns printed on the inside of envelopers. These are meant gainst > the use of light to read the contents of an unopened enveloper. How > strong are these in the face of image recognition? Did someone study > such patters? Maybe an additional layer of household aluminium foil should work fine. > * Tamper-proof enevelopes, meant to make it hard to open an envelope > unnoticed. How well do these work? Does it even make snsne to put much > effort into them, as an attacker could use a new envelope (though there > might be some difficulties involved to get or fake the right postmark)? > * There seems to be some literature on the security of wax seals (e.g. > "Licet ad regimen", published in 1198 - does anyone know of a German, > French or English translation). Services which do such things may have international stamps in stock, just in case ... About traditional wax seals, i could imagine a silicone mold would be enough to fake such a seal successfully. But now i have a question, if you don't mind. Prior sending an encrypted letter, have you thought about a proper ASCII armor also, because when i did tests in the past i found only codegroup suitable, but even FOSS OCR software can not detect hundert percent codegroup letters. Maybe one needs to use a special font ... https://www.fourmilab.ch/codegroup/ Regards Stefan From peter at digitalbrains.com Wed Jan 30 20:22:35 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Jan 2019 20:22:35 +0100 Subject: [OT] Where can I find some papers to read on mail (and envelope) security? In-Reply-To: <20190130163327.3c8a9135@300baud.de> References: <20190130163327.3c8a9135@300baud.de> Message-ID: On 30/01/2019 16:33, Stefan Claas wrote: > Maybe an additional layer of household aluminium foil should work fine. The sender could use their hat for that ;-P (SCNR) > Maybe one needs to use a special font ... Oh, most definitely. In this day and age, I'd probably look at a two-dimensional barcode instead. Supposing I would even consider sending OpenPGP data on paper :-). Other than key backups, where I'd opt for the program paperkey rather than barcodes. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jan 30 20:44:07 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 30 Jan 2019 20:44:07 +0100 Subject: [OT] Where can I find some papers to read on mail (and envelope) security? In-Reply-To: References: <20190130163327.3c8a9135@300baud.de> Message-ID: <20190130204407.4c195dc7@300baud.de> On Wed, 30 Jan 2019 20:22:35 +0100, Peter Lebbing wrote: > On 30/01/2019 16:33, Stefan Claas wrote: > > Maybe one needs to use a special font ... > > Oh, most definitely. But which one ... ;-) I may check this again with a friend. > In this day and age, I'd probably look at a two-dimensional barcode > instead. The new jabcode (color barcode) from Germany's Fraunhofer Institute is pretty cool, because it stores much more data then traditional b / w codes. And it can withstand jpeg artifacts when converted back to .png! > Supposing I would even consider sending OpenPGP data on paper :-). Other > than key backups, where I'd opt for the program paperkey rather than > barcodes. Paperkey is good, but seriously we should also research this topic a bit, because it might come in handy. And it would be interesting to see with what solutions people would come up. On the other side i wish PGPfone would have been further developed. I found it, way back then, pretty cool and super easy to use, compared to PGP or GnuPG. Regards Stefan From peter at digitalbrains.com Wed Jan 30 21:23:56 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 30 Jan 2019 21:23:56 +0100 Subject: OpenPGP on paper (was: Where can I find some papers to read on mail (and envelope) security?) In-Reply-To: <20190130204407.4c195dc7@300baud.de> References: <20190130163327.3c8a9135@300baud.de> <20190130204407.4c195dc7@300baud.de> Message-ID: (Changed the subject because we went off-topic on an off-topic thread and in doing so went back on-topic for the mailing list! :-) On 30/01/2019 20:44, Stefan Claas wrote: > But which one ... ;-) I may check this again with a friend. Well there are the classical options: Debian provides free fonts like that as packages fonts-ocr-a and fonts-ocr-b, which come from: and > The new jabcode (color barcode) from Germany's Fraunhofer Institute > is pretty cool Oh, nice. My bank uses something similar (you get a device with a camera you point at your webbrowser screen), but this is an open standard, that's much better. Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From sac at 300baud.de Wed Jan 30 21:50:06 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 30 Jan 2019 21:50:06 +0100 Subject: OpenPGP on paper (was: Where can I find some papers to read on mail (and envelope) security?) In-Reply-To: References: <20190130163327.3c8a9135@300baud.de> <20190130204407.4c195dc7@300baud.de> Message-ID: <20190130215006.6f436b0b@300baud.de> On Wed, 30 Jan 2019 21:23:56 +0100, Peter Lebbing wrote: > On 30/01/2019 20:44, Stefan Claas wrote: > > But which one ... ;-) I may check this again with a friend. > > Well there are the classical options: > > > > Debian provides free fonts like that as packages fonts-ocr-a and > fonts-ocr-b, which come from: > > and > Thanks, i will take a look! Regards Stefan From GnuPG-User at Juinio.net Wed Jan 30 21:46:26 2019 From: GnuPG-User at Juinio.net (Allen M. Juinio) Date: Wed, 30 Jan 2019 12:46:26 -0800 Subject: Gnupg-users Digest, Vol 184, Issue 22 In-Reply-To: References: Message-ID: <625DD656-7563-4FAD-A51E-7A61486C9A92@Juinio.net> > Date: Wed, 30 Jan 2019 20:44:07 +0100 > From: Stefan Claas > To: Peter Lebbing > Cc: gnupg-users at gnupg.org > Subject: Re: [OT] Where can I find some papers to read on mail (and > envelope) security? > Message-ID: <20190130204407.4c195dc7 at 300baud.de> > Content-Type: text/plain; charset=US-ASCII > > [SNIP] > > On the other side i wish PGPfone would have been further developed. > I found it, way back then, pretty cool and super easy to use, compared > to PGP or GnuPG. > > Regards > Stefan Have you tried using Signal from Open Whisper Systems? They have both an Android and Apple version. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sac at 300baud.de Wed Jan 30 23:47:41 2019 From: sac at 300baud.de (Stefan Claas) Date: Wed, 30 Jan 2019 23:47:41 +0100 Subject: Gnupg-users Digest, Vol 184, Issue 22 In-Reply-To: <625DD656-7563-4FAD-A51E-7A61486C9A92@Juinio.net> References: <625DD656-7563-4FAD-A51E-7A61486C9A92@Juinio.net> Message-ID: <20190130234741.3e8ce8af@300baud.de> On Wed, 30 Jan 2019 12:46:26 -0800, Allen M. Juinio wrote: > > Date: Wed, 30 Jan 2019 20:44:07 +0100 > > From: Stefan Claas > > On the other side i wish PGPfone would have been further developed. > > I found it, way back then, pretty cool and super easy to use, compared > > to PGP or GnuPG. > Have you tried using Signal from Open Whisper Systems? They have both an Android and Apple version. Thanks, i am aware of Signal, but what i mean is to communicate directly and not via servers and also by not giving away phone numbers. With PGPfone one needed only the (current) IP address of its communication partner and then connected directly, without any servers involved. Regards Stefan From wk at gnupg.org Thu Jan 31 08:53:17 2019 From: wk at gnupg.org (Werner Koch) Date: Thu, 31 Jan 2019 08:53:17 +0100 Subject: [OT] Where can I find some papers to read on mail (and envelope) security? In-Reply-To: <20190130204407.4c195dc7@300baud.de> (Stefan Claas's message of "Wed, 30 Jan 2019 20:44:07 +0100") References: <20190130163327.3c8a9135@300baud.de> <20190130204407.4c195dc7@300baud.de> Message-ID: <87y371b6vm.fsf@wheatstone.g10code.de> On Wed, 30 Jan 2019 20:44, sac at 300baud.de said: > On the other side i wish PGPfone would have been further developed. > I found it, way back then, pretty cool and super easy to use, compared > to PGP or GnuPG. Please don't compare an online protocol with an offline (store+forward) protocol - they have very different semantics and purposes. With online or near-online protocols you can negotiate parameters and with a phone you even have a kind of second channel for verification purposes. Hard to see how to do this with backup tapes or data in mail queues and imap folders ;-) Shalom-Salam, Werner p.s. Regarding the OP: I would still recommend Ross Anderson's "Security Engineering" - it is far from being dedicated to snail mail but nevertheless has lot of real world security examples for many areas. -- 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 mkesper at schokokeks.org Wed Jan 30 21:36:15 2019 From: mkesper at schokokeks.org (Michael Kesper) Date: Wed, 30 Jan 2019 21:36:15 +0100 Subject: [OT] Where can I find some papers to read on mail (and envelope) security? In-Reply-To: <20190130163327.3c8a9135@300baud.de> References: <20190130163327.3c8a9135@300baud.de> Message-ID: <65f4a745-0113-f91c-7c17-c3460c09deaf@schokokeks.org> Hi Stefan, On 30.01.19 16:33, Stefan Claas wrote: > Interesting topic, which i am interested in as well. I started, as German > citizen, to use also epost Brief and De-Mail a while ago, when > communicating sometimes with friends, because i like those paid > services much more than the classical email PGP combo. You know that you use snake oil then? These services decrypt your e-mails to "protect you against viruses" [0]. Best wishes Michael [0] https://www.deutschepost.de/de/e/epost/privatkunden/sicherheit.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: