Re: Which version of GnuPG to use?
On Mon, 16 Sep 2019 23:49, gnupg-users@gnupg.org said: > speak, with a specially crafted software, when using an online computer > with a SmardCard? I have read that the secret key can not been copied from > the card, but what about the 'bits and pieces' in memory when decrypting? Side-channel attacks on smartcards are an pretty old thing dating back to the late 80ies. Current smartcards are hardened against most such attacks. Unless you have physical access to the card the secrets and their use on the card/token are well protected against any sniffing by the host. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Which version of GnuPG to use?
Daniel Bossert wrote: > Hi all > > Some years ago I used GnuPG, but somewhen stopped with it. > > Now I want to start again. However there are many rumors that it is > unsecure meanwhile. Can you tell us what rumors you have heared? I would say the encryption in GnuPG is secure, but sadly people tend to use encryption software on online computers due to many tutorials, MUA plug-ins and their lazyness and therefore it can never been guaranteed that the communications are always secure. P.S. Question for Werner and all the other hackers. Would it be very difficult to read out the required decryption parameters, like p&q so to speak, with a specially crafted software, when using an online computer with a SmardCard? I have read that the secret key can not been copied from the card, but what about the 'bits and pieces' in memory when decrypting? Regards Stefan -- box: 4a64758de9e8ceded2c481ee526440687fe2f3a828e3a813f87753ad30847b56 certified OpenPGP key blocks available on keybase.io/stefan_claas ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating bitwise identical keyrings with GnuPG 1 + 2
On Mon, 16 Sep 2019 15:41, io...@ionic.de said: > * On 9/15/19 3:56 PM, Werner Koch wrote: >> The trust packets are for internal use of gpg and are never exported. > > But... that's the whole point. gpg 1.4 seems to export them, while gpg > 2.x does not. I just checked the code and I can't see how they get exported. In the loop over the packets you find: /* Make sure that ring_trust packets never get exported. */ if (node->pkt->pkttype == PKT_RING_TRUST) continue; which should skip them while exporting. Can you please provide a test keyring and tell us the exact gpg 1.4 version you are using? > unreproducible output for a specific operation is a bit weird. I don't know if > the format GnuPG generates with the --export command is considered > stable, though. Yes it is the interchange format as specified by RFC-4880. > I basically need to find a way to > - either make gpg 1.4 NOT output trust packets The solution is simple; Do not use gpg 1.4 except for decrypting legacy data which either does not use MDC or is encrypted with a v3 key. There is no other use case for gpg 1.4. > 1.4 seems to generate trust packets *only* after signatures, while 2.2, when > used with the --export-options backup option, generates trust packets after > key, They are implementation defined and thus do not go into the key interchange format (transferable public/secret key). The backup/restore options are an exception for, well, backup and restore of *GnuPG*'s internal key data storage. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location?
* On 9/16/19 3:27 PM, Werner Koch wrote: > On Mon, 16 Sep 2019 10:11, io...@ionic.de said: > >> which also means that requests to URLs like http://keys.gnupg.net will >> sometimes >> redirect a user to that location. > > That is not correct. For quite some time that address is a hardwired to > avoid problems DNS problems (https://dev.gnupg.org/T3755): I probably should have been more specific. Yes, that holds for the GnuPG tool, but I was talking about users accessing the keyserver web interface directly using a normal browser (e.g., for checking on own or foreign public keys). The CNAME is still used in this case. :) I was quite surprised to browse to http://keys.gnupg.net and be redirected to https://analytics.sumptuouscapital.com/ - though luckily only the one mentioned node does that. Mihai signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Generating bitwise identical keyrings with GnuPG 1 + 2
* On 9/15/19 3:56 PM, Werner Koch wrote: > The trust packets are for internal use of gpg and are never exported. But... that's the whole point. gpg 1.4 seems to export them, while gpg 2.x does not. > These packets are one of the reasons why we stated for decades that the > interface is "gpg --export" and that the files in ~/.gnupg are internal to > gnupg. I understand that this might be considered implementation defined, but getting unreproducible output for a specific operation is a bit weird. I don't know if the format GnuPG generates with the --export command is considered stable, though. > The RFC also states that the format of this packet is _implementation > defined_ and SHOULD NOT be emitted to output streams or should be ignored on > import. So it looks like GnuPG 1.x didn't adhere to this recommendation, while GnuPG 2.x does. > If you use "--export-options backup" these trust packets are exported anyway > so that they can be imported with "--import-otions restore". That might be a valid workaround for gpg >= 2.1.18 to make it spit out trust packets. I basically need to find a way to - either make gpg 1.4 NOT output trust packets - or make gpg 2.x generate them. Initially, I thought about using --export-options export-minimal, because it's supported by even ancient 1.4 versions and could have been the better solution here, given that a package archive keyring doesn't need to ship additional signatures (other than the most recent selfsigs). This said, I tried that option and it does not seem to force gpg 1.4 to drop trust packets, so that's sadly not a viable option. Haven't any other option that would stop gpg 1.4 from generating them either. Using --export-options backup, which seems to be supported by at least gpg 2.1.18+, made gpg 2.2 write out trust packets alright, but... more than gpg 1.4 generates. :( 1.4 seems to generate trust packets *only* after signatures, while 2.2, when used with the --export-options backup option, generates trust packets after key, user and signature packets. Excerpt: --- keyringdump.gpg12019-09-16 11:58:56.506758876 +0200 +++ keyringdump.gpg22019-09-16 12:02:14.967564877 +0200 @@ -4,9 +4,13 @@ pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: E1F958385BFE2B6E -# off=272 ctb=b4 tag=13 hlen=2 plen=46 +# off=272 ctb=b0 tag=12 hlen=2 plen=12 +:trust packet: key upd=0 src=0 +# off=286 ctb=b4 tag=13 hlen=2 plen=46 :user ID packet: "X2go Debian/Ubuntu Packaging " -# off=320 ctb=89 tag=2 hlen=3 plen=312 +# off=334 ctb=b0 tag=12 hlen=2 plen=12 +:trust packet: uid upd=0 src=0 +# off=348 ctb=89 tag=2 hlen=3 plen=312 :signature packet: algo 1, keyid E1F958385BFE2B6E version 4, created 1299793310, md5len 0, sigclass 0x13 digest algo 2, begin of digest a8 73 @@ -19,15 +23,15 @@ hashed subpkt 23 len 1 (keyserver preferences: 80) subpkt 16 len 8 (issuer key ID E1F958385BFE2B6E) data: [2046 bits] -# off=635 ctb=b0 tag=12 hlen=2 plen=2 +# off=663 ctb=b0 tag=12 hlen=2 plen=6 :trust packet: sig flag=00 sigcache=03 -# off=639 ctb=b9 tag=14 hlen=3 plen=269 +# off=671 ctb=b9 tag=14 hlen=3 plen=269 :public sub key packet: version 4, algo 1, created 1299793310, expires 0 pkey[0]: [2048 bits] pkey[1]: [17 bits] keyid: 71F21F68F489CDCF -# off=911 ctb=89 tag=2 hlen=3 plen=287 +# off=943 ctb=89 tag=2 hlen=3 plen=287 :signature packet: algo 1, keyid E1F958385BFE2B6E version 4, created 1299793310, md5len 0, sigclass 0x18 digest algo 2, begin of digest 77 f5 Looks like I'm stuck. The source code is also enlightening - build_packet_and_meta (which is used with backup) creates trust packets for KEY, SIG, and USER packets, while keyring.c in 1.4 ignores/skips over any trust packets but those coming right after a SIG packet. Mihai signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: 37.191.231.105 (part of keyserver pool) redirects to ... unknown location?
On Mon, 16 Sep 2019 10:11, io...@ionic.de said: > which also means that requests to URLs like http://keys.gnupg.net will > sometimes > redirect a user to that location. That is not correct. For quite some time that address is a hardwired to avoid problems DNS problems (https://dev.gnupg.org/T3755): /* We used to have DNS CNAME redirection from the URLs below to * sks-keyserver pools. The idea was to allow for a quick way to * switch to a different set of pools. The problem with that * approach is that TLS needs to verify the hostname and - because * DNS is not secured - it can only check the user supplied hostname * and not a hostname from a CNAME RR. Thus the final server all * need to have certificates with the actual pool name as well as * for keys.gnupg.net - that would render the advantage of * keys.gnupg.net useless and so we better give up on this. Because * the keys.gnupg.net URL are still in widespread use we do a static * mapping here. */ if (!strcmp (uri, "hkps://keys.gnupg.net") || !strcmp (uri, "keys.gnupg.net")) uri = "hkps://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "https://keys.gnupg.net";)) uri = "https://hkps.pool.sks-keyservers.net";; else if (!strcmp (uri, "hkp://keys.gnupg.net")) uri = "hkp://hkps.pool.sks-keyservers.net"; else if (!strcmp (uri, "http://keys.gnupg.net";)) uri = "http://hkps.pool.sks-keyservers.net";; else if (!strcmp (uri, "hkps://http-keys.gnupg.net") || !strcmp (uri, "http-keys.gnupg.net")) uri = "hkps://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "https://http-keys.gnupg.net";)) uri = "https://ha.pool.sks-keyservers.net";; else if (!strcmp (uri, "hkp://http-keys.gnupg.net")) uri = "hkp://ha.pool.sks-keyservers.net"; else if (!strcmp (uri, "http://http-keys.gnupg.net";)) uri = "http://ha.pool.sks-keyservers.net";; Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Which version of GnuPG to use?
Hi, On Mon, Sep 16, 2019 at 11:29:19AM +0200, Daniel Bossert wrote: I need recommendations: - Which version of software shall I install? The latest version available for your system, which should in any case be a version from the 2.2 branch. (If your system is Windows, that would be Gpg4Win 3.1.10, which provides GnuPG 2.2.17.) You should *not* use GnuPG 1.4.x unless you have some very specific needs (such as working on a "exotic" system or having to interoperate with PGP versions from the mid-1990s), and you should *not* use any version from the 2.0 or 2.1 branch which are not supported anymore. - Create key via cli-commands or is Windows-Version ok? This doesn't matter, really. You may use gnupg directly on the command line if you're familiar with it, but you don't have to. - Which keys shall I take (there was an article not to encrypt/sign with El-Gamal)? The usual recommandation is to stick to the default setting proposed by GnuPG (which currently and if I remember correctly is to generate a RSA-3072 master key for certifying and signing and a RSA-3072 encryption subkey). Note that modern versions of GnuPG do not ask you anymore to specify the type and/or size of key you want unless you explicitly request it. - Damien signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On Mon, Sep 16, 2019, Binarus wrote: > Surname, Forename | Company > Commas are not allowed as part of email addresses. While I knew that, I unless quoted, e.g., "Surname, Forename | Company" ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Which version of GnuPG to use?
Hi all Some years ago I used GnuPG, but somewhen stopped with it. Now I want to start again. However there are many rumors that it is unsecure meanwhile. I need recommendations: - Which version of software shall I install? - Create key via cli-commands or is Windows-Version ok? - Which keys shall I take (there was an article not to encrypt/sign with El-Gamal)? Many thanks and kind regards Daniel ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
37.191.231.105 (part of keyserver pool) redirects to ... unknown location?
Hi Since I know that the keyserver maintainers follow this list, I wonder what happened to 37.191.231.105, which is part of the keyserver pool? It currently HTTP-301-redirects to https://analytics.sumptuouscapital.com/ - which also means that requests to URLs like http://keys.gnupg.net will sometimes redirect a user to that location. Mihai signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: keys.openpgp.org not sending confirmation email
On 14.09.2019 13:15, Binarus wrote: > I have used the Thunderbird / Enigmail / Gpg4Win troika for quite a > while without any issue. Yesterday, I had to reinstall, and while doing > so, upgraded to the newest versions of that packages, and while I was at > it, revoked my old (1024-bit) keys and generated new (4096-bit) ones > (using Enigmail's key management). > > So I got four new key pairs, each of them associated with exactly one > email address. I uploaded the four public keys, again using Enigmail's > key management, to Enigmail's default key server, keys.openpgp.org. > Enigmail reported success each time. > > I got confirmation emails for three of that four keys, but it seems that > the key server isn't in the mood to send a confirmation email for the > fourth. I have uploaded that one multiple times since then (again via > Enigmail's key management), each time getting a success message, but > still getting no confirmation email. The issue is solved now. I am documenting the solution for people who are affected by the same problem and find this thread when searching. Credits go to Vincent Breitmoser who has confirmed my own suspicion and who was very helpful and fast with his support. The point is that the key server failed to parse the key's ID as an email address. The ID had the following structure (not the real ID, just to make clear the structure): Surname, Forename | Company Commas are not allowed as part of email addresses. While I knew that, I made the wrong assumption that only the part between the brackets would be considered the email address, and that I could use any characters for the "name" part (expect brackets, of course ...). Obviously, I was wrong, and the name part must obey the same rules as the actual email address. Vincent has told me that a certain number of other people had the same problem, so they are thinking of making their parsers less strict, as far as it concerns the name part. After my correspondence with him, I think that they will be quite fast in implementing the changes. However, I recommend everybody to make their whole key ID match the rules for email addresses if they intend to upload it to a key server. Personally, I have revoked all four of the new keys and generated new ones with the ID being only the email address without a name part. While this was not possible using Enigmail (because Enigmail insisted that I had to add a name to the key), it was very easy by using gpg directly on the command line (by the way, its documentation is quite good). As a last tip, keys.openpgp.org offers to upload a public key directly. When you do that, it will emit helpful messages in case of failure. In my case, with the problematic key / ID, it clearly told the the ID could not be parsed as an email address. Unfortunately, I didn't know about the direct upload offer before asking here ... Regards, and thanks again, Binarus ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
