From ueno at gnu.org Wed Jul 1 03:39:40 2015 From: ueno at gnu.org (Daiki Ueno) Date: Wed, 01 Jul 2015 10:39:40 +0900 Subject: [PATCH] Add inside-Emacs mode to GUI pinentry programs In-Reply-To: <87r3pd2vdw.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 15 Jun 2015 11:06:35 +0200") References: <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <87lhfuowyy.wl-neal@walfield.org> <87fv5xgr8j.wl-neal@walfield.org> <87wpz96uuq.fsf-ueno@gnu.org> <871thfrsjv.fsf-ueno@gnu.org> <871theh9sz.wl-neal@walfield.org> <87381u4fko.fsf@vigenere.g10code.de> <87zj42fm5p.wl-neal@walfield.org> <87wpz62p14.fsf@vigenere.g10code.de> <87y4jmfbee.wl-neal@walfield.org> <87r3pd2vdw.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: > On Mon, 15 Jun 2015 05:15, ueno at gnu.org said: > >> + /* Remove the INSIDE_EMACS variable so that a pinentry does not >> + always try to interact with Emacs. */ >> +#ifndef HAVE_W32_SYSTEM >> + gnupg_unsetenv ("INSIDE_EMACS"); >> +#endif > > I think we can do this on all platforms. The ifdef W32 is used for > DISPLAY because tehre is no X Server there. Sorry for the last minute request. Would you consider the attached patch for the 2.1.6 release, then? I suppose this wouldn't be a problem for the desktop environments starting gpg-agent on session start, but it might be safer to do that for terminal users. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-agent-Unset-INSIDE_EMACS-on-gpg-agent-startup.patch Type: text/x-patch Size: 1127 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Jul 1 06:18:25 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 01 Jul 2015 00:18:25 -0400 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150630073023-3349-16897-mailpile@slinky> References: <87y4j1ygsk.fsf@alice.fifthhorseman.net> <20150630073023-3349-16897-mailpile@slinky> Message-ID: <87oajwwlwu.fsf@alice.fifthhorseman.net> On Tue 2015-06-30 04:10:04 -0400, Bjarni Runar Einarsson wrote: > True. It did occur to me that naming the header after an RFC actually > accomplishes the versioning that was requested, but that's probably > bordering on "too clever". I agree that protected-headers is fine. That's if we end up needing it a versioning header at all, of course :) > This is an important point. However, I think my scheme makes such > tampering easy to detect. sure, the detection of tampering is easy! it's figuring out what to do about it that's hard. > Consider that the proposed protected-headers attribute is not user > configurable; this attribute is not created if you attach a > message/rfc822-headers part by hand, and is not generated by the bounces > or delivery reports the MIME type is commonly used for. > > However, the protected-headers attribute *is* protected by the PGP > encryption envelope or signature and is thus tamper resistant. > > That means that IF it is present, then it MUST be contained within a > RFC2822 part with a matching message-ID. If that constraint is violated, > then the message has been tampered with. > > Because message-IDs are important for so many things, threading etc., > they are generally NOT routinely modified by MTAs or mailing lists. So > the rate of false posities should be quite low. is the rate really what we're concerned with, though? It seems to me that we're discussing here is defense against an active adversary who is trying to convince you of something counterfactual related to the signatures. The worst counterfactual is to convince you that something in the unsigned context is included in the signed material. Maybe there are other possible attacks? > We were never going to be able to prevent tampering, the best we can do > is detect it. This scheme accomplishes that. > > Does that hold water? I think the argument here is that there are two kinds of attacks on signed headers: 0) make you think a correctly-signed header is invalid 1) make you think some other arbitrary data is correctly-signed attack (0) has so many easy ways to accomplish (random bit flips, whitespace injection) that we shouldn't presume to defend against it. attack (1) is harder to understand and work out. I think you're claiming that it's impossible, but i don't see an exhaustive argument for it. there are all kinds of ways that it could be repurposed in a bad way. Consider an attack like the following: A) Bob sends Alice two signed messages, X and Y. Both of them are memory-hole, multi-part/signed messages. Message X is "Subject: Xavier" with body "I think we should fire him." and message Y is "Subject: Yuri" with body "We are lucky to work with him." B) Alice wants to cause some trouble. She creates a new message Z that is multipart/mixed, with two subparts, each of which are the multipart-signed bodies of X and Y. the part containing X's body is marked Content-Disposition: inline, and the part containing Y's body is marked Content-Disposition: attachment. C) in the headers of message Z, she copies the Message-ID from message Y. D) Alice shares message Z with Yuri, telling him separately: "watch out for Bob, he wants to fire you!" E) Yuri sees a message with a signed header from Bob and a signed body from Bob, but the message he gets is the opposite of Bob's intended meaning. > It is possible, but it becomes very awkward to work with. Since MIME is > effectively designed as a stream protocol (you can generate an infinite > stream of data which is also infinitely nested, and is still valid > MIME), it's just not designed to make inferring position (or relative > position) easy to do. > > If you try to infer position you have two choices: > > 1. Parse the entire message into an intermediate data structure and > then evaluate that. > 2. Write code which evaluates a stream on the fly. I'm not sure we're talking about the same thing when we're talking about "inferring position". CSS selectors also work on tree-structured documents and they're able to recognize things like : body > div > span.mhole message/rfc822 > multipart/signed > multipart/mixed > message/rfc822-headers > Option 1 perpetuates the performance nightmares of PGP/MIME: you can't > do anything useful with a message without parsing the whole thing. I'd > like to avoid encoding this bad behavior into the spec. if we're looking at signatures, you're right that we won't be able to evaluate them until the entire message is processed. This is not particularly negotiable. If we want to talk about message signature structures that can sign messages piecemeal, that introduce whole new semantics and UI concerns, which i think we really don't want to get into. > Option 2 is only marginally more performant than option 1, in that you > can stop parsing when you've found what you need - but you still need > to start at the beginning and parse everything from there, updating > counters as you go and hoping that your MIME library traverses the > message tree in a stable and predictable way. Surely these are requirements of any sane mime library in the first place? > Yes, but Patrick is correct that the verifiation parser will need to > correctly decode before comparing with the public header section. > > The simple case is simple: encodings on the public header and the > protected one should simply be the same by default. If they're > different, then the message has been tampered with. > > Unfortunately, such tampering is common. If I send 8bit headers (not > an uncommon thing to do in Iceland a few years ago), some MTAs might > helpfully re-encode the header section. A good implementation of Memory > Hole will avoid raising a false positive here, but I'm not sure how much > work is involved. > > As always, signtures are the difficult bit and some implementations > might choose to not perform header validation at all just because it's > hard to get it right. Why shouldn't the signed embedded header (if you have a valid signature that covers it) should just replace any tampered external header? > Encryption is easy: protected-headers in an encrypted part can just be > trusted blindly and overwrite whatever was in the public section. Is > there any need to warn the user about tampering (considering the high > expected rate of false positives), if we're able to recover from it > gracefully? I'm not convinced this is as easy of an argument; the encryption doesn't necessarily contain a signature, right? --dkg From ueno at gnu.org Wed Jul 1 11:18:34 2015 From: ueno at gnu.org (Daiki Ueno) Date: Wed, 01 Jul 2015 18:18:34 +0900 Subject: gpgme 1.5.5 tests failing In-Reply-To: <87h9qc3w5k.fsf@vigenere.g10code.de> (Werner Koch's message of "Sat, 13 Jun 2015 09:27:51 +0200") References: <87fv62ba5j.fsf@vigenere.g10code.de> <874mmdlyel.fsf@alice.fifthhorseman.net> <87twuc4up2.fsf@vigenere.g10code.de> <87oakklol4.fsf@alice.fifthhorseman.net> <87pp507lwp.fsf-ueno-ueno@gnu.org> <878ubolj55.fsf@alice.fifthhorseman.net> <87h9qc3w5k.fsf@vigenere.g10code.de> Message-ID: Werner Koch writes: > On Fri, 12 Jun 2015 23:19, dkg at fifthhorseman.net said: > >> But... should gpgme require the existence or proper configuration of >> /dev/pts in some particular mode to be able to work? It seems to me >> that a system without /dev/pts at all should still be able to use gpgme, > > Right. As long as stderr and stdout are not connceted to a tty there > should be no problem. Maybe due to setlocale ? The error is around engine-gpg.c:518: if (isatty (1)) { int err; err = ttyname_r (1, dft_ttyname, sizeof (dft_ttyname)); if (err) rc = gpg_error_from_errno (err); With glibc and such chroot setting, I get: - isatty (1) => returns 0 - ttyname (1) => returns NULL, and doesn't set errno - ttyname_r (1, ...) => returns ENOTTY I am not sure if either of them is posixly correct, but maybe we can avoid the undefined behavior, by rewriting the above code to: err = ttyname_r (1, dft_ttyname, sizeof (dft_ttyname)); if (err != ENOTTY) { if (err) rc = gpg_error_from_errno (err); else This is what the 'tty' command (in coreutils) does. I'm attaching a tentative patch. For reproducing the error, I used the mock command on Fedora: $ mock -r fedora-rawhide-x86_64 --init $ mock -r fedora-rawhide-x86_64 --rebuild gpgme*.src.rpm (This actually runs "make check", but succeeds because stdout is redirected) $ mock -r fedora-rawhide-x86_64 --shell sh-4.3# cd builddir/build/BUILD/gpgme-1.4.3 sh-4.3# make check ... t-encrypt.c:60: GPGME: Inappropriate ioctl for device FAIL: t-encrypt t-encrypt-sym.c:67: GPGME: Inappropriate ioctl for device FAIL: t-encrypt-sym t-encrypt-sign.c:116: GPGME: Inappropriate ioctl for device Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Work-around-isatty-misbehavior-in-chroot.patch Type: text/x-patch Size: 4639 bytes Desc: not available URL: From bre at pagekite.net Wed Jul 1 11:19:25 2015 From: bre at pagekite.net (Bjarni Runar Einarsson) Date: Wed, 01 Jul 2015 09:19:25 -0000 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <87oajwwlwu.fsf@alice.fifthhorseman.net> References: <87oajwwlwu.fsf@alice.fifthhorseman.net> Message-ID: <20150701083714-3349-91410-mailpile@slinky> Good morning! Daniel Kahn Gillmor wrote: > > This is an important point. However, I think my scheme makes such > > tampering easy to detect. > > sure, the detection of tampering is easy! it's figuring out what to do > about it that's hard. Yes. :) > I think the argument here is that there are two kinds of attacks on > signed headers: > > 0) make you think a correctly-signed header is invalid > > 1) make you think some other arbitrary data is correctly-signed > > attack (0) has so many easy ways to accomplish (random bit flips, > whitespace injection) that we shouldn't presume to defend against it. > > attack (1) is harder to understand and work out. I think you're > claiming that it's impossible, but i don't see an exhaustive argument > for it. there are all kinds of ways that it could be repurposed in a > bad way. Yes, I think my scheme can be made secure. But I'm not sure how best to explore and express that; mailing lists aren't a very good medium for this sort of thing. > Consider an attack like the following: > > B) Alice wants to cause some trouble. She creates a new message Z > that is multipart/mixed, with two subparts, each of which are the > multipart-signed bodies of X and Y. the part containing X's body is > marked Content-Disposition: inline, and the part containing Y's body > is marked Content-Disposition: attachment. This attack is detected by my scheme. The parser will detect the protected-headers markers in X and notices that they are not contained in a matching RFC2822 message. Your attack scenario is useful though, in that it clearly defines an attack scenario which tools implementing Memory Hole should thwart. > I'm not sure we're talking about the same thing when we're talking about > "inferring position". CSS selectors also work on tree-structured > documents and they're able to recognize things like : > > body > div > span.mhole > > message/rfc822 > multipart/signed > multipart/mixed > message/rfc822-headers Generating or evaluating paths like this is not easy with all toolchains. CSS-style selectors are not a standard feature of MIME libraries. For example the default API exposed by the Python libraries for traversing MIME, Message.walk(), doesn't make the necessary information readily available. When using Message.walk() I cannot easily tell if that multipart/mixed part is contained inside multipart/signed or contained within message/rfc822. See: https://docs.python.org/2/library/email.message.html#email.message.Message.walk I can hack it, of course. But my point here is only that what you are asking is not something library authors have designed for, which *will* complicate implementation. You haven't justified this cost. My proposal on the other hand uses the Message-ID and the ad-hoc parameters on the Content-Type attribute for what they were designed for; signaling and identification, tooling should be pretty good and implementations straightforward. :-) > if we're looking at signatures, you're right that we won't be able to > evaluate them until the entire message is processed. This is not > particularly negotiable. > > If we want to talk about message signature structures that can sign > messages piecemeal, that introduce whole new semantics and UI concerns, > which i think we really don't want to get into. I understand that you don't want to get into it, I'm sure it feels like a giant can of worms and bike sheds. But I also thing it would be a travesty if we created a new spec today that was so inflexible that it wouldn't interoperate with forseeable developments on that front. Especially since the flexibility I'm after coincides with technical simplicity in this case. I content that your prosposal to detect based on position within the MIME structure is much more work to get right and implementations will be more brittle. I don't think you've ever really explained *why* you want to do things this way, so I'm probably overlooking what benefits you forsee from a position-based scheme as opposed to a marker like I proposed. Perhaps you could explain in more detail if you think I'm overlooking something important? > > As always, signtures are the difficult bit and some implementations > > might choose to not perform header validation at all just because it's > > hard to get it right. > > Why shouldn't the signed embedded header (if you have a valid signature > that covers it) should just replace any tampered external header? Maybe it should! This is certainly a simpler user experience. If the rate of normal tampering is high enough, then there's no point scaring the user with warnings about it when the app is able to recover and correct the situation. > > Encryption is easy: protected-headers in an encrypted part can just be > > trusted blindly and overwrite whatever was in the public section. Is > > there any need to warn the user about tampering (considering the high > > expected rate of false positives), if we're able to recover from it > > gracefully? > > I'm not convinced this is as easy of an argument; the encryption doesn't > necessarily contain a signature, right? Without a signature, the encrypted part is theoretically just as easy to tamper with (by replacing it wholesale) as any header in the public part. However in practice it is still more reliable because we know all the standard e-mail infrastructure doesn'tl mess with the contents. Malicious actors will just do both. The implication of course is that if there is no signature, we can't mark the headers as "verified". But we might still prefer to display the ones that were less likely to have been corrupted en route. Cheers! - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: OpenPGP Digital Signature URL: From wk at gnupg.org Wed Jul 1 12:15:27 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Jul 2015 12:15:27 +0200 Subject: [PATCH] Include defs.inc in BUILT_SOURCES In-Reply-To: <1435695479-18104-1-git-send-email-eric@debian.org> (Eric Dorland's message of "Tue, 30 Jun 2015 16:17:59 -0400") References: <1435695479-18104-1-git-send-email-eric@debian.org> Message-ID: <877fqki3pc.fsf@vigenere.g10code.de> On Tue, 30 Jun 2015 22:17, eric at debian.org said: > * doc/Makefile.am: Building the info files can fail on a clean source > tree since the .texi files include defs.inc. Use BUILT_SOURCES to force > it to be built early. I already di this 2 weeks ago ;-) commit ef273a9afc7840b75cfb9b8af78d117b7d672c6a Author: Werner Koch Date: Mon Jun 15 16:19:44 2015 +0200 doc: Add defs.inc to BUILT_SOURCES Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ueno at gnu.org Wed Jul 1 13:20:45 2015 From: ueno at gnu.org (Daiki Ueno) Date: Wed, 01 Jul 2015 20:20:45 +0900 Subject: gpgme 1.5.5 tests failing In-Reply-To: (Daiki Ueno's message of "Wed, 01 Jul 2015 18:18:34 +0900") References: <87fv62ba5j.fsf@vigenere.g10code.de> <874mmdlyel.fsf@alice.fifthhorseman.net> <87twuc4up2.fsf@vigenere.g10code.de> <87oakklol4.fsf@alice.fifthhorseman.net> <87pp507lwp.fsf-ueno-ueno@gnu.org> <878ubolj55.fsf@alice.fifthhorseman.net> <87h9qc3w5k.fsf@vigenere.g10code.de> Message-ID: <87mvzg6s4y.fsf-ueno@gnu.org> Daiki Ueno writes: > With glibc and such chroot setting, I get: > > - isatty (1) => returns 0 Sorry, s/returns 0/returns 1/. By the way, that reminds me of an isatty bug in MSYS2: http://sourceforge.net/p/msys2/tickets/157/ so I have an impression that it would be safer not to rely on isatty too much. Regards, -- Daiki Ueno From Alexander.Strobel at giepa.de Wed Jul 1 13:47:40 2015 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Wed, 1 Jul 2015 13:47:40 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <87y4j1ygsk.fsf@alice.fifthhorseman.net> References: <559016F8.1070906@enigmail.net> <20150628172001-31604-82866-mailpile@slinky> <87y4j1ygsk.fsf@alice.fifthhorseman.net> Message-ID: <5593D35C.6080505@giepa.de> >> Patrick wrote on another thread: >>> >> We should agree on certain specifics like how to display non-ASCII >>> >> characters in the memory hole headers. I would vote against using RFC >>> >> 2047, section 2 (e.g. =?UTF-8?blah?=), such that users can read the >>> >> headers easily if their mailers would not yet understand memory hole. >> > >> > I think I disagree. Although I applaud the sentiment (it's awesome that >> > we're considering usability here), my gut feeling is the headers should >> > be exactly like they are in the public header section. This will make >> > both the spec and the code to implement it much simpler, lowering the >> > bar to getting everyone to adopt this. > I agree with Bjarni here -- i don't want any different parsers to have > to apply to this stuff, and demanding that senders re-encode these > embedded headers seems like trouble to me. > > fwiw, i think thunderbird already displays the headers correctly if > they're packed with RFC 2047 encodings. I am weakly for the variation to use RFC 2047 within the protected-headers. Most MUA are capable of en/decoding these strings by default, so transferring them from/to the protected headers can easily be done and they will be displayed correctly. We have to implement some kind of conversion anyhow, so we should do this only at the moment we have to display the protected-headers side by side to the email. Regards Alex Strobel From wk at gnupg.org Wed Jul 1 15:19:19 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 01 Jul 2015 15:19:19 +0200 Subject: [Announce] GnuPG 2.1.6 released Message-ID: <87h9poggmg.fsf@vigenere.g10code.de> Hello! The GnuPG Project is pleased to announce the availability of a new release of GnuPG modern: Version 2.1.6. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard which is commonly abbreviated as PGP. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different branches of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about this branch. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. Noteworthy changes in version 2.1.6 =================================== * agent: New option --verify for the PASSWD command. * gpgsm: Add command option "offline" as an alternative to --disable-dirmngr. * gpg: Do not prompt multiple times for a password in pinentry loopback mode. * Allow the use of debug category names with --debug. * Using gpg-agent and gpg/gpgsm with different locales will now show the correct translations in Pinentry. * gpg: Improve speed of --list-sigs and --check-sigs. * gpg: Make --list-options show-sig-subpackets work again. * gpg: Fix an export problem for old keyrings with PGP-2 keys. * scd: Support PIN-pads on more readers. * dirmngr: Properly cleanup zombie LDAP helper processes and avoid hangs on dirmngr shutdown. * Various other bug fixes. A detailed description of the changes found in the 2.1 branch can be found at . Please be aware that there are still known bugs which we are working on. Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing list archives for known problems and workarounds. Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.6 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2 (4802k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2.sig This is the GnuPG source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe (2577k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe.sig This is an installer for Windows without graphical frontends except for a basic Pinentry tool. Please de-install an installed Gpg4win version before trying this installer. Note that on Window TLS access to keyservers is not yet available. The sources used to build the installer can be found in the same directory with an ".tar.xz" suffix. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.6.tar.bz2 you would use this command: gpg --verify gnupg-2.1.6.tar.bz2.sig gnupg-2.1.6.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.6.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.6.tar.bz2 and check that the output matches the next line: 9e8157b3386da04760657ce3117fc4dc570c57c5 gnupg-2.1.6.tar.bz2 a8cd2e7ab48abb94c126051df902e3380faf117e gnupg-w32-2.1.6_20150701.exe 1d3e70504f993d1297f04564dfda222f8b68a96f gnupg-w32-2.1.6_20150701.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from a keyserver using this command gpg --keyserver hkp://keys.gnupg.net --recv-keys \ 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using by a different key. Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese, Czech, French, German, Japanese, Russian, and Ukrainian being almost completely translated (2075 different strings). Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available as are the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. You may also want to follow postings at https://gnupg.org/blob/. Support ======== Please consult the archive of the gnupg-users mailing list before reporting a bug . We suggest to send bug reports for a new release to this list in favor of filing a bug at . For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html If you are a developer and you may need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. Maintenance and development of GnuPG is possible due to many individual and corporate donations; for a list of non-anonymous donors see . For the GnuPG hackers, Werner p.s. This is a announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From dkg at fifthhorseman.net Wed Jul 1 21:08:57 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 01 Jul 2015 15:08:57 -0400 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <20150701083714-3349-91410-mailpile@slinky> References: <87oajwwlwu.fsf@alice.fifthhorseman.net> <20150701083714-3349-91410-mailpile@slinky> Message-ID: <874mlnr8za.fsf@alice.fifthhorseman.net> On Wed 2015-07-01 05:19:25 -0400, Bjarni Runar Einarsson wrote: > Yes, I think my scheme can be made secure. But I'm not sure how > best to explore and express that; mailing lists aren't a very good > medium for this sort of thing. Do you have a preferred medium? If so, please point me to it :) We need to produce written documentation someplace that *will* convince people :) > Daniel Kahn Gillmor wrote: >> Consider an attack like the following: >> >> B) Alice wants to cause some trouble. She creates a new message Z >> that is multipart/mixed, with two subparts, each of which are the >> multipart-signed bodies of X and Y. the part containing X's body is >> marked Content-Disposition: inline, and the part containing Y's body >> is marked Content-Disposition: attachment. > > This attack is detected by my scheme. The parser will detect the > protected-headers markers in X and notices that they are not contained > in a matching RFC2822 message. I don't think this is a full protection -- the parser will *also* contain the protected-headers marker in Y and notice that they are contained in a matching RFC2822 message. shouldn't that trigger the expected "signed header" display? if not, why not? > Your attack scenario is useful though, in that it clearly defines an > attack scenario which tools implementing Memory Hole should thwart. yep, we should try to write up a stable of these attack scenarios. > Generating or evaluating paths like this is not easy with all > toolchains. CSS-style selectors are not a standard feature of MIME > libraries. agree. > For example the default API exposed by the Python libraries for > traversing MIME, Message.walk(), doesn't make the necessary information > readily available. When using Message.walk() I cannot easily tell if > that multipart/mixed part is contained inside multipart/signed or > contained within message/rfc822. > > See: https://docs.python.org/2/library/email.message.html#email.message.Message.walk > > I can hack it, of course. But my point here is only that what you are > asking is not something library authors have designed for, which *will* > complicate implementation. You haven't justified this cost. > > My proposal on the other hand uses the Message-ID and the ad-hoc > parameters on the Content-Type attribute for what they were designed > for; signaling and identification, tooling should be pretty good and > implementations straightforward. :-) Let's avoid "my proposal" and "your proposal" -- i don't want any ego stakes in the discussion one way or the other :) Let's call the two proposals "message-id matching" and "position matching" Anyone implementing signature verification has to deal with positional matching at some level anyway. you have to know which bits are the signature, and which other bits are the stuff signed (and which other stuff is irrelevant). So we're not going to avoid positional matching in the first place. furthermore, positional matching governs a signed mesage entirely on the basis of the message itself. The only contextual filter applied is "is this in something that is presented as a message/rfc822 object in the first place?" -- and if the answer is no, then we simply don't interpret the protected-header part as relevant to any message. By contrast, mesage-id matching relies on unsigned context to interpret the signed data, and to decide where to consider it relevant. This is a pattern that is asking for trouble. >> If we want to talk about message signature structures that can sign >> messages piecemeal, that introduce whole new semantics and UI concerns, >> which i think we really don't want to get into. > > I understand that you don't want to get into it, I'm sure it feels like > a giant can of worms and bike sheds. > > But I also thing it would be a travesty if we created a new spec today > that was so inflexible that it wouldn't interoperate with forseeable > developments on that front. I'm not suggesting that we'll decide to never deal with it. But i think the question of piecemeal signatures is orthogonal to memory-hole-style protected headers, whether we are talking about message-id matching or position matching. If you want to think through piecemeal signatures, let's do that, but in a distinct thread (we touched on their value briefly at the OpenPGP summit, and i recognize that there are legitimate scenarios where something like this would be useful; i'm just not sure about the tradeoffs in terms of metadata leakage and UI complexity). > I don't think you've ever really explained *why* you want to do things > this way, so I'm probably overlooking what benefits you forsee from > a position-based scheme as opposed to a marker like I proposed. Perhaps > you could explain in more detail if you think I'm overlooking something > important? I'm disappointed that my explanations are apparently so bad they don't register as explanations, but i'm willing to try harder :) Making a system's interpretation of signed data subtly (or not so subtly) dependent on unsigned context is a bad idea, because attackers can exploit the unsigned context to force different interpretations of the signed data. message-id matching is worse in this regard than position matching. >> > As always, signtures are the difficult bit and some implementations >> > might choose to not perform header validation at all just because it's >> > hard to get it right. >> >> Why shouldn't the signed embedded header (if you have a valid signature >> that covers it) should just replace any tampered external header? > > Maybe it should! This is certainly a simpler user experience. > > If the rate of normal tampering is high enough, then there's no point > scaring the user with warnings about it when the app is able to recover > and correct the situation. I'm not convinced that we should ever scare the user with warnings about failed signatures anywhere. I'm inclined to treat failed signatures exactly the same as unsigned messages for the default UI case, particularly because there's nothing most users can do to "fix" or even effectively inspect the broken signature. > Without a signature, the encrypted part is theoretically just as easy to > tamper with (by replacing it wholesale) as any header in the public > part. However in practice it is still more reliable because we know all > the standard e-mail infrastructure doesn'tl mess with the contents. > > Malicious actors will just do both. The implication of course is that if > there is no signature, we can't mark the headers as "verified". But we > might still prefer to display the ones that were less likely to have > been corrupted en route. Yep, totally agree here -- as long as we're not claiming something about the headers that is untrue (marking it as "signed" would be bad if there was no signature), i see no harm in displaying an encrypted embedded header preferentialy over the external header. This raises a UI question though: how do we communicate to users that a given header was hidden (encrypted) in transit, as opposed to a header that was *not* hidden (encrypted) in transit? Is this something that we need to communicate to the user? if so, how do we do it? what visual cues would be needed? --dkg From folkert at vanheusden.com Wed Jul 1 21:22:50 2015 From: folkert at vanheusden.com (folkert) Date: Wed, 1 Jul 2015 21:22:50 +0200 Subject: [Announce] GnuPG 2.1.6 released In-Reply-To: <87h9poggmg.fsf@vigenere.g10code.de> References: <87h9poggmg.fsf@vigenere.g10code.de> Message-ID: <20150701192250.GZ9362@belle.intranet.vanheusden.com> Hi, At least with gpg2 2.1.4-1 and gpgme 1.5.5-2 the passphrase callback does not work. When enabled I get the "secret key unusable" error, and without the callback (enter passphrase via agent) it works fine. If I remember correctly you stated that you need gpg2 v2.1 or better for that to work: https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029872.html On Wed, Jul 01, 2015 at 03:19:19PM +0200, Werner Koch wrote: > Hello! > > The GnuPG Project is pleased to announce the availability of a new > release of GnuPG modern: Version 2.1.6. > > The GNU Privacy Guard (GnuPG) is a complete and free implementation > of the OpenPGP standard which is commonly abbreviated as PGP. > > GnuPG allows to encrypt and sign data and communication, features a > versatile key management system as well as access modules for public key > directories. GnuPG itself is a command line tool with features for easy > integration with other applications. A wealth of frontend applications > and libraries making use of GnuPG are available. Since version 2 GnuPG > provides support for S/MIME and Secure Shell in addition to OpenPGP. > > GnuPG is Free Software (meaning that it respects your freedom). It can > be freely used, modified and distributed under the terms of the GNU > General Public License. > > Three different branches of GnuPG are actively maintained: > > - GnuPG "modern" (2.1) is the latest development with a lot of new > features. This announcement is about this branch. > > - GnuPG "stable" (2.0) is the current stable version for general use. > This is what most users are currently using. > > - GnuPG "classic" (1.4) is the old standalone version which is most > suitable for older or embedded platforms. > > You may not install "modern" (2.1) and "stable" (2.0) at the same > time. However, it is possible to install "classic" (1.4) along with > any of the other versions. > > > Noteworthy changes in version 2.1.6 > =================================== > > * agent: New option --verify for the PASSWD command. > > * gpgsm: Add command option "offline" as an alternative to > --disable-dirmngr. > > * gpg: Do not prompt multiple times for a password in pinentry > loopback mode. > > * Allow the use of debug category names with --debug. > > * Using gpg-agent and gpg/gpgsm with different locales will now show > the correct translations in Pinentry. > > * gpg: Improve speed of --list-sigs and --check-sigs. > > * gpg: Make --list-options show-sig-subpackets work again. > > * gpg: Fix an export problem for old keyrings with PGP-2 keys. > > * scd: Support PIN-pads on more readers. > > * dirmngr: Properly cleanup zombie LDAP helper processes and avoid > hangs on dirmngr shutdown. > > * Various other bug fixes. > > > A detailed description of the changes found in the 2.1 branch can be > found at . > > Please be aware that there are still known bugs which we are working on. > Check https://bugs.gnupg.org, https://wiki.gnupg.org, and the mailing > list archives for known problems and workarounds. > > > Getting the Software > ==================== > > Please follow the instructions found at https://gnupg.org/download/ or > read on: > > GnuPG 2.1.6 may be downloaded from one of the GnuPG mirror sites or > direct from its primary FTP server. The list of mirrors can be found > at . Note that GnuPG is not available > at ftp.gnu.org. > > On ftp.gnupg.org you find these files: > > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2 (4802k) > ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.6.tar.bz2.sig > > This is the GnuPG source code compressed using BZIP2 and its OpenPGP > signature. > > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe (2577k) > ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.6_20150701.exe.sig > > This is an installer for Windows without graphical frontends except for > a basic Pinentry tool. Please de-install an installed Gpg4win version > before trying this installer. Note that on Window TLS access to > keyservers is not yet available. The sources used to build the > installer can be found in the same directory with an ".tar.xz" suffix. > > > Checking the Integrity > ====================== > > In order to check that the version of GnuPG which you are going to > install is an original and unmodified one, you can do it in one of > the following ways: > > * If you already have a version of GnuPG installed, you can simply > verify the supplied signature. For example to verify the signature > of the file gnupg-2.1.6.tar.bz2 you would use this command: > > gpg --verify gnupg-2.1.6.tar.bz2.sig gnupg-2.1.6.tar.bz2 > > This checks whether the signature file matches the source file. > You should see a message indicating that the signature is good and > made by one or more of the release signing keys. Make sure that > this is a valid key, either by matching the shown fingerprint > against a trustworthy list of valid release signing keys or by > checking that the key has been signed by trustworthy other keys. > See below for information on the signing keys. > > * If you are not able to use an existing version of GnuPG, you have > to verify the SHA-1 checksum. On Unix systems the command to do > this is either "sha1sum" or "shasum". Assuming you downloaded the > file gnupg-2.1.6.tar.bz2, you would run the command like this: > > sha1sum gnupg-2.1.6.tar.bz2 > > and check that the output matches the next line: > > 9e8157b3386da04760657ce3117fc4dc570c57c5 gnupg-2.1.6.tar.bz2 > a8cd2e7ab48abb94c126051df902e3380faf117e gnupg-w32-2.1.6_20150701.exe > 1d3e70504f993d1297f04564dfda222f8b68a96f gnupg-w32-2.1.6_20150701.tar.xz > > > > Release Signing Keys > ==================== > > To guarantee that a downloaded GnuPG version has not been tampered by > malicious entities we provide signature files for all tarballs and > binary versions. The keys are also signed by the long term keys of > their respective owners. Current releases are signed by one or more > of these four keys: > > 2048R/4F25E3B6 2011-01-12 [expires: 2019-12-31] > Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 > Werner Koch (dist sig) > > rsa2048/E0856959 2014-10-29 [expires: 2019-12-31] > Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 > David Shaw (GnuPG Release Signing Key) > > rsa2048/33BD3F06 2014-10-29 [expires: 2016-10-28] > Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 > NIIBE Yutaka (GnuPG Release Key) > > rsa2048/7EFD60D9 2014-10-19 [expires: 2020-12-31] > Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 > Werner Koch (Release Signing Key) > > You may retrieve these files from a keyserver using this command > > gpg --keyserver hkp://keys.gnupg.net --recv-keys \ > 249B39D24F25E3B6 04376F3EE0856959 \ > 2071B08A33BD3F06 8A861B1C7EFD60D9 > > The keys are also available at https://gnupg.org/signature_key.html and > in any recently released GnuPG tarball in the file g10/distsigkey.gpg . > Note that this mail has been signed using by a different key. > > > Internationalization > ==================== > > This version of GnuPG has support for 26 languages with Chinese, > Czech, French, German, Japanese, Russian, and Ukrainian being almost > completely translated (2075 different strings). > > > Documentation > ============= > > If you used GnuPG in the past you should read the description of > changes and new features at doc/whats-new-in-2.1.txt or online at > > https://gnupg.org/faq/whats-new-in-2.1.html > > The file gnupg.info has the complete user manual of the system. > Separate man pages are included as well but they have not all the > details available as are the manual. It is also possible to read the > complete manual online in HTML format at > > https://gnupg.org/documentation/manuals/gnupg/ > > or in Portable Document Format at > > https://gnupg.org/documentation/manuals/gnupg.pdf . > > The chapters on gpg-agent, gpg and gpgsm include information on how > to set up the whole thing. You may also want search the GnuPG mailing > list archives or ask on the gnupg-users mailing lists for advise on > how to solve problems. Many of the new features are around for > several years and thus enough public knowledge is already available. > > You may also want to follow postings at https://gnupg.org/blob/. > > > Support > ======== > > Please consult the archive of the gnupg-users mailing list before > reporting a bug . > We suggest to send bug reports for a new release to this list in favor > of filing a bug at . For commercial support > requests we keep a list of known service companies at: > > https://gnupg.org/service.html > > If you are a developer and you may need a certain feature for your > project, please do not hesitate to bring it to the gnupg-devel mailing > list for discussion. > > > Thanks > ====== > > We have to thank all the people who helped with this release, be it > testing, coding, translating, suggesting, auditing, administering the > servers, spreading the word, and answering questions on the mailing > lists. Maintenance and development of GnuPG is possible due to many > individual and corporate donations; for a list of non-anonymous donors > see . > > > For the GnuPG hackers, > > Werner > > > p.s. > This is a announcement only mailing list. Please send replies only to > the gnupg-users at gnupg.org mailing list. > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. > _______________________________________________ > Gnupg-announce mailing list > Gnupg-announce at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-announce > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel Folkert van Heusden -- To MultiTail einai ena polymorfiko ergaleio gia ta logfiles kai tin eksodo twn entolwn. Prosferei: filtrarisma, xrwmatismo, sygxwneysi, diaforetikes provoles. http://www.vanheusden.com/multitail/ ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From Alexander.Strobel at giepa.de Thu Jul 2 11:59:39 2015 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Thu, 2 Jul 2015 11:59:39 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <87y4j1ygsk.fsf@alice.fifthhorseman.net> References: <559016F8.1070906@enigmail.net> <20150628172001-31604-82866-mailpile@slinky> <87y4j1ygsk.fsf@alice.fifthhorseman.net> Message-ID: <55950B8B.4020604@giepa.de> >> Patrick wrote on another thread: >>> >> We should agree on certain specifics like how to display non-ASCII >>> >> characters in the memory hole headers. I would vote against using RFC >>> >> 2047, section 2 (e.g. =?UTF-8?blah?=), such that users can read the >>> >> headers easily if their mailers would not yet understand memory hole. >> > >> > I think I disagree. Although I applaud the sentiment (it's awesome that >> > we're considering usability here), my gut feeling is the headers should >> > be exactly like they are in the public header section. This will make >> > both the spec and the code to implement it much simpler, lowering the >> > bar to getting everyone to adopt this. > I agree with Bjarni here -- i don't want any different parsers to have > to apply to this stuff, and demanding that senders re-encode these > embedded headers seems like trouble to me. > > fwiw, i think thunderbird already displays the headers correctly if > they're packed with RFC 2047 encodings. I am weakly for the variation to use RFC 2047 within the protected-headers. Most MUA are capable of en/decoding these strings by default, so transferring them from/to the protected headers can easily be done and they will be displayed correctly. We have to implement some kind of conversion anyhow, so we should do this only at the moment we have to display the protected-headers side by side to the email. Bjarni Runar Einarsson wrote: > The headers we protect are not PGP/MIME headers. I think something like > "protected-headers" or "secure-headers" would be better. I vote for the term "protected-headers". @All: New fields to consider Please correct me if I understood it wrong: In thes slides[1] DKG wrote, there is the minimum set of fields to put into the "protected-headers". Did anyone think about MUA specific header fields at this moment? How should the new standard handle them? In my opinion we should use the fields mentioned in your slides as minimum everyone has to implement. I am unsure about how to handle MUA specific fields which aren't directly shown to the user. We should allow these fields in the "protected-headers" and the analyzing software has to show/ignore these (irrelevant) fields. The "Thread-Index" in Microsoft Outlook is one of these fields for example. As this field is used by Outlook for building/displaying a conversation tree it is neccessary to "protect" (sign) this field. [1] https://www.ietf.org/proceedings/92/slides/slides-92-appsawg-0.pdf Regards Alex Strobel (www.gpg4o.com) From aheinecke at intevation.de Thu Jul 2 10:50:11 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Thu, 02 Jul 2015 10:50:11 +0200 Subject: [PATCH] gpgme: Add offline mode support for CMS keylisting Message-ID: <2590578.j8aOYfjzk7@esus> Hi, Attached patch implements support for the new offline option in gpgsm 2.1.6. The plan is to use this in Kleopatra to allow a keylisting that checks the Trustchain of a certificate but does not depend on slow / erronous external services for CRL / OCSP checks without disabling them completely. Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: Add-offline-mode-support-for-CMS-keylisting.patch Type: text/x-patch Size: 15688 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From neal at walfield.org Thu Jul 2 17:37:45 2015 From: neal at walfield.org (Neal H. Walfield) Date: Thu, 02 Jul 2015 17:37:45 +0200 Subject: [Announce] GnuPG 2.1.6 released In-Reply-To: <20150701192250.GZ9362@belle.intranet.vanheusden.com> References: <87h9poggmg.fsf@vigenere.g10code.de> <20150701192250.GZ9362@belle.intranet.vanheusden.com> Message-ID: <87egkqzi2e.wl-neal@walfield.org> Hi Folkert, At Wed, 1 Jul 2015 21:22:50 +0200, folkert wrote: > At least with gpg2 2.1.4-1 and gpgme 1.5.5-2 the passphrase callback > does not work. > When enabled I get the "secret key unusable" error, and without the > callback (enter passphrase via agent) it works fine. > If I remember correctly you stated that you need gpg2 v2.1 or better > for that to work: > https://lists.gnupg.org/pipermail/gnupg-devel/2015-May/029872.html Can you create (or point me to) a small, self-contained example that demonstrates this behavior? (I haven't been following this issue closely so I'm not clear how to exactly recreate the issue.) If you don't have time for that, can you at least open an issue on bugs.gnupg.org. Thanks! :) Neal From dkg at fifthhorseman.net Thu Jul 2 21:10:49 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 2 Jul 2015 15:10:49 -0400 Subject: [PATCH] drop long-deprecated gpgsm-gencert.sh Message-ID: <1435864249-11439-1-git-send-email-dkg@fifthhorseman.net> * tools/gpgsm-gencert.sh: remove deprecated script entirely. It is fully replaced by gpgsm --gen-key * doc/tools.texi: remove gpgsm-gencert.sh documentation * .gitignore: no longer ignore gpgsm-gencert.sh manpage * doc/Makefile.am: quit making the manpage * tools/Makefile.am: quit distributing the script * doc/howto-create-a-server-cert.texi: overhaul documentation to use gpgsm --gen-key and tweak explanations -- The commit deprecating gpgsm-gencert.sh (81972ca7d53ff1996e0086702a09d4405bdc2a7e) dates back exactly 6 years. https://codesearch.debian.net/results/gpgsm-gencert.sh suggests that in all of debian it is only referenced in documentation (for poldi and scute) and example files (libept), and isn't actually used directly anywhere. Furthermore, trying to use gpgsm-gencert.sh to make a simple webserver certificate-signing request failed for me, following the examples in doc/howto-create-a-server-cert.texi exactly. It's time we ripped off this band-aid :) Signed-off-by: Daniel Kahn Gillmor --- .gitignore | 1 - NEWS | 1 + doc/Makefile.am | 2 +- doc/howto-create-a-server-cert.texi | 177 +++++++++++++++---------------- doc/tools.texi | 37 ------- tools/Makefile.am | 3 +- tools/gpgsm-gencert.sh | 203 ------------------------------------ 7 files changed, 85 insertions(+), 339 deletions(-) delete mode 100755 tools/gpgsm-gencert.sh diff --git a/.gitignore b/.gitignore index a525f14..dd3d031 100644 --- a/.gitignore +++ b/.gitignore @@ -67,7 +67,6 @@ doc/gpg-zip.1 doc/gpg2.1 doc/gpgconf.1 doc/gpgparsemail.1 -doc/gpgsm-gencert.sh.1 doc/gpgsm.1 doc/gpgv2.1 doc/scdaemon.1 diff --git a/NEWS b/NEWS index 6932b92..476f42c 100644 --- a/NEWS +++ b/NEWS @@ -1,6 +1,7 @@ Noteworthy changes in version 2.1.7 (unreleased) ------------------------------------------------ + * dropped deprecated gpgsm-gencert.sh Noteworthy changes in version 2.1.6 (2015-07-01) ------------------------------------------------ diff --git a/doc/Makefile.am b/doc/Makefile.am index 3ea19ad..3ed3057 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -71,7 +71,7 @@ myman_sources = gnupg7.texi gpg.texi gpgsm.texi gpg-agent.texi \ myman_pages = gpg2.1 gpgsm.1 gpg-agent.1 dirmngr.8 scdaemon.1 gpgv2.1 \ watchgnupg.1 gpgconf.1 addgnupghome.8 gpg-preset-passphrase.1 \ gpg-connect-agent.1 gpgparsemail.1 symcryptrun.1 \ - gpgsm-gencert.sh.1 applygnupgdefaults.8 gpg-zip.1 \ + applygnupgdefaults.8 gpg-zip.1 \ dirmngr-client.1 man_MANS = $(myman_pages) gnupg.7 diff --git a/doc/howto-create-a-server-cert.texi b/doc/howto-create-a-server-cert.texi index ce6dd2f..f75da2e 100644 --- a/doc/howto-create-a-server-cert.texi +++ b/doc/howto-create-a-server-cert.texi @@ -7,18 +7,17 @@ actually been done this way to get a certificate from CAcert to be used on a real server. It has only been tested with this CA, but there shouldn't be any problem to run this against any other CA. -Before you start, make sure that gpg-agent is running. As there is no -need for a configuration file, you may simply enter: +We start by generating an X.509 certificate signing request. As there +is no need for a configuration file, you may simply enter: @cartouche @example - $ gpgsm-gencert.sh >a.p10 - Key type - [1] RSA - [2] Existing key - [3] Direct from card - Your selection: 1 - You selected: RSA + $ gpgsm --gen-key >example.com.cert-req.pem + Please select what kind of key you want: + (1) RSA + (2) Existing key + (3) Existing key from card + Your selection? 1 @end example @end cartouche @@ -32,39 +31,36 @@ Let's continue: @cartouche @example - Key length - [1] 1024 - [2] 2048 - Your selection: 1 - You selected: 1024 + What keysize do you want? (2048) + Requested keysize is 2048 bits @end example @end cartouche -The script offers two common key sizes. With the current setup of -CAcert, it does not make much sense to use a 2k key; their policies need -to be revised anyway (a CA root key valid for 30 years is not really -serious). +Hitting enter chooses the default RSA key size of 2048 bits. Smaller +keys are too weak on the modern Internet. If you choose a larger +(stronger) key, your server will need to do more work. @cartouche @example - Key usage - [1] sign, encrypt - [2] sign - [3] encrypt - Your selection: 1 - You selected: sign, encrypt + Possible actions for a RSA key: + (1) sign, encrypt + (2) sign + (3) encrypt + Your selection? 1 @end example @end cartouche -We want to sign and encrypt using this key. This is just a suggestion -and the CA may actually assign other key capabilities. +Selecting ``sign'' enables use of the key for Diffie-Hellman key +exchange mechanisms (DHE and ECDHE) in TLS, which are preferred +because they offer forward secrecy. Selecting ``encrypt'' enables RSA +key exchange mechanisms, which are still common in some places. +Selecting both enables both key exchange mechanisms. Now for some real data: @cartouche @example - Name (DN) - > CN=kerckhoffs.g10code.com + Enter the X.509 subject name: CN=example.com @end example @end cartouche @@ -74,13 +70,13 @@ server names later. @cartouche @example - E-Mail addresses (end with an empty line) + E-Mail addresses (end with an empty line): > @end example @end cartouche -We don't need email addresses in a server certificate and CAcert would -anyway ignore such a request. Thus just hit enter. +We don't need email addresses in a TLS server certificate and CAcert +would anyway ignore such a request. Thus just hit enter. If you want to create a client certificate for email encryption, this would be the place to enter your mail address @@ -89,22 +85,21 @@ however the CA may not accept them all or reject the entire request. @cartouche @example - DNS Names (optional; end with an empty line) - > www.g10code.com - DNS Names (optional; end with an empty line) - > ftp.g10code.com - DNS Names (optional; end with an empty line) + Enter DNS names (optional; end with an empty line): + > example.com + > www.example.com > @end example @end cartouche -Here I entered the names of the servers which actually run on the -machine given in the DN above. The browser will accept a certificate for -any of these names. As usual the CA must approve all of these names. +Here I entered the names of the services which the machine actually +provides. You almost always want to include the canonical name here +too. The browser will accept a certificate for any of these names. As +usual the CA must approve all of these names. @cartouche @example - URIs (optional; end with an empty line) + URIs (optional; end with an empty line): > @end example @end cartouche @@ -112,25 +107,30 @@ any of these names. As usual the CA must approve all of these names. It is possible to insert arbitrary URIs into a certificate; for a server certificate this does not make sense. + at cartouche + at example + Create self-signed certificate? (y/N) + at end example + at end cartouche + +Since we are creating a certificate signing request, and not a full +certificate, we answer no here, or just hit enter for the default. + We have now entered all required information and @command{gpgsm} will display what it has gathered and ask whether to create the certificate request: @cartouche @example - Parameters for certificate request to create: - 1 Key-Type: RSA - 2 Key-Length: 1024 - 3 Key-Usage: sign, encrypt - 4 Name-DN: CN=kerckhoffs.g10code.com - 5 Name-DNS: www.g10code.com - 6 Name-DNS: ftp.g10code.com - - Really create such a CSR? - [1] yes - [2] no - Your selection: 1 - You selected: yes + These parameters are used: + Key-Type: RSA + Key-Length: 2048 + Key-Usage: sign, encrypt + Name-DN: CN=example.com + Name-DNS: example.com + Name-DNS: www.example.com + + Proceed with creation? (y/N) y @end example @end cartouche @@ -146,6 +146,7 @@ When it is ready, you should see the final notice: @cartouche @example gpgsm: certificate request created + Ready. You should now send this request to your CA. @end example @end cartouche @@ -153,17 +154,22 @@ Now, you may look at the created request: @cartouche @example - $ cat a.p10 + $ cat example.com.cert-req.pem -----BEGIN CERTIFICATE REQUEST----- - MIIBnzCCAQgCAQAwITEfMB0GA1UEAxMWa2VyY2tob2Zmcy5nMTBjb2RlLmNvbTCB - nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA5h+uKRenpvbe+BnMY6siPO50LVyg - HtB7kr+YISlPJ5JAFO12yQFz9Y0sBLHbjR+V+TOawwP1dZhGjlgnEBkMdWKuEBlS - wFTALLX78GAyvAYAmPqSPDEYXkMECyUXVX/bbGI1bY8Y2OGy4w4D+v7e+xD2NBkm - Bj5cNy+YMbGVldECAwEAAaA+MDwGCSqGSIb3DQEJDjEvMC0wKwYDVR0RBCQwIoIP - d3d3LmcxMGNvZGUuY29tgg9mdHAuZzEwY29kZS5jb20wDQYJKoZIhvcNAQEFBQAD - gYEAzBRIi8KTfKyebOlMtDN6oDYBOv+r9A4w3u/Z1ikjffaiN1Bmd2o9Ez9KXKHA - IezLeSEA/rGUPN5Ur5qIJnRNQ8xrS+iLftr8msWQSZppVnA/vnqMrtqBUpitqAr0 - eYBmt1Uem2Y3UFABrKPglv2xzgGkrKX6AqmFoOnJWQ0QcTw= + MIIClTCCAX0CAQAwFjEUMBIGA1UEAxMLZXhhbXBsZS5jb20wggEiMA0GCSqGSIb3 + DQEBAQUAA4IBDwAwggEKAoIBAQDP1QEcbTvOLLCX4gAoOzH9AW7jNOMj7OSOL0uW + h2bCdkK5YVpnX212Z6COTC3ZG0pJiCeGt1TbbDJUlTa4syQ6JXavjK66N8ASZsyC + Rwcl0m6hbXp541t1dbgt2VgeGk25okWw3j+brw6zxLD2TnthJxOatID0lDIG47HW + GqzZmA6WHbIBIONmGnReIHTpPAPCDm92vUkpKG1xLPszuRmsQbwEl870W/FHrsvm + DPvVUUSdIvTV9NuRt7/WY6G4nPp9QlIuTf1ESPzIuIE91gKPdrRCAx0yuT708S1n + xCv3ETQ/bKPoAQ67eE3mPBqkcVwv9SE/2/36Lz06kAizRgs5AgMBAAGgOjA4Bgkq + hkiG9w0BCQ4xKzApMCcGA1UdEQQgMB6CC2V4YW1wbGUuY29tgg93d3cuZXhhbXBs + ZS5jb20wDQYJKoZIhvcNAQELBQADggEBAEWD0Qqz4OENLYp6yyO/KqF0ig9FDsLN + b5/R+qhms5qlhdB5+Dh+j693Sj0UgbcNKc6JT86IuBqEBZmRCJuXRoKoo5aMS1cJ + hXga7N9IA3qb4VBUzBWvlL92U2Iptr/cEbikFlYZF2Zv3PBv8RfopVlI3OLbKV9D + bJJTt/6kuoydXKo/Vx4G0DFzIKNdFdJk86o/Ziz8NOs9JjZxw9H9VY5sHKFM5LKk + VcLwnnLRlNjBGB+9VK/Tze575eG0cJomTp7UGIB+1xzIQVAhUZOizRDv9tHDeaK3 + k+tUhV0kuJcYHucpJycDSrP/uAY5zuVJ0rs2QSjdnav62YrRgEsxJrU= -----END CERTIFICATE REQUEST----- $ @end example @@ -189,26 +195,7 @@ followed by a Ctrl-D @example -----BEGIN CERTIFICATE----- MIIEIjCCAgqgAwIBAgIBTDANBgkqhkiG9w0BAQQFADBUMRQwEgYDVQQKEwtDQWNl - cnQgSW5jLjEeMBwGA1UECxMVaHR0cDovL3d3dy5DQWNlcnQub3JnMRwwGgYDVQQD - ExNDQWNlcnQgQ2xhc3MgMyBSb290MB4XDTA1MTAyODE2MjA1MVoXDTA3MTAyODE2 - MjA1MVowITEfMB0GA1UEAxMWa2VyY2tob2Zmcy5nMTBjb2RlLmNvbTCBnzANBgkq - hkiG9w0BAQEFAAOBjQAwgYkCgYEA5h+uKRenpvbe+BnMY6siPO50LVygHtB7kr+Y - ISlPJ5JAFO12yQFz9Y0sBLHbjR+V+TOawwP1dZhGjlgnEBkMdWKuEBlSwFTALLX7 - 8GAyvAYAmPqSPDEYXkMECyUXVX/bbGI1bY8Y2OGy4w4D+v7e+xD2NBkmBj5cNy+Y - MbGVldECAwEAAaOBtTCBsjAMBgNVHRMBAf8EAjAAMDQGA1UdJQQtMCsGCCsGAQUF - BwMCBggrBgEFBQcDAQYJYIZIAYb4QgQBBgorBgEEAYI3CgMDMAsGA1UdDwQEAwIF - oDAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2Vy - dC5vcmcwKwYDVR0RBCQwIoIPd3d3LmcxMGNvZGUuY29tgg9mdHAuZzEwY29kZS5j - b20wDQYJKoZIhvcNAQEEBQADggIBAAj5XAHCtzQR8PV6PkQBgZqUCbcfxGO/ZIp9 - aIT6J2z0Jo1OZI6KmConbqnZG9WyDlV5P7msQXW/Z9nBfoj4KSmNR8G/wtb8ClJn - W8s75+K3ZLq1UgEyxBDrS7GjtbVaj7gsfZsuiQzxmk9lbl1gbkpJ3VEMjwVCTMlM - fpjp8etyPhUZqOZaoKVaq//KTOsjhPMwz7TcfOkHvXketPrWTcefJQU7NKLH16D3 - mZAwnBxp3P51H6E6VG8AoJO8xCBuVwsbXKEf/FW+tmKG9pog6CaZQ9WibROTtnKj - NJjSBsrUk5C+JowO/EyZRGm6R1tlok8iFXj+2aimyeBqDcxozNmFgh9F3S5u0wK0 - 6cfYgkPVMHxgwV3f3Qh+tJkgLExN7KfO9hvpZqAh+CLQtxVmvpxEVEXKR6nwBI5U - BaseulvVy3wUfg2daPkG17kDDBzQlsWC0BRF8anH+FWSrvseC3nS0a9g3sXF1Ic3 - gIqeAMhkant1Ac3RR6YCWtJKr2rcQNdDAxXK35/gUSQNCi9dclEzoOgjziuA1Mha - 94jYcvGKcwThn0iITVS5hOsCfaySBLxTzfIruLbPxXlpWuCW/6I/7YyivppKgEZU + [...] rUTFlNElRXCwIl0YcJkIaYYqWf7+A/aqYJCi8+51usZwMy3Jsq3hJ6MA3h1BgwZs Rtct3tIX -----END CERTIFICATE----- @@ -229,19 +216,19 @@ To see the content of your certificate, you may now enter: @cartouche @example - $ gpgsm -K kerckhoffs.g10code.com + $ gpgsm -K example.com /home/foo/.gnupg/pubring.kbx --------------------------- Serial number: 4C Issuer: /CN=CAcert Class 3 Root/OU=http:\x2f\x2fwww.[...] - Subject: /CN=kerckhoffs.g10code.com - aka: (dns-name www.g10code.com) - aka: (dns-name ftp.g10code.com) - validity: 2005-10-28 16:20:51 through 2007-10-28 16:20:51 - key type: 1024 bit RSA + Subject: /CN=example.com + aka: (dns-name example.com) + aka: (dns-name www.example.com) + validity: 2015-07-01 16:20:51 through 2016-07-01 16:20:51 + key type: 2048 bit RSA key usage: digitalSignature keyEncipherment ext key usage: clientAuth (suggested), serverAuth (suggested), [...] - fingerprint: 0F:9C:27:B2:DA:05:5F:CB:33:19:D8:E9:65:B9:BD:4F:B1:98:CC:57 + fingerprint: 0F:9C:27:B2:DA:05:5F:CB:33:D8:19:E9:65:B9:4F:BD:B1:98:CC:57 @end example @end cartouche @@ -256,7 +243,7 @@ certificate. To create such a file, run: @cartouche @example - $ gpgsm --export-secret-key-p12 -a >kerckhoffs-cert.pem + $ gpgsm --export-secret-key-p12 -a >example.com-cert.pem @end example @end cartouche @@ -266,12 +253,12 @@ certificate as well as the private key: @cartouche @example - $ cat kerckhoffs-cert.pem + $ cat example-cert.pem Issuer ...: /CN=CAcert Class 3 Root/OU=http:\x2f\x2fwww.CA[...] Serial ...: 4C - Subject ..: /CN=kerckhoffs.g10code.com - aka ..: (dns-name www.g10code.com) - aka ..: (dns-name ftp.g10code.com) + Subject ..: /CN=example.com + aka ..: (dns-name example.com) + aka ..: (dns-name www.example.com) -----BEGIN PKCS12----- MIIHlwIBAzCCB5AGCSqGSIb37QdHAaCCB4EEggd9MIIHeTk1BJ8GCSqGSIb3DQEu diff --git a/doc/tools.texi b/doc/tools.texi index a067eb6..1dd1b35 100644 --- a/doc/tools.texi +++ b/doc/tools.texi @@ -15,7 +15,6 @@ GnuPG comes with a couple of smaller tools: * addgnupghome:: Create .gnupg home directories. * gpgconf:: Modify .gnupg home directories. * applygnupgdefaults:: Run gpgconf for all users. -* gpgsm-gencert.sh:: Generate an X.509 certificate request. * gpg-preset-passphrase:: Put a passphrase into the cache. * gpg-connect-agent:: Communicate with a running agent. * dirmngr-client:: How to use the Dirmngr client tool. @@ -1001,42 +1000,6 @@ applygnupgdefaults @c - at c GPGSM-GENCERT.SH - at c - at node gpgsm-gencert.sh - at section Generate an X.509 certificate request - at manpage gpgsm-gencert.sh.1 - at ifset manverb -.B gpgsm-gencert.sh -\- Generate an X.509 certificate request - at end ifset - - at mansect synopsis - at ifset manverb -.B gpgsm-gencert.sh - at end ifset - - at mansect description -This is a simple tool to interactively generate a certificate request -which will be printed to stdout. - - at manpause - at noindent - at command{gpgsm-gencert.sh} is invoked as: - - at samp{gpgsm-cencert.sh} - - at mansect see also - at ifset isman - at command{gpgsm}(1), - at command{gpg-agent}(1), - at command{scdaemon}(1) - at end ifset - at include see-also-note.texi - - - - at c @c GPG-PRESET-PASSPHRASE @c @node gpg-preset-passphrase diff --git a/tools/Makefile.am b/tools/Makefile.am index 5c28954..496b1a6 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -18,7 +18,7 @@ EXTRA_DIST = \ Manifest watchgnupg.c \ - addgnupghome applygnupgdefaults gpgsm-gencert.sh \ + addgnupghome applygnupgdefaults \ lspgpot mail-signed-keys convert-from-106 sockprox.c \ ccidmon.c ChangeLog-2011 gpg-connect-agent-w32info.rc @@ -34,7 +34,6 @@ AM_CFLAGS = $(LIBGCRYPT_CFLAGS) $(GPG_ERROR_CFLAGS) $(LIBASSUAN_CFLAGS) sbin_SCRIPTS = addgnupghome applygnupgdefaults -bin_SCRIPTS = gpgsm-gencert.sh if HAVE_USTAR # bin_SCRIPTS += gpg-zip noinst_SCRIPTS = gpg-zip diff --git a/tools/gpgsm-gencert.sh b/tools/gpgsm-gencert.sh deleted file mode 100755 index b209c8e..0000000 --- a/tools/gpgsm-gencert.sh +++ /dev/null @@ -1,203 +0,0 @@ -#!/bin/sh -# -*- sh -*- -# gpgsm-gencert.c - Generate X.509 certificates through GPGSM. -# Copyright (C) 2004, 2005 Free Software Foundation, Inc. -# -# This file is part of GnuPG. -# -# GnuPG is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 3 of the License, or -# (at your option) any later version. -# -# GnuPG is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, see . - -set -e - -ASSUAN_FP_IN=4 -ASSUAN_FP_OUT=5 - -ASSUAN_COMMANDS="\ -INPUT FD=$ASSUAN_FP_IN\n\ -OUTPUT FD=$ASSUAN_FP_OUT --armor\n\ -GENKEY\n\ -BYE\n" - -ANSWER="" - -query_user() -{ - message=$1; shift - - echo "$message" >&2 - echo -n "> " >&2 - read answer - - ANSWER=$answer; -} - -query_user_menu() -{ - message=$1; shift - i=0 - - echo "$message" >&2 - for choice in "$@"; do - i=$(expr $i + 1) - echo " [$i] $choice" >&2 - done - - while true; do - j=1 - echo -n "Your selection: " >&2 - read idx - - while [ $j -lt $i -o $j -eq $i ]; do - if [ "$idx" = $j ]; then - break - fi - j=$(expr $j + 1) - done - if [ $j -lt $i -o $j -eq $i ]; then - break - fi - done - - i=0 - for choice in "$@"; do - i=$(expr $i + 1) - if [ $i -eq $idx ]; then - ANSWER=$1 - break; - fi - shift - done - - echo "You selected: $ANSWER" >&2 -} - - -echo "WARNING: This script is deprecated; please use" >&2 -echo " gpgsm --gen-key" >&2 -echo " instead." >&2 -KEY_TYPE="" -while [ -z "$KEY_TYPE" ]; do - query_user_menu "Key type" "RSA" "Existing key" "Direct from card" - case "$ANSWER" in - RSA) - KEY_TYPE=$ANSWER - query_user_menu "Key length" "1024" "2048" - KEY_LENGTH=$ANSWER - KEY_GRIP= - ;; - Existing*) - # User requested to use an existing key; need to set some dummy defaults - query_user "Keygrip " - if [ -n "$ANSWER" ]; then - KEY_TYPE=RSA - KEY_LENGTH=1024 - KEY_GRIP=$ANSWER - fi - ;; - Direct*) - tmp=$(echo 'SCD SERIALNO' | gpg-connect-agent | \ - awk '$2 == "SERIALNO" {print $3}') - if [ -z "$tmp" ]; then - echo "No card found" >&2 - else - echo "Card with S/N $tmp found" >&2 - tmp=$(echo 'SCD LEARN --force' | gpg-connect-agent | \ - awk '$2 == "KEYPAIRINFO" {printf " %s", $4}') - sshid=$(echo 'SCD GETATTR $AUTHKEYID' | gpg-connect-agent | \ - awk '$2 == "$AUTHKEYID" {print $3}') - [ -n "$sshid" ] && echo "gpg-agent uses $sshid as ssh key" >&2 - query_user_menu "Select key " $tmp "back" - if [ "$ANSWER" != "back" ]; then - KEY_TYPE="card:$ANSWER" - KEY_LENGTH= - KEY_GRIP= - fi - fi - ;; - *) - exit 1 - ;; - esac -done - -query_user_menu "Key usage" "sign, encrypt" "sign" "encrypt" -KEY_USAGE=$ANSWER - -query_user "Name (DN)" -NAME=$ANSWER - -EMAIL_ADDRESSES= -LF= -while : ; do - query_user "E-Mail addresses (end with an empty line)" - [ -z "$ANSWER" ] && break - EMAIL_ADDRESSES="${EMAIL_ADDRESSES}${LF}Name-Email: $ANSWER" - LF=' -' -done - -DNS_ADDRESSES= -LF= -while : ; do - query_user "DNS Names (optional; end with an empty line)" - [ -z "$ANSWER" ] && break - DNS_ADDRESSES="${DNS_ADDRESSES}${LF}Name-DNS: $ANSWER" - LF=' -' -done - -URI_ADDRESSES= -LF= -while : ; do - query_user "URIs (optional; end with an empty line)" - [ -z "$ANSWER" ] && break - URI_ADDRESSES="${URI_ADDRESSES}${LF}Name-URI: $ANSWER" - LF=' -' -done - -file_parameter=$(mktemp "/tmp/gpgsm.XXXXXX") -outfile=$(mktemp "/tmp/gpgsm.XXXXXX") - - -( -cat < "$file_parameter" - - -echo 'Parameters for certificate request to create:' >&2 -cat -n "$file_parameter" >&2 -echo >&2 - -query_user_menu "Really create such a CSR?" "yes" "no" -[ "$ANSWER" != "yes" ] && exit 1 - - -printf "$ASSUAN_COMMANDS" | \ - gpgsm --no-log-file --debug-level none --debug-none \ - --server 4< "$file_parameter" 5>"$outfile" >/dev/null - -cat "$outfile" - -rm "$file_parameter" "$outfile" -exit 0 -- 2.1.4 From rfkrocktk at gmail.com Thu Jul 2 21:27:44 2015 From: rfkrocktk at gmail.com (Naftuli Tzvi Kay) Date: Thu, 2 Jul 2015 12:27:44 -0700 Subject: Feature request: handle multiple encryption subkeys on different smart cards intelligently In-Reply-To: References: <5576E2BC.7070007@fsij.org> Message-ID: I've also done some more hacking on trying to figure out a way to work around the issue currently. I've attempted to do the following: 1. Determine the card serial number by using gpg --card-status and parsing with sed, grep, etc. 2. Pair the card serial number with the encryption key known in advance to be used by the card. (ie: simple shell "case" statement to select encryption key id "DEADBEEF" for card "010101010" etc.) 3. When decrypting, pass --default-user $decrypt_key_id! . This way, I'm more or less forcing GnuPG to attempt using that key, which is an encryption subkey. This unfortunately still fails in the initramfs setting. When I run my script from the operating system, it works as planned. In initramfs, it doesn't work. My next step will be to do something really janky: split my secring.gpg into multiple secret keyrings, each containing only a single stub for the key required, and then switch GnuPG's keyring using --secret-keyring to the keyring which contains only the encryption key requested. This should *hopefully* solve the problem, but I hope you can see how ridiculous this is. I've tested my script in a running OS with all three of my hardware smart cards and decryption works as expected. I'm not certain why GnuPG (1.4.18) is functioning differently in an initramfs setting than in the normal OS, but it is. I've attached my script to this email. The script is decidedly *not* working, but hopefully I can hack a workaround by using different secret ring files. Thanks, - Naftuli Tzvi On Tue, Jun 9, 2015 at 12:26 PM, Naftuli Tzvi Kay wrote: > Thank goodness! I'm glad I was on to something here, moreso glad that I'm > not hearing "it's not a bug, it's a feature?" as is unfortunately common to > hear these days. > > I've yet to try using the --try-all-secrets in --batch mode, I'm not sure > if that will help remedy the problem. Do note that I'm using GnuPG 1, as > it's in an initramfs setting. Would that setting help remedy the problem in > the interrim? > > I don't know what my options are in initramfs for using GnuPG without > piping the password in with the cryptsetup askpass command; I assume that > askpass does some magic to grab keyboard input that the gpg binary itself > probably wouldn't be able to do. If I'm able to get gpg working > interactively instead of reading the passphrase from STDIN, I can just > endure having to press 'c' several times until everything is right in the > world and it finds the right decryption key in hardware. > > Thanks, > - Naftuli Tzvi > > On Tue, Jun 9, 2015 at 5:57 AM, NIIBE Yutaka wrote: > >> Hello, >> >> Thank you for detailed report. It helps me a lot to understand your >> situation. >> >> Let me explain current GnuPG implementation. >> >> Basically, current implementation processes OpenPGP packets one by >> one. >> >> On 06/09/2015 07:16 AM, Naftuli Tzvi Kay wrote: >> > The process it seems to use is like this: >> > >> > 1. Check if $ENC_SUBKEY_A's secret key is present: it's not. >> > 2. Complain about the card not being present: >> > Please remove the current card and insert the one with serial >> number: >> > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX >> > Hit return when ready or enter 'c' to cancel >> > 3. Hit c until it gets to the right key and prompts for the smart >> > card PIN. This can take a while, as I have 3 cards per identity. >> >> Correct. Note that this behavior is not for smartcard only, it also >> applies to private keys on file system. >> >> > What it /should/ do is this: >> > >> > 1. Examine the file and determine which keys can decrypt it. _If_ a >> > smart card is present _and_ the smart card's secret key stub in >> > secring.gpg can decrypt the file, immediately defer to using that >> > card. >> > 2. If no card is present or the file is --hidden-recipient, try >> > decrypting with any present keys in the keyring whose smart card is >> > present. >> > 3. If there are no present keys, the present key can't decrypt the >> > file, or the present key failed to decrypt the file, then start >> > prompting to "insert the key known as ...". >> >> Yes, I agree. >> >> From the implementation viewpoint, it will be something like: >> >> (1) gpg frontend parses all packets for ESK (Encrypted Session Key) >> sequence. >> >> (2) Then, talks to gpg-agent for available private keys to decide >> which private key to decrypt. >> >> (3) Asks gpg-agent to decrypt. >> -- >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: decrypt_yubikey Type: application/octet-stream Size: 1866 bytes Desc: not available URL: From bernhard at intevation.de Fri Jul 3 10:54:11 2015 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 3 Jul 2015 10:54:11 +0200 Subject: FAQ: which keyserver to use? keys.gnupg.org Message-ID: <201507031054.16933.bernhard@intevation.de> Hi Robert, thanks for maintaining the FAQ! My suggestion for improvement is to mention keys.gnupg.net as a certserver and also mention that because of the round robin method, someone will sometimes end up with a certserver that is temporarily out of order. I got the question again in the Gpg4win Forum and within Intevation I get question for nonworking certservers sometimes and DNS takes a while to hand over a different one. BTW: It would be cool to have a page to link to that explains how the service keys.gnupg.net is run. (There is only a small section in https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html that I've found ) Best, Bernhard -- www.intevation.de/~bernhard (CEO) www.fsfe.org (Founding GA Member) Intevation GmbH, Osnabr?ck, Germany; Amtsgericht Osnabr?ck, HRB 18998 Owned and run by Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From gniibe at fsij.org Fri Jul 3 11:36:46 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 03 Jul 2015 18:36:46 +0900 Subject: [TESTING] Curve25519 encryption support Message-ID: <559657AE.2050900@fsij.org> Hello, Here is a patch I am testing for Curve25519 encryption support (which requires libgcrypt change for Curve25519). I tested (1) key generation, (2) encryption, and (3) decryption. There are things we need to decide: OID, algo ID, and format. Currently, I use: OID: 1.3.6.1.4.1.3029.1.5.1 algo ID: ECC = 18 (not 22 nor 23) Public key OpenPGP format: prefix 0x40 and native little endian Libgcrypt SEXP format: Use (flags eddsa) to specify prefix 0x40 and native little endian It works for me, but the code is not mature enough. diff --git a/common/openpgp-oid.c b/common/openpgp-oid.c index 7a75801..92622ce 100644 --- a/common/openpgp-oid.c +++ b/common/openpgp-oid.c @@ -45,6 +45,7 @@ static struct { const char *alias; /* NULL or alternative name of the curve. */ } oidtable[] = { + { "Curve25519", "1.3.6.1.4.1.3029.1.5.1", 255, "curve25519" }, { "Ed25519", "1.3.6.1.4.1.11591.15.1", 255, "ed25519" }, { "NIST P-256", "1.2.840.10045.3.1.7", 256, "nistp256" }, @@ -65,6 +66,10 @@ static struct { static const char oid_ed25519[] = { 0x09, 0x2b, 0x06, 0x01, 0x04, 0x01, 0xda, 0x47, 0x0f, 0x01 }; +/* The OID for Curve25519 in OpenPGP format. */ +static const char oid_curve25519[] = + { 0x0a, 0x2b, 0x06, 0x01, 0x04, 0x01, 0x97, 0x55, 0x01, 0x05, 0x01 }; + /* Helper for openpgp_oid_from_str. */ static size_t @@ -291,6 +296,22 @@ openpgp_oid_is_ed25519 (gcry_mpi_t a) } +int +openpgp_oid_is_curve25519 (gcry_mpi_t a) +{ + const unsigned char *buf; + unsigned int nbits; + size_t n; + + if (!a || !gcry_mpi_get_flag (a, GCRYMPI_FLAG_OPAQUE)) + return 0; + + buf = gcry_mpi_get_opaque (a, &nbits); + n = (nbits+7)/8; + return (n == DIM (oid_curve25519) + && !memcmp (buf, oid_curve25519, DIM (oid_curve25519))); +} + /* Map the Libgcrypt ECC curve NAME to an OID. If R_NBITS is not NULL store the bit size of the curve there. Returns NULL for unknown diff --git a/common/util.h b/common/util.h index b92d78c..2851cfd 100644 --- a/common/util.h +++ b/common/util.h @@ -318,6 +318,7 @@ size_t percent_unescape_inplace (char *string, int nulrepl); gpg_error_t openpgp_oid_from_str (const char *string, gcry_mpi_t *r_mpi); char *openpgp_oid_to_str (gcry_mpi_t a); int openpgp_oid_is_ed25519 (gcry_mpi_t a); +int openpgp_oid_is_curve25519 (gcry_mpi_t a); const char *openpgp_curve_to_oid (const char *name, unsigned int *r_nbits); const char *openpgp_oid_to_curve (const char *oid); const char *openpgp_enum_curves (int *idxp); diff --git a/g10/ecdh.c b/g10/ecdh.c index 9576a1c..a1b7ecf 100644 --- a/g10/ecdh.c +++ b/g10/ecdh.c @@ -134,9 +134,12 @@ pk_ecdh_encrypt_with_shared_point (int is_encrypt, gcry_mpi_t shared_mpi, } secret_x_size = (nbits+7)/8; - assert (nbytes > secret_x_size); - memmove (secret_x, secret_x+1, secret_x_size); - memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); + assert (nbytes >= secret_x_size); + if ((nbytes & 1)) + /* Remove the "04" prefix of non-compressed format. */ + memmove (secret_x, secret_x+1, secret_x_size); + if (nbytes - secret_x_size) + memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); if (DBG_CRYPTO) log_printhex ("ECDH shared secret X is:", secret_x, secret_x_size ); diff --git a/g10/keygen.c b/g10/keygen.c index 796d18f..3eb8e73 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -1520,6 +1520,13 @@ gen_ecc (int algo, const char *curve, kbnode_t pub_root, (((keygen_flags & KEYGEN_FLAG_TRANSIENT_KEY) && (keygen_flags & KEYGEN_FLAG_NO_PROTECTION))? " transient-key" : "")); + else if (algo == PUBKEY_ALGO_ECDH && !strcmp (curve, "Curve25519")) + keyparms = xtryasprintf + ("(genkey(ecc(curve %zu:%s)(flags eddsa comp%s)))", + strlen (curve), curve, + (((keygen_flags & KEYGEN_FLAG_TRANSIENT_KEY) + && (keygen_flags & KEYGEN_FLAG_NO_PROTECTION))? + " transient-key" : "")); else keyparms = xtryasprintf ("(genkey(ecc(curve %zu:%s)(flags nocomp%s)))", @@ -2125,7 +2132,7 @@ ask_keysize (int algo, unsigned int primary_keysize) function may adjust. Returns a malloced string with the name of the curve. BOTH tells that gpg creates a primary and subkey. */ static char * -ask_curve (int *algo, int both) +ask_curve (int *algo, int *subkey_algo) { struct { const char *name; @@ -2176,7 +2183,7 @@ ask_curve (int *algo, int both) continue; if (!gcry_pk_get_curve (keyparms, 0, NULL)) continue; - if (both && curves[idx].fix_curve) + if (subkey_algo && curves[idx].fix_curve) { /* Both Curve 25519 keys are to be created. Check that Libgcrypt also supports the real Curve25519. */ @@ -2241,6 +2248,11 @@ ask_curve (int *algo, int both) if ((*algo == PUBKEY_ALGO_ECDSA || *algo == PUBKEY_ALGO_EDDSA) && curves[idx].fix_curve) { + if (subkey_algo && *subkey_algo == PUBKEY_ALGO_ECDSA) + { + *subkey_algo = PUBKEY_ALGO_EDDSA; + result = xstrdup ("Ed25519"); + } *algo = PUBKEY_ALGO_EDDSA; result = xstrdup ("Ed25519"); } @@ -3672,7 +3684,7 @@ generate_keypair (ctrl_t ctrl, int full, const char *fname, || algo == PUBKEY_ALGO_EDDSA || algo == PUBKEY_ALGO_ECDH) { - curve = ask_curve (&algo, both); + curve = ask_curve (&algo, &subkey_algo); r = xmalloc_clear( sizeof *r + 20 ); r->key = pKEYTYPE; sprintf( r->u.value, "%d", algo); @@ -3743,7 +3755,7 @@ generate_keypair (ctrl_t ctrl, int full, const char *fname, || algo == PUBKEY_ALGO_EDDSA || algo == PUBKEY_ALGO_ECDH) { - curve = ask_curve (&algo, 0); + curve = ask_curve (&algo, NULL); nbits = 0; r = xmalloc_clear (sizeof *r + strlen (curve)); r->key = pKEYCURVE; @@ -4292,7 +4304,7 @@ generate_subkeypair (ctrl_t ctrl, kbnode_t keyblock) else if (algo == PUBKEY_ALGO_ECDSA || algo == PUBKEY_ALGO_EDDSA || algo == PUBKEY_ALGO_ECDH) - curve = ask_curve (&algo, 0); + curve = ask_curve (&algo, NULL); else nbits = ask_keysize (algo, 0); diff --git a/g10/keyid.c b/g10/keyid.c index 90d982e..cfdf29d 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -761,12 +761,20 @@ keygrip_from_pk (PKT_public_key *pk, unsigned char *array) case PUBKEY_ALGO_ECDH: { char *curve = openpgp_oid_to_str (pk->pkey[0]); + if (!curve) err = gpg_error_from_syserror (); else { + int with_eddsa_flag = 0; + + if (pk->pubkey_algo == PUBKEY_ALGO_EDDSA + || (pk->pubkey_algo == PUBKEY_ALGO_ECDH + && openpgp_oid_is_curve25519 (pk->pkey[0]))) + with_eddsa_flag = 1; + err = gcry_sexp_build (&s_pkey, NULL, - pk->pubkey_algo == PUBKEY_ALGO_EDDSA ? + with_eddsa_flag ? "(public-key(ecc(curve%s)(flags eddsa)(q%m)))" : "(public-key(ecc(curve%s)(q%m)))", curve, pk->pkey[1]); diff --git a/g10/misc.c b/g10/misc.c index 9134b28..8f2d379 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -612,11 +612,11 @@ openpgp_pk_algo_usage ( int algo ) use = PUBKEY_USAGE_ENC; break; case PUBKEY_ALGO_DSA: + case PUBKEY_ALGO_ECDSA: use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG | PUBKEY_USAGE_AUTH; break; - case PUBKEY_ALGO_ECDSA: case PUBKEY_ALGO_EDDSA: - use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG | PUBKEY_USAGE_AUTH; + use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH; default: break; } diff --git a/g10/pkglue.c b/g10/pkglue.c index d72275b..e543ceb 100644 --- a/g10/pkglue.c +++ b/g10/pkglue.c @@ -228,9 +228,13 @@ pk_encrypt (pubkey_algo_t algo, gcry_mpi_t *resarr, gcry_mpi_t data, rc = gpg_error_from_syserror (); else { + int with_eddsa_flag = openpgp_oid_is_curve25519 (pkey[0]); + /* Now use the ephemeral secret to compute the shared point. */ rc = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecdh(curve%s)(q%m)))", + with_eddsa_flag ? + "(public-key(ecdh(curve%s)(flags eddsa)(q%m)))" + : "(public-key(ecdh(curve%s)(q%m)))", curve, pkey[1]); xfree (curve); /* Put K into a simplified S-expression. */ diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c index cb834af..fd7f812 100644 --- a/g10/pubkey-enc.c +++ b/g10/pubkey-enc.c @@ -250,8 +250,8 @@ get_it (PKT_pubkey_enc *enc, DEK *dek, PKT_public_key *sk, u32 *keyid) if(err) goto leave; - /* Reuse NFRAME, which size is sufficient to include the session key. */ - err = gcry_mpi_print (GCRYMPI_FMT_USG, frame, nframe, &nframe, decoded); + xfree (frame); + err = gcry_mpi_aprint (GCRYMPI_FMT_USG, &frame, &nframe, decoded); mpi_release (decoded); if (err) goto leave; -- From wk at gnupg.org Fri Jul 3 17:41:45 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 03 Jul 2015 17:41:45 +0200 Subject: [PATCH] drop long-deprecated gpgsm-gencert.sh In-Reply-To: <1435864249-11439-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 2 Jul 2015 15:10:49 -0400") References: <1435864249-11439-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87a8vdp7t2.fsf@vigenere.g10code.de> On Thu, 2 Jul 2015 21:10, dkg at fifthhorseman.net said: > * tools/gpgsm-gencert.sh: remove deprecated script entirely. It is > fully replaced by gpgsm --gen-key Okay. Someone - please push it. Salam-Shalom, Werner p.s. I had mail problems the last two days but meanwhile the disk has been replaced an all is fine again. However, I am leaving for summer holidays now (coincidently the heat took over my office only today). -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Fri Jul 3 22:22:30 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 03 Jul 2015 22:22:30 +0200 Subject: [PATCH] drop long-deprecated gpgsm-gencert.sh In-Reply-To: <87a8vdp7t2.fsf@vigenere.g10code.de> References: <1435864249-11439-1-git-send-email-dkg@fifthhorseman.net> <87a8vdp7t2.fsf@vigenere.g10code.de> Message-ID: <87h9plout5.wl-neal@walfield.org> At Fri, 03 Jul 2015 17:41:45 +0200, Werner Koch wrote: > > On Thu, 2 Jul 2015 21:10, dkg at fifthhorseman.net said: > > * tools/gpgsm-gencert.sh: remove deprecated script entirely. It is > > fully replaced by gpgsm --gen-key > > Okay. Someone - please push it. Pushed. Neal From neal at walfield.org Fri Jul 3 22:24:26 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 03 Jul 2015 22:24:26 +0200 Subject: RMLL Message-ID: <87fv55oupx.wl-neal@walfield.org> Hi, I'm going to be at RMLL next week. Specifically, I'll be there from Monday through Thursday afternoon. On Monday afternoon, I'm going to give a talk called "An Advanced Introduction to GnuPG". (I'll also be giving a talk about ZFS on Monday.) If anyone is around and would like to meet up, please drop me an email. :) Neal From gnupg-devel at spodhuis.org Sat Jul 4 22:35:16 2015 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Sat, 4 Jul 2015 20:35:16 +0000 Subject: FAQ: which keyserver to use? keys.gnupg.org In-Reply-To: <201507031054.16933.bernhard@intevation.de> References: <201507031054.16933.bernhard@intevation.de> Message-ID: <20150704203516.GA98118@tower.spodhuis.org> On 2015-07-03 at 10:54 +0200, Bernhard Reiter wrote: > BTW: It would be cool to have a page to link to that explains > how the service keys.gnupg.net is run. (There is only > a small section in > https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html > that I've found ) (I can't speak for anyone but me; my position is as a keyserver operator who debugs problems for others; I also wrote the main doc on what's needed to get up and running with a keyserver which peers with others) The `keys.gnupg.net` hostname is an alias maintained by the GnuPG developers, so that they can point it at any service of their choosing and have clients which use the defaults be updated. This way, they have maximum flexibility to do what they think best for their user-base. At this time, the alias (DNS CNAME) points to a pool hostname maintained by Kristian Fiskerstrand, with DNS secondarying provided by volunteers. You can find more information about this pool at: https://sks-keyservers.net/ The main PGP keyserver implementation "peers" with others, to spread keys via a gossip system, and exports information to let you see which others it talks to, so it's possible to spider across all the keyservers in a mutually-reachable set. Pool software does just this, collecting public information and including the keyservers run by volunteers and filtering according to various criteria. Kristian lists the various pools and the criteria for each, for the pools he runs. Anyone can run their own pool: it's only a collection of DNS entries pointing to servers. (Exclusion from public pools currently requires manual requests, there's a proposal to have an exported status flag to request to be excluded automatically). If you want more chance of having each key request be answered without error, use `ha.pool.sks-keyservers.net` which requires that each keyserver IP be a cluster of servers with a reverse proxy in front. https://sks-keyservers.net/overview-of-pools.php -Phil From diafygi at gmail.com Mon Jul 6 04:16:14 2015 From: diafygi at gmail.com (Daniel Roesler) Date: Sun, 5 Jul 2015 19:16:14 -0700 Subject: [Sks-devel] Analyzing key server data In-Reply-To: <1435915384.20594.8.camel@cryptobitch.de> References: <20150322125848.218ee839@pc1> <1435915384.20594.8.camel@cryptobitch.de> Message-ID: Hmmm, I maintain openpgp-python and was able convert a full dump to json about two months ago. Perhaps one of the recent updates broke things? Do you have a particular public key that raises an Exception? Daniel On Fri, Jul 3, 2015 at 2:23 AM, Tobias Mueller wrote: > Hi Hanno! > > On So, 2015-03-22 at 12:58 +0100, Hanno B?ck wrote: >> Code: >> https://github.com/hannob/pgpecosystem >> > This is great work, thanks. > > I tried to parse SKS dumps in the past, but I failed miserably, using > python-openpgp. > I'm looking forward to seeing your implementation. > > Have you seen the Analysing the Web of Trust paper? > http://link.springer.com/chapter/10.1007/978-3-642-23822-2_27 > http://dl.acm.org/citation.cfm?id=844108 > > There is also . > > Cheers, > Tobi > > > _______________________________________________ > Sks-devel mailing list > Sks-devel at nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel From Alexander.Strobel at giepa.de Mon Jul 6 16:35:52 2015 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Mon, 6 Jul 2015 16:35:52 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <559A3484.4020800@rundquadrat.at> References: <559A3484.4020800@rundquadrat.at> Message-ID: <559A9248.60202@giepa.de> Am 06.07.2015 um 09:55 schrieb Stefan Selbitschka: > I split my implementation in three kind of headers "headers to > secure", "headers to remove" and "headers to replace". While the > first headers are put into the rfc822-headers part(s) the second > group are removed from message headers and the last group of headers > is set to a default value like "subject => "encrypted message". > Question are: > Should we remove headers? > Should one or both be a user choice or do we deicide? > ... Does "headers to remove" mean that they are stripped from the email completely? Even as I can understand the intention to do something lkike this, I think this might be something which some MUAs arent able to realize. I would not prefer such an explizit blacklisting. > For the UI representation of protected headers I would make a green > background for header fields that are protected and not manipulated, a > red background if they are manipulated and standard transparent if a > headers is not protected. Using colors to communicate ok/error states is common, but bad usabilty in my opinion. As colors might be displayed wrong (if you don't use something like web safe colors), there are some people outside which are color blind or live in a culture where the meaning of a color is different from our understanding. Because of this I would prefer icons and/or a textual representation. > Do we implement this for PGP/MIME and Inline? > > My assumption in April was that we implement this only for PGP/MIME > but since some of us like gpg4o can only to inline-pgp, I think we > should do both. Is there a agreed MIME structure for the inline case > or do we just use the same? To implement this for PGP/MIME was our understanding too. We are able to read PGP/MIME without problems. Creating RFC conform PGP/MIME in contrast _is_ a problem for us, as Outlook/Exchange inserts an empty MIME part and destroys the content-type of the email and the first empty MIME part. So you would all help gpg4o, gpg4win, Outlook Privacy Plugin, ... (i.e everyone who has to communicate via MAPI with Outlook/Exchange), when everyone might be able to interpret/read this "PGP/MIME" equivalent. Defining a standard for protected-headers in INLINE messages might help other webbased "clients" like Mailvelope and others to check whether a mail has been modified on its way to the recipient(s). It think it won't be a solution for encryption on these platforms as they don't have access to the source of the emails nor they have (write) access to the email headers. Regards Alex Strobel www.gpg4o.com Am 06.07.2015 um 09:55 schrieb Stefan Selbitschka: > Hi, > > I nearly finished my implementation in R2Mail2 and some questions > arose, I'd like to discuss with you, since I think if we all > implement this without a standard we should to the same ;). > > Which headers are protected? > > I split my implementation in three kind of headers "headers to > secure", "headers to remove" and "headers to replace". While the > first headers are put into the rfc822-headers part(s) the second > group are removed from message headers and the last group of headers > is set to a default value like "subject => "encrypted message". > > In the singed only case removing headers make no sense but in the > encrypted case this could increase security against meta data > analysis. > > At the moment I have following headers in the separate arrays: > HEADERS_TO_SECURE = { "from", "to", "cc", "subject", "message-id", > "references", "x-mailer", "in-reply-to", "reply-to" } > HEADERS_TO_REMOVE = { "references", "x-mailer", in-reply-to", > "reply-to" } HEADERS_TO_REPLACE = { "subject" => "Encrypted Message" > } > > As long as I could see Enigmail didn't remove any headers at the > moment. > > Question are: Should we remove headers? Which headers are protected > and removed or replaces by dummy values? Should one or both be a > user choice or do we deicide? > > > > What is the terminology and UI representation for the user? > > How should we call the settings where we enable/disable the header > protection? "Protect Headers" => Yes/No. > > For the UI representation of protected headers I would make a green > background for header fields that are protected and not manipulated, > a red background if they are manipulated and standard transparent if > a headers is not protected. > > > > Do we implement this for PGP/MIME and Inline? > > My assumption in April was that we implement this only for PGP/MIME > but since some of us like gpg4o can only to inline-pgp, I think we > should do both. Is there a agreed MIME structure for the inline case > or do we just use the same? > > > regards - Stefan > > > From diafygi at gmail.com Mon Jul 6 17:22:48 2015 From: diafygi at gmail.com (Daniel Roesler) Date: Mon, 6 Jul 2015 08:22:48 -0700 Subject: [Sks-devel] Analyzing key server data In-Reply-To: References: <20150322125848.218ee839@pc1> <1435915384.20594.8.camel@cryptobitch.de> Message-ID: Ok, just confirmed that openpgp-python can still parse the pool. Do you have a public key that throws an exception? https://research.daylightpirates.org/sks-dumps/2015-07-06/json/ NOTE: Each file contains 10,000 rows of json objects (1 for each public key). Daniel On Sun, Jul 5, 2015 at 7:16 PM, Daniel Roesler wrote: > Hmmm, I maintain openpgp-python and was able convert a full dump to > json about two months ago. Perhaps one of the recent updates broke > things? Do you have a particular public key that raises an Exception? > > Daniel > > On Fri, Jul 3, 2015 at 2:23 AM, Tobias Mueller wrote: >> Hi Hanno! >> >> On So, 2015-03-22 at 12:58 +0100, Hanno B?ck wrote: >>> Code: >>> https://github.com/hannob/pgpecosystem >>> >> This is great work, thanks. >> >> I tried to parse SKS dumps in the past, but I failed miserably, using >> python-openpgp. >> I'm looking forward to seeing your implementation. >> >> Have you seen the Analysing the Web of Trust paper? >> http://link.springer.com/chapter/10.1007/978-3-642-23822-2_27 >> http://dl.acm.org/citation.cfm?id=844108 >> >> There is also . >> >> Cheers, >> Tobi >> >> >> _______________________________________________ >> Sks-devel mailing list >> Sks-devel at nongnu.org >> https://lists.nongnu.org/mailman/listinfo/sks-devel From dkg at fifthhorseman.net Mon Jul 6 21:48:12 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 06 Jul 2015 15:48:12 -0400 Subject: Pinentry: secure memory In-Reply-To: <87381r29tj.wl-neal@walfield.org> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> <87381r29tj.wl-neal@walfield.org> Message-ID: <878uatm5j7.fsf@alice.fifthhorseman.net> On Tue 2015-06-16 07:04:40 -0400, Neal H. Walfield wrote: > This raises another question: do the secure widgets actually increase > security? Recall our threat model is someone reading the password > from swap. Is swap the only reason to use the secure memory? Defending against memory being written to non-volatile storage or readable from outside the machine is increasingly difficult in this age of hibernated and virtualized systems. furthermore, there are other kinds of attack (like spoofing pinentry or gpg-agent itself) that locked memory does nothing to prevent. So I'm not convinced the tradeoff for secure memory is worthwhile. If you're relying on graphical toolkits, you end up relying on the toolkits to do the right thing anyway. depending on native implementations for visually-integrated UI seems like it might be a better approach, both for usability and for security. --dkg From diafygi at gmail.com Mon Jul 6 23:13:09 2015 From: diafygi at gmail.com (Daniel Roesler) Date: Mon, 6 Jul 2015 14:13:09 -0700 Subject: [Sks-devel] Analyzing key server data In-Reply-To: <20150706204048.GN3665@cryptobitch.de> References: <20150322125848.218ee839@pc1> <1435915384.20594.8.camel@cryptobitch.de> <20150706204048.GN3665@cryptobitch.de> Message-ID: Here's what I got with openpgp-python[1]. Seems to parse fine, though I haven't added signature validation yet. https://paste.ee/p/2NDMF Daniel [1]: python openpgp.py -m ~/Desktop/3A6CED98.asc | python -c "import json, sys; print json.dumps(json.loads(sys.stdin.read()), indent=4, sort_keys=True)" > ~/Desktop/3A6CED98.asc.pretty.json On Mon, Jul 6, 2015 at 1:40 PM, Tobias Mueller wrote: > Hi! > > On Mon, Jul 06, 2015 at 08:22:48AM -0700, Daniel Roesler wrote: >> Ok, just confirmed that openpgp-python can still parse the pool. > Cool! Thanks for that. > >> Do you have a public key that throws an exception? > I tried a couple of years back: > http://lists.nongnu.org/archive/html/sks-devel/2012-06/msg00025.html > > Cheers, > Tobi From dkg at fifthhorseman.net Tue Jul 7 01:29:28 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 06 Jul 2015 19:29:28 -0400 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <559A9248.60202@giepa.de> References: <559A3484.4020800@rundquadrat.at> <559A9248.60202@giepa.de> Message-ID: <877fqclvaf.fsf@alice.fifthhorseman.net> Hi Alexander-- On Mon 2015-07-06 10:35:52 -0400, Alexander Strobel wrote: > Does "headers to remove" mean that they are stripped from the email > completely? Even as I can understand the intention to do something lkike > this, I think this might be something which some MUAs arent able to > realize. I would not prefer such an explizit blacklisting. i think the headers to remove will ultimately be up to the preferences (and capabilities) of the MUAs in question, but having a set of guidelines about what headers people generally prefer to drop entirely would be useful. there are RFC 822 constraints about headers which must be present that MUAs wouldn't want to get rid of, of course. > Using colors to communicate ok/error states is common, but bad usabilty > in my opinion. As colors might be displayed wrong (if you don't use > something like web safe colors), there are some people outside which are > color blind or live in a culture where the meaning of a color is > different from our understanding. > Because of this I would prefer icons and/or a textual representation. regardless of the use of color, we need a consistent textual representation, for when people trigger help text or other "tell me more about..." UI. I generally agree with Alexander that color is a bad thing to rely on, though. > To implement this for PGP/MIME was our understanding too. We are able to > read PGP/MIME without problems. Creating RFC conform PGP/MIME in > contrast _is_ a problem for us, as Outlook/Exchange inserts an empty > MIME part and destroys the content-type of the email and the first empty > MIME part. I've seen this problem listed before in several places. Is this documented someplace? is Microsoft aware of this as a bug? is there a way that Microsoft customers can agitate for it to be fixed? PGP/MIME is pretty important as a mechanism for making semantically unambiguous e-mail message signatures (and encrypted e-mails, for that matter). > Defining a standard for protected-headers in INLINE messages might help > other webbased "clients" like Mailvelope I think mailvelope has switched to PGP/MIME. --dkg From patrick at enigmail.net Tue Jul 7 03:32:37 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Mon, 6 Jul 2015 21:32:37 -0400 Subject: Fwd: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <559A7EA6.8050403@rundquadrat.at> References: <559A7EA6.8050403@rundquadrat.at> Message-ID: <559B2C35.5050306@enigmail.net> For some unknown reason, Stefan cannot post to the mailing list; I'm forwarding the mail below on his behalf. -Patrick -------- Forwarded Message -------- Subject: Memory Hole discussion / OpenPGP e-mail header protection Date: Mon, 06 Jul 2015 09:52:21 +0200 From: Stefan Selbitschka To: GnuPG Development List CC: Patrick Brunschwig , Bjarni Runar Einarsson , alexander.strobel at giepa.de Hi, I nearly finished my implementation in R2Mail2 and some questions arose, I'd like to discuss with you, since I think if we all implement this without a standard we should to the same ;). Which headers are protected? I split my implementation in three kind of headers "headers to secure", "headers to remove" and "headers to replace". While the first headers are put into the rfc822-headers part(s) the second group are removed from message headers and the last group of headers is set to a default value like "subject => "encrypted message". In the singed only case removing headers make no sense but in the encrypted case this could increase security against meta data analysis. At the moment I have following headers in the separate arrays: HEADERS_TO_SECURE = { "from", "to", "cc", "subject", "message-id", "references", "x-mailer", "in-reply-to", "reply-to" } HEADERS_TO_REMOVE = { "references", "x-mailer", in-reply-to", "reply-to" } HEADERS_TO_REPLACE = { "subject" => "Encrypted Message" } As long as I could see Enigmail didn't remove any headers at the moment. Question are: Should we remove headers? Which headers are protected and removed or replaces by dummy values? Should one or both be a user choice or do we deicide? What is the terminology and UI representation for the user? How should we call the settings where we enable/disable the header protection? "Protect Headers" => Yes/No. For the UI representation of protected headers I would make a green background for header fields that are protected and not manipulated, a red background if they are manipulated and standard transparent if a headers is not protected. Do we implement this for PGP/MIME and Inline? My assumption in April was that we implement this only for PGP/MIME but since some of us like gpg4o can only to inline-pgp, I think we should do both. Is there a agreed MIME structure for the inline case or do we just use the same? regards - Stefan From dkg at fifthhorseman.net Tue Jul 7 15:16:41 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 7 Jul 2015 09:16:41 -0400 Subject: [PATCH] clarify constraints on who modifies files in ~/.gnupg Message-ID: <1436275001-32684-1-git-send-email-dkg@fifthhorseman.net> --- doc/gpg.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/gpg.texi b/doc/gpg.texi index 6c5cc5d..c0632b3 100644 --- a/doc/gpg.texi +++ b/doc/gpg.texi @@ -2943,7 +2943,7 @@ helper script is provided to create these files (@pxref{addgnupghome}). For internal purposes @command{@gpgname} creates and maintains a few other files; They all live in in the current home directory (@pxref{option ---homedir}). Only the @command{@gpgname} may modify these files. +--homedir}). Only the @command{@gpgname} program may modify these files. @table @file -- 2.1.4 From dkg at fifthhorseman.net Tue Jul 7 18:00:16 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 7 Jul 2015 12:00:16 -0400 Subject: [PATCH] improve documentation about VALIDSIG Message-ID: <1436284816-5796-1-git-send-email-dkg@fifthhorseman.net> * doc/DETAILS: improve documentation about VALIDSIG -- the claim that VALIDSIG is the same as GOODSIG is simply wrong. Attempt to clarify it. Also, the paragraph about primary-key-fpr and sig-version was weirdly re-ordered during the org-mode conversion in 65eb98966a569a91c97d0c23ba5582a9a7558de0; repair it. Signed-off-by: Daniel Kahn Gillmor --- doc/DETAILS | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/doc/DETAILS b/doc/DETAILS index d1f7394..23a5420 100644 --- a/doc/DETAILS +++ b/doc/DETAILS @@ -408,12 +408,15 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: - - [ ] - This status indicates that the signature is good. This is the same - as GOODSIG but has the fingerprint as the argument. Both status - lines are emitted for a good signature. All arguments here are on - one long line. sig-timestamp is the signature creation time in - seconds after the epoch. expire-timestamp is the signature - expiration time in seconds after the epoch (zero means "does not + This status indicates that the signature is cryptographically + valid. This similar to GOODSIG or EXPSIG or EXPKEYSIG or REVSIG + (depending on the date and the state of the signature and signing + key) but has the fingerprint as the argument. Multiple status + lines (VALIDSIG and the other appropriate *SIG status) are emitted + for a valid signature. All arguments here are on one long line. + sig-timestamp is the signature creation time in seconds after the + epoch. expire-timestamp is the signature expiration time in + seconds after the epoch (zero means "does not expire"). sig-version, pubkey-algo, hash-algo, and sig-class (a 2-byte hex value) are all straight from the signature packet. PRIMARY-KEY-FPR is the fingerprint of the primary key or identical @@ -421,8 +424,8 @@ pkd:0:1024:B665B1435F4C2 .... FF26ABB: key without running gpg again for this purpose. The primary-key-fpr parameter is used for OpenPGP and not - class is not defined for CMS and currently set to 0 and 00. available for CMS signatures. The sig-version as well as the sig + class is not defined for CMS and currently set to 0 and 00. Note, that *-TIMESTAMP may either be a number of seconds since Epoch or an ISO 8601 string which can be detected by the presence -- 2.1.4 From gniibe at fsij.org Wed Jul 8 02:42:30 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 08 Jul 2015 09:42:30 +0900 Subject: [TESTING] Curve25519 encryption support (update) In-Reply-To: <559657AE.2050900@fsij.org> References: <559657AE.2050900@fsij.org> Message-ID: <559C71F6.1070607@fsij.org> Hello, Here is a patch I am testing for Curve25519 encryption support (which requires libgcrypt change for Curve25519, and Gnuk master branch). I tested: (1) key generation (2) encryption (3) decryption (4) keytocard (5) asking decryption on card There are things we need to decide: OID, algo ID, and format. Currently, I use: OID: 1.3.6.1.4.1.3029.1.5.1 algo ID: ECC = 18 (not 22 nor 23) Public key OpenPGP format: prefix 0x40 and native little endian Libgcrypt SEXP format: Use (flags eddsa) to specify DJB format/processing (flags comp) for prefix 0x40 It works for me, but the code is not mature enough. diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c index 562179b..34c942b 100644 --- a/agent/cvt-openpgp.c +++ b/agent/cvt-openpgp.c @@ -83,14 +83,29 @@ get_keygrip (int pubkey_algo, const char *curve, gcry_mpi_t *pkey, case GCRY_PK_ECC: if (!curve) err = gpg_error (GPG_ERR_BAD_SECKEY); - else if (!strcmp (curve, openpgp_curve_to_oid ("Ed25519", NULL))) - err = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecc(curve %s)(flags eddsa)(q%m)))", - "Ed25519", pkey[0]); else - err = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecc(curve %s)(q%m)))", - curve, pkey[0]); + { + int with_eddsa_flag = 0; + const char *curve_name; + + curve_name = "Ed25519"; + if (!strcmp (curve, openpgp_curve_to_oid (curve_name, NULL))) + with_eddsa_flag = 1; + else + { + curve_name = "Curve25519"; + if (!strcmp (curve, openpgp_curve_to_oid (curve_name, NULL))) + with_eddsa_flag = 1; + } + if (with_eddsa_flag) + err = gcry_sexp_build (&s_pkey, NULL, + "(public-key(ecc(curve %s)(flags eddsa)(q%m)))", + curve_name, pkey[0]); + else + err = gcry_sexp_build (&s_pkey, NULL, + "(public-key(ecc(curve %s)(q%m)))", + curve, pkey[0]); + } break; default: @@ -146,19 +161,32 @@ convert_secret_key (gcry_sexp_t *r_key, int pubkey_algo, gcry_mpi_t *skey, case GCRY_PK_ECC: if (!curve) err = gpg_error (GPG_ERR_BAD_SECKEY); - else if (!strcmp (curve, openpgp_curve_to_oid ("Ed25519", NULL))) + else { - /* Do not store the OID as name but the real name and the - EdDSA flag. */ - err = gcry_sexp_build (&s_skey, NULL, - "(private-key(ecc(curve%s)(flags eddsa)" - "(q%m)(d%m)))", - "Ed25519", skey[0], skey[1]); + int with_eddsa_flag = 0; + const char *curve_name; + + curve_name = "Ed25519"; + if (!strcmp (curve, openpgp_curve_to_oid (curve_name, NULL))) + with_eddsa_flag = 1; + else + { + curve_name = "Curve25519"; + if (!strcmp (curve, openpgp_curve_to_oid (curve_name, NULL))) + with_eddsa_flag = 1; + } + if (with_eddsa_flag) + /* Do not store the OID as name but the real name and the + EdDSA flag. */ + err = gcry_sexp_build (&s_skey, NULL, + "(private-key(ecc(curve%s)(flags eddsa)" + "(q%m)(d%m)))", + "Ed25519", skey[0], skey[1]); + else + err = gcry_sexp_build (&s_skey, NULL, + "(private-key(ecc(curve%s)(q%m)(d%m)))", + curve, skey[0], skey[1]); } - else - err = gcry_sexp_build (&s_skey, NULL, - "(private-key(ecc(curve%s)(q%m)(d%m)))", - curve, skey[0], skey[1]); break; default: @@ -216,22 +244,35 @@ convert_transfer_key (gcry_sexp_t *r_key, int pubkey_algo, gcry_mpi_t *skey, case GCRY_PK_ECC: if (!curve) err = gpg_error (GPG_ERR_BAD_SECKEY); - else if (!strcmp (curve, openpgp_curve_to_oid ("Ed25519", NULL))) + else { - /* Do not store the OID as name but the real name and the - EdDSA flag. */ - err = gcry_sexp_build - (&s_skey, NULL, - "(protected-private-key(ecc(curve%s)(flags eddsa)(q%m)" - "(protected openpgp-native%S)))", - "Ed25519", skey[0], transfer_key); + int with_eddsa_flag = 0; + const char *curve_name; + + curve_name = "Ed25519"; + if (!strcmp (curve, openpgp_curve_to_oid (curve_name, NULL))) + with_eddsa_flag = 1; + else + { + curve_name = "Curve25519"; + if (!strcmp (curve, openpgp_curve_to_oid (curve_name, NULL))) + with_eddsa_flag = 1; + } + if (with_eddsa_flag) + /* Do not store the OID as name but the real name and the + EdDSA flag. */ + err = gcry_sexp_build + (&s_skey, NULL, + "(protected-private-key(ecc(curve%s)(flags eddsa)(q%m)" + "(protected openpgp-native%S)))", + curve_name, skey[0], transfer_key); + else + err = gcry_sexp_build + (&s_skey, NULL, + "(protected-private-key(ecc(curve%s)(q%m)" + "(protected openpgp-native%S)))", + curve, skey[0], transfer_key); } - else - err = gcry_sexp_build - (&s_skey, NULL, - "(protected-private-key(ecc(curve%s)(q%m)" - "(protected openpgp-native%S)))", - curve, skey[0], transfer_key); break; default: diff --git a/common/openpgp-oid.c b/common/openpgp-oid.c index 7a75801..92622ce 100644 --- a/common/openpgp-oid.c +++ b/common/openpgp-oid.c @@ -45,6 +45,7 @@ static struct { const char *alias; /* NULL or alternative name of the curve. */ } oidtable[] = { + { "Curve25519", "1.3.6.1.4.1.3029.1.5.1", 255, "curve25519" }, { "Ed25519", "1.3.6.1.4.1.11591.15.1", 255, "ed25519" }, { "NIST P-256", "1.2.840.10045.3.1.7", 256, "nistp256" }, @@ -65,6 +66,10 @@ static struct { static const char oid_ed25519[] = { 0x09, 0x2b, 0x06, 0x01, 0x04, 0x01, 0xda, 0x47, 0x0f, 0x01 }; +/* The OID for Curve25519 in OpenPGP format. */ +static const char oid_curve25519[] = + { 0x0a, 0x2b, 0x06, 0x01, 0x04, 0x01, 0x97, 0x55, 0x01, 0x05, 0x01 }; + /* Helper for openpgp_oid_from_str. */ static size_t @@ -291,6 +296,22 @@ openpgp_oid_is_ed25519 (gcry_mpi_t a) } +int +openpgp_oid_is_curve25519 (gcry_mpi_t a) +{ + const unsigned char *buf; + unsigned int nbits; + size_t n; + + if (!a || !gcry_mpi_get_flag (a, GCRYMPI_FLAG_OPAQUE)) + return 0; + + buf = gcry_mpi_get_opaque (a, &nbits); + n = (nbits+7)/8; + return (n == DIM (oid_curve25519) + && !memcmp (buf, oid_curve25519, DIM (oid_curve25519))); +} + /* Map the Libgcrypt ECC curve NAME to an OID. If R_NBITS is not NULL store the bit size of the curve there. Returns NULL for unknown diff --git a/common/util.h b/common/util.h index b92d78c..2851cfd 100644 --- a/common/util.h +++ b/common/util.h @@ -318,6 +318,7 @@ size_t percent_unescape_inplace (char *string, int nulrepl); gpg_error_t openpgp_oid_from_str (const char *string, gcry_mpi_t *r_mpi); char *openpgp_oid_to_str (gcry_mpi_t a); int openpgp_oid_is_ed25519 (gcry_mpi_t a); +int openpgp_oid_is_curve25519 (gcry_mpi_t a); const char *openpgp_curve_to_oid (const char *name, unsigned int *r_nbits); const char *openpgp_oid_to_curve (const char *oid); const char *openpgp_enum_curves (int *idxp); diff --git a/g10/ecdh.c b/g10/ecdh.c index 9576a1c..a1b7ecf 100644 --- a/g10/ecdh.c +++ b/g10/ecdh.c @@ -134,9 +134,12 @@ pk_ecdh_encrypt_with_shared_point (int is_encrypt, gcry_mpi_t shared_mpi, } secret_x_size = (nbits+7)/8; - assert (nbytes > secret_x_size); - memmove (secret_x, secret_x+1, secret_x_size); - memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); + assert (nbytes >= secret_x_size); + if ((nbytes & 1)) + /* Remove the "04" prefix of non-compressed format. */ + memmove (secret_x, secret_x+1, secret_x_size); + if (nbytes - secret_x_size) + memset (secret_x+secret_x_size, 0, nbytes-secret_x_size); if (DBG_CRYPTO) log_printhex ("ECDH shared secret X is:", secret_x, secret_x_size ); diff --git a/g10/keygen.c b/g10/keygen.c index 796d18f..3eb8e73 100644 --- a/g10/keygen.c +++ b/g10/keygen.c @@ -1520,6 +1520,13 @@ gen_ecc (int algo, const char *curve, kbnode_t pub_root, (((keygen_flags & KEYGEN_FLAG_TRANSIENT_KEY) && (keygen_flags & KEYGEN_FLAG_NO_PROTECTION))? " transient-key" : "")); + else if (algo == PUBKEY_ALGO_ECDH && !strcmp (curve, "Curve25519")) + keyparms = xtryasprintf + ("(genkey(ecc(curve %zu:%s)(flags eddsa comp%s)))", + strlen (curve), curve, + (((keygen_flags & KEYGEN_FLAG_TRANSIENT_KEY) + && (keygen_flags & KEYGEN_FLAG_NO_PROTECTION))? + " transient-key" : "")); else keyparms = xtryasprintf ("(genkey(ecc(curve %zu:%s)(flags nocomp%s)))", @@ -2125,7 +2132,7 @@ ask_keysize (int algo, unsigned int primary_keysize) function may adjust. Returns a malloced string with the name of the curve. BOTH tells that gpg creates a primary and subkey. */ static char * -ask_curve (int *algo, int both) +ask_curve (int *algo, int *subkey_algo) { struct { const char *name; @@ -2176,7 +2183,7 @@ ask_curve (int *algo, int both) continue; if (!gcry_pk_get_curve (keyparms, 0, NULL)) continue; - if (both && curves[idx].fix_curve) + if (subkey_algo && curves[idx].fix_curve) { /* Both Curve 25519 keys are to be created. Check that Libgcrypt also supports the real Curve25519. */ @@ -2241,6 +2248,11 @@ ask_curve (int *algo, int both) if ((*algo == PUBKEY_ALGO_ECDSA || *algo == PUBKEY_ALGO_EDDSA) && curves[idx].fix_curve) { + if (subkey_algo && *subkey_algo == PUBKEY_ALGO_ECDSA) + { + *subkey_algo = PUBKEY_ALGO_EDDSA; + result = xstrdup ("Ed25519"); + } *algo = PUBKEY_ALGO_EDDSA; result = xstrdup ("Ed25519"); } @@ -3672,7 +3684,7 @@ generate_keypair (ctrl_t ctrl, int full, const char *fname, || algo == PUBKEY_ALGO_EDDSA || algo == PUBKEY_ALGO_ECDH) { - curve = ask_curve (&algo, both); + curve = ask_curve (&algo, &subkey_algo); r = xmalloc_clear( sizeof *r + 20 ); r->key = pKEYTYPE; sprintf( r->u.value, "%d", algo); @@ -3743,7 +3755,7 @@ generate_keypair (ctrl_t ctrl, int full, const char *fname, || algo == PUBKEY_ALGO_EDDSA || algo == PUBKEY_ALGO_ECDH) { - curve = ask_curve (&algo, 0); + curve = ask_curve (&algo, NULL); nbits = 0; r = xmalloc_clear (sizeof *r + strlen (curve)); r->key = pKEYCURVE; @@ -4292,7 +4304,7 @@ generate_subkeypair (ctrl_t ctrl, kbnode_t keyblock) else if (algo == PUBKEY_ALGO_ECDSA || algo == PUBKEY_ALGO_EDDSA || algo == PUBKEY_ALGO_ECDH) - curve = ask_curve (&algo, 0); + curve = ask_curve (&algo, NULL); else nbits = ask_keysize (algo, 0); diff --git a/g10/keyid.c b/g10/keyid.c index 90d982e..cfdf29d 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -761,12 +761,20 @@ keygrip_from_pk (PKT_public_key *pk, unsigned char *array) case PUBKEY_ALGO_ECDH: { char *curve = openpgp_oid_to_str (pk->pkey[0]); + if (!curve) err = gpg_error_from_syserror (); else { + int with_eddsa_flag = 0; + + if (pk->pubkey_algo == PUBKEY_ALGO_EDDSA + || (pk->pubkey_algo == PUBKEY_ALGO_ECDH + && openpgp_oid_is_curve25519 (pk->pkey[0]))) + with_eddsa_flag = 1; + err = gcry_sexp_build (&s_pkey, NULL, - pk->pubkey_algo == PUBKEY_ALGO_EDDSA ? + with_eddsa_flag ? "(public-key(ecc(curve%s)(flags eddsa)(q%m)))" : "(public-key(ecc(curve%s)(q%m)))", curve, pk->pkey[1]); diff --git a/g10/misc.c b/g10/misc.c index 9134b28..8f2d379 100644 --- a/g10/misc.c +++ b/g10/misc.c @@ -612,11 +612,11 @@ openpgp_pk_algo_usage ( int algo ) use = PUBKEY_USAGE_ENC; break; case PUBKEY_ALGO_DSA: + case PUBKEY_ALGO_ECDSA: use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG | PUBKEY_USAGE_AUTH; break; - case PUBKEY_ALGO_ECDSA: case PUBKEY_ALGO_EDDSA: - use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG | PUBKEY_USAGE_AUTH; + use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH; default: break; } diff --git a/g10/pkglue.c b/g10/pkglue.c index d72275b..7d78322 100644 --- a/g10/pkglue.c +++ b/g10/pkglue.c @@ -228,9 +228,13 @@ pk_encrypt (pubkey_algo_t algo, gcry_mpi_t *resarr, gcry_mpi_t data, rc = gpg_error_from_syserror (); else { + int with_eddsa_flag = openpgp_oid_is_curve25519 (pkey[0]); + /* Now use the ephemeral secret to compute the shared point. */ rc = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecdh(curve%s)(q%m)))", + with_eddsa_flag ? + "(public-key(ecdh(curve%s)(flags eddsa)(q%m)))" + : "(public-key(ecdh(curve%s)(q%m)))", curve, pkey[1]); xfree (curve); /* Put K into a simplified S-expression. */ diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c index cb834af..fd7f812 100644 --- a/g10/pubkey-enc.c +++ b/g10/pubkey-enc.c @@ -250,8 +250,8 @@ get_it (PKT_pubkey_enc *enc, DEK *dek, PKT_public_key *sk, u32 *keyid) if(err) goto leave; - /* Reuse NFRAME, which size is sufficient to include the session key. */ - err = gcry_mpi_print (GCRYMPI_FMT_USG, frame, nframe, &nframe, decoded); + xfree (frame); + err = gcry_mpi_aprint (GCRYMPI_FMT_USG, &frame, &nframe, decoded); mpi_release (decoded); if (err) goto leave; diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index f5911f3..81e1590 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -151,6 +151,7 @@ enum CURVE_NIST_P521, CURVE_SEC_P256K1, CURVE_ED25519, + CURVE_CURVE25519, CURVE_UNKNOWN, }; @@ -242,9 +243,6 @@ struct app_local_s { struct { int curve; } ecc; - struct { - int curve; - } eddsa; }; } keyattr[3]; }; @@ -950,6 +948,11 @@ get_ecc_key_parameters (int curve, int *r_n_bits, const char **r_curve_oid) *r_n_bits = 255; *r_curve_oid = "1.3.6.1.4.1.11591.15.1"; } + else if (curve == CURVE_CURVE25519) + { + *r_n_bits = 255; + *r_curve_oid = "1.3.6.1.4.1.3029.1.5.1"; + } else { *r_n_bits = 0; @@ -981,13 +984,13 @@ send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int number) } else if (app->app_local->keyattr[number].key_type == KEY_TYPE_EDDSA) { - get_ecc_key_parameters (app->app_local->keyattr[number].eddsa.curve, + get_ecc_key_parameters (app->app_local->keyattr[number].ecc.curve, &n_bits, &curve_oid); snprintf (buffer, sizeof buffer, "%d 22 %u %s", number+1, n_bits, curve_oid); } else - snprintf (buffer, sizeof buffer, "0 0 UNKNOWN"); + snprintf (buffer, sizeof buffer, "%d 0 0 UNKNOWN", number+1); send_status_direct (ctrl, keyword, buffer); } @@ -1304,6 +1307,8 @@ get_curve_name (int curve) return "secp256k1"; else if (curve == CURVE_ED25519) return "Ed25519"; + else if (curve == CURVE_CURVE25519) + return "Curve25519"; else return "unknown"; } @@ -1477,6 +1482,8 @@ get_public_key (app_t app, int keyno) } /* Prepend numbers with a 0 if needed. */ if (app->app_local->keyattr[keyno].key_type != KEY_TYPE_EDDSA + && !(app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECC + && app->app_local->keyattr[keyno].ecc.curve == CURVE_CURVE25519) && mlen && (*m & 0x80)) { *mbuf = 0; @@ -1506,72 +1513,36 @@ get_public_key (app_t app, int keyno) { err = gcry_sexp_build (&s_pkey, NULL, "(public-key(rsa(n%b)(e%b)))", (int)mlen, mbuf, (int)elen, ebuf); - if (err) - goto leave; - - len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); - keybuf = xtrymalloc (len); - if (!keybuf) - { - gcry_sexp_release (s_pkey); - err = gpg_error_from_syserror (); - goto leave; - } - gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); - gcry_sexp_release (s_pkey); } - else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECC) + else { + /* ECDSA, ECDH or EdDSA */ const char *curve_name = get_curve_name (app->app_local->keyattr[keyno].ecc.curve); - err = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecc(curve%s)(q%b)))", - curve_name, (int)mlen, mbuf); - if (err) - goto leave; - - len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); - - keybuf = xtrymalloc (len); - if (!keybuf) - { - gcry_sexp_release (s_pkey); - err = gpg_error_from_syserror (); - goto leave; - } - gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); - gcry_sexp_release (s_pkey); + if (app->app_local->keyattr[keyno].ecc.curve == CURVE_ED25519 + || app->app_local->keyattr[keyno].ecc.curve == CURVE_CURVE25519) + err = gcry_sexp_build (&s_pkey, NULL, + "(public-key(ecc(curve%s)(flags eddsa)(q%b)))", + curve_name, (int)mlen, mbuf); + else + err = gcry_sexp_build (&s_pkey, NULL, + "(public-key(ecc(curve%s)(q%b)))", + curve_name, (int)mlen, mbuf); } - else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_EDDSA) - { - const char *curve_name - = get_curve_name (app->app_local->keyattr[keyno].eddsa.curve); - err = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecc(curve%s)(flags eddsa)(q%b)))", - curve_name, (int)mlen, mbuf); - if (err) - goto leave; - - len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); - - keybuf = xtrymalloc (len); - if (!keybuf) - { - gcry_sexp_release (s_pkey); - err = gpg_error_from_syserror (); - goto leave; - } - gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); - gcry_sexp_release (s_pkey); - } - else + if (err) + goto leave; + len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); + keybuf = xtrymalloc (len); + if (!keybuf) { - err = gpg_error (GPG_ERR_NOT_IMPLEMENTED); + gcry_sexp_release (s_pkey); + err = gpg_error_from_syserror (); goto leave; } - + gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); + gcry_sexp_release (s_pkey); app->app_local->pk[keyno].key = (unsigned char*)keybuf; app->app_local->pk[keyno].keylen = len - 1; /* Decrement for trailing '\0' */ @@ -3264,6 +3235,8 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), curve = CURVE_SEC_P256K1; else if (tok && toklen == 7 && !memcmp (tok, "Ed25519", 7)) curve = CURVE_ED25519; + else if (tok && toklen == 10 && !memcmp (tok, "Curve25519", 10)) + curve = CURVE_CURVE25519; else { log_error (_("unsupported curve\n")); @@ -3289,7 +3262,8 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), } if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) goto leave; - if (tok && buf2 && curve != CURVE_ED25519) + if (tok && buf2 + && curve != CURVE_ED25519 && curve != CURVE_CURVE25519) /* It's MPI. Strip off leading zero bytes and save. */ for (;toklen && !*tok; toklen--, tok++) ; @@ -3396,10 +3370,13 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), curve == CURVE_ED25519 ? KEY_TYPE_EDDSA : KEY_TYPE_ECC, curve == CURVE_ED25519 ? "\x09\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" + : curve == CURVE_CURVE25519 ? + "\x0a\x2b\x06\x01\x04\x01\x97\x55\x01\x05\x01" : curve == CURVE_NIST_P256 ? "\x08\x2a\x86\x48\xce\x3d\x03\x01\x07" : "\x05\x2b\x81\x04\x00\x0a", (size_t)(curve == CURVE_ED25519 ? 10 + : curve == CURVE_CURVE25519 ? 11 : curve == CURVE_NIST_P256? 9 : 6), ecc_q, ecc_q_len, "\x03\x01\x08\x07", (size_t)4); if (err) @@ -4396,6 +4373,8 @@ parse_ecc_curve (const unsigned char *buffer, size_t buflen) curve = CURVE_SEC_P256K1; else if (buflen == 9) curve = CURVE_ED25519; + else if (buflen == 10) + curve = CURVE_CURVE25519; else curve = CURVE_UNKNOWN; @@ -4470,12 +4449,12 @@ parse_algorithm_attribute (app_t app, int keyno) else if (*buffer == 22) /* EdDSA */ { app->app_local->keyattr[keyno].key_type = KEY_TYPE_EDDSA; - app->app_local->keyattr[keyno].eddsa.curve + app->app_local->keyattr[keyno].ecc.curve = parse_ecc_curve (buffer + 1, buflen - 1); if (opt.verbose) log_printf ("EdDSA, curve=%s\n", - get_curve_name (app->app_local->keyattr[keyno].eddsa.curve)); + get_curve_name (app->app_local->keyattr[keyno].ecc.curve)); } else if (opt.verbose) log_printhex ("", buffer, buflen); -- From gniibe at fsij.org Wed Jul 8 08:02:54 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 08 Jul 2015 15:02:54 +0900 Subject: Canonical Key Format for ECC? In-Reply-To: <877frkkd7a.fsf@vigenere.g10code.de> References: <556EE9BA.3040209@fsij.org> <877frkkd7a.fsf@vigenere.g10code.de> Message-ID: <559CBD0E.2070107@fsij.org> Hello, Here is the change to use Libgcrypt's curve name than OID string. It includes a bit of clean up for API of openpgp_oid_to_curve. I'm going to commit this. diff --git a/common/openpgp-oid.c b/common/openpgp-oid.c index 7a75801..676079c 100644 --- a/common/openpgp-oid.c +++ b/common/openpgp-oid.c @@ -332,7 +332,7 @@ openpgp_curve_to_oid (const char *name, unsigned int *r_nbits) } -/* Map an OpenPGP OID to the Libgcrypt curve NAME. Returns "?" for +/* Map an OpenPGP OID to the Libgcrypt curve NAME. Returns NULL for unknown curve names. We prefer an alias name here which is more suitable for printing. */ const char * @@ -341,13 +341,13 @@ openpgp_oid_to_curve (const char *oidstr) int i; if (!oidstr) - return ""; + return NULL; for (i=0; oidtable[i].name; i++) if (!strcmp (oidtable[i].oidstr, oidstr)) return oidtable[i].alias? oidtable[i].alias : oidtable[i].name; - return "?"; + return NULL; } diff --git a/g10/import.c b/g10/import.c index de22520..0a2ebcd 100644 --- a/g10/import.c +++ b/g10/import.c @@ -1414,7 +1414,9 @@ transfer_secret_keys (ctrl_t ctrl, struct stats_s *stats, kbnode_t sec_keyblock, err = gpg_error_from_syserror (); else { - err = gcry_sexp_build (&curve, NULL, "(curve %s)", curvestr); + const char *curvename = openpgp_oid_to_curve (curvestr); + err = gcry_sexp_build (&curve, NULL, "(curve %s)", + curvename?curvename:curvestr); xfree (curvestr); if (!err) { diff --git a/g10/keyid.c b/g10/keyid.c index 90d982e..6b6f670 100644 --- a/g10/keyid.c +++ b/g10/keyid.c @@ -121,7 +121,7 @@ pubkey_string (PKT_public_key *pk, char *buffer, size_t bufsize) char *curve = openpgp_oid_to_str (pk->pkey[0]); const char *name = openpgp_oid_to_curve (curve); - if (*name && *name != '?') + if (name) snprintf (buffer, bufsize, "%s", name); else if (curve) snprintf (buffer, bufsize, "E_%s", curve); diff --git a/g10/keylist.c b/g10/keylist.c index d4e572e..d81e7dd 100644 --- a/g10/keylist.c +++ b/g10/keylist.c @@ -1092,7 +1092,7 @@ list_keyblock_print (KBNODE keyblock, int secret, int fpr, { char *curve = openpgp_oid_to_str (pk2->pkey[0]); const char *name = openpgp_oid_to_curve (curve); - if (!*name || *name == '?') + if (!name) name = curve; es_fprintf (es_stdout, " %s", name); xfree (curve); @@ -1359,7 +1359,7 @@ list_keyblock_colon (KBNODE keyblock, int secret, int has_secret, int fpr) { char *curve = openpgp_oid_to_str (pk->pkey[0]); const char *name = openpgp_oid_to_curve (curve); - if (!*name || *name == '?') + if (!name) name = curve; es_fputs (name, es_stdout); xfree (curve); @@ -1488,7 +1488,7 @@ list_keyblock_colon (KBNODE keyblock, int secret, int has_secret, int fpr) { char *curve = openpgp_oid_to_str (pk->pkey[0]); const char *name = openpgp_oid_to_curve (curve); - if (!*name || *name == '?') + if (!name) name = curve; es_fputs (name, es_stdout); xfree (curve); diff --git a/g10/parse-packet.c b/g10/parse-packet.c index 5116404..6131d32 100644 --- a/g10/parse-packet.c +++ b/g10/parse-packet.c @@ -2086,8 +2086,8 @@ parse_key (IOBUF inp, int pkttype, unsigned long pktlen, || algorithm == PUBKEY_ALGO_ECDH) && i==0) { char *curve = openpgp_oid_to_str (pk->pkey[0]); - es_fprintf (listfp, " %s (%s)", - openpgp_oid_to_curve (curve), curve); + const char *name = openpgp_oid_to_curve (curve); + es_fprintf (listfp, " %s (%s)", name?name:"", curve); xfree (curve); } es_putc ('\n', listfp); -- From dkg at fifthhorseman.net Wed Jul 8 19:17:30 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 8 Jul 2015 13:17:30 -0400 Subject: [PATCH] GPGME: remove BUILD_TIMESTAMP Message-ID: <1436375850-26861-1-git-send-email-dkg@fifthhorseman.net> embedding the timestamp of the configuration into the build makes the binary output unreproducible, which makes it more difficult to verify that any particular set of binaries is build from the expected source code. This changeset removes all attempts at embedding the build timestamp in GPGME. We already have PACKAGE_VERSION (and BUILD_REVISION when building from git) as identifiers of what was built, so we should be able to let go of this source of variation in the build without much of a drawback. If removal of BUILD_TIMESTAMP isn't acceptable for gpgme, we should allow it to be externally set for people who are trying to rebuild the package reproducibly. See also: https://wiki.debian.org/ReproducibleBuilds/Howto#Files_in_data.tar_contain_timestamps Signed-off-by: Daniel Kahn Gillmor --- configure.ac | 5 ----- src/version.c | 2 +- src/versioninfo.rc.in | 1 - 3 files changed, 1 insertion(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index be36a42..66feec8 100644 --- a/configure.ac +++ b/configure.ac @@ -260,11 +260,6 @@ changequote([,])dnl BUILD_FILEVERSION="${BUILD_FILEVERSION}mym4_revision_dec" AC_SUBST(BUILD_FILEVERSION) -BUILD_TIMESTAMP=`date -u +%Y-%m-%dT%H:%M+0000 2>/dev/null || date` -AC_SUBST(BUILD_TIMESTAMP) -AC_DEFINE_UNQUOTED(BUILD_TIMESTAMP, "$BUILD_TIMESTAMP", - [The time this package was configured for a build]) - # # Options to disable some regression tests # diff --git a/src/version.c b/src/version.c index 15e5aee..09602b0 100644 --- a/src/version.c +++ b/src/version.c @@ -92,7 +92,7 @@ cright_blurb (void) "This is GPGME " PACKAGE_VERSION " - The GnuPG Made Easy library\n" CRIGHTBLURB "\n" - "(" BUILD_REVISION " " BUILD_TIMESTAMP ")\n" + "(" BUILD_REVISION ")\n" "\n\n"; return blurb; } diff --git a/src/versioninfo.rc.in b/src/versioninfo.rc.in index a4ab0af..50df4fd 100644 --- a/src/versioninfo.rc.in +++ b/src/versioninfo.rc.in @@ -45,7 +45,6 @@ BEGIN VALUE "PrivateBuild", "\0" VALUE "ProductName", "GPGME\0" VALUE "ProductVersion", "@VERSION@\0" - VALUE "SpecialBuild", "@BUILD_TIMESTAMP@\0" END END END -- 2.1.4 From gniibe at fsij.org Thu Jul 9 05:51:30 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 09 Jul 2015 12:51:30 +0900 Subject: scd: Remove unused files. Message-ID: <559DEFC2.6020603@fsij.org> Hello, I'm going to remove old historical unused files under SCD. * scd/Makefile.am (sc_copykeys_*): Remove. * scd/sc-copykeys.c: Remove. * scd/pcsc-wrapper.c: Remove. * scd/{card-common.h,card-dinsig.c,card-p15.c,card.c}: Remove. -- sc-copykeys doesn't work any more because it's based on old API. pcsc-wrapper has gone because of nPth which is compatible to pthreads. The card* files are old files, now we have app*. -- From gniibe at fsij.org Thu Jul 9 07:50:16 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 09 Jul 2015 14:50:16 +0900 Subject: Revised patch to support the SmartCard-HSM in scdaemon In-Reply-To: <53CED1D8.1010306@cardcontact.de> References: <53CED1D8.1010306@cardcontact.de> Message-ID: <559E0B98.4050902@fsij.org> Hello, This is a reply to your message sent last year. On 07/23/2014 06:04 AM, Andreas Schwier wrote: > please find attached [1] the revised patch to GnuPG master, adding > support for the SmartCard-HSM to scdaemon. Recently, we received a post to gnupg-users about using the SmartCard-HSM for OpenPGP. http://lists.gnupg.org/pipermail/gnupg-users/2015-July/053870.html IIUC, the driver you submitted is intended to be used with gpgsm, perhaps. Please correct me if I'm wrong. Do you have a plan to add the READKEY method so that it can work for OpenPGP? In gnupg/scd/app-openpgp.c, we have: ======================== /* Handle the READKEY command for OpenPGP. On success a canonical encoded S-expression with the public key will get stored at PK and its length (for assertions) at PKLEN; the caller must release that buffer. On error PK and PKLEN are not changed and an error code is returned. */ static gpg_error_t do_readkey (app_t app, const char *keyid, unsigned char **pk, size_t *pklen) ======================== When it's available, gpg frontend can ask card for signing/decipher for OpenPGP. Creating OpenPGP from the public key in the card, we will need some tool, though. -- From andreas.schwier.ml at cardcontact.de Thu Jul 9 09:32:28 2015 From: andreas.schwier.ml at cardcontact.de (Andreas Schwier) Date: Thu, 09 Jul 2015 09:32:28 +0200 Subject: Revised patch to support the SmartCard-HSM in scdaemon In-Reply-To: <559E0B98.4050902@fsij.org> References: <53CED1D8.1010306@cardcontact.de> <559E0B98.4050902@fsij.org> Message-ID: <559E238C.6040202@cardcontact.de> Hello, the SmartCard-HSM driver only works with gpgsm. When we wrote the driver, there was a limitation in gpg that prevented the use of anything else than a card compliant with the OpenPGP Card specification [1]. If that situation has been resolved, then I'm more than happy to make the SmartCard-HSM available as key store for GnuPG keys. Andreas [1] http://lists.gnupg.org/pipermail/gnupg-devel/2013-November/028034.html On 07/09/2015 07:50 AM, NIIBE Yutaka wrote: > Hello, > > This is a reply to your message sent last year. > > On 07/23/2014 06:04 AM, Andreas Schwier wrote: >> please find attached [1] the revised patch to GnuPG master, adding >> support for the SmartCard-HSM to scdaemon. > > Recently, we received a post to gnupg-users about using the > SmartCard-HSM for OpenPGP. > > http://lists.gnupg.org/pipermail/gnupg-users/2015-July/053870.html > > IIUC, the driver you submitted is intended to be used with gpgsm, > perhaps. Please correct me if I'm wrong. > > Do you have a plan to add the READKEY method so that it can work > for OpenPGP? > > In gnupg/scd/app-openpgp.c, we have: > ======================== > /* Handle the READKEY command for OpenPGP. On success a canonical > encoded S-expression with the public key will get stored at PK and > its length (for assertions) at PKLEN; the caller must release that > buffer. On error PK and PKLEN are not changed and an error code is > returned. */ > static gpg_error_t > do_readkey (app_t app, const char *keyid, unsigned char **pk, size_t *pklen) > ======================== > > When it's available, gpg frontend can ask card for signing/decipher > for OpenPGP. > > Creating OpenPGP from the public key in the card, we will need some > tool, though. > -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Sch?lerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 571 56149 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org http://www.smartcard-hsm.com From gniibe at fsij.org Thu Jul 9 10:52:39 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 09 Jul 2015 17:52:39 +0900 Subject: Revised patch to support the SmartCard-HSM in scdaemon In-Reply-To: <559E238C.6040202@cardcontact.de> References: <53CED1D8.1010306@cardcontact.de> <559E0B98.4050902@fsij.org> <559E238C.6040202@cardcontact.de> Message-ID: <559E3657.7000608@fsij.org> Thank you for your prompt reply. I am talking about GnuPG 2.1. I think that, even now, it is possible to use gpg-connect-agent command to sign/deciper using SmartCard-HSM. On 07/09/2015 04:32 PM, Andreas Schwier wrote: > the SmartCard-HSM driver only works with gpgsm. When we wrote the > driver, there was a limitation in gpg that prevented the use of anything > else than a card compliant with the OpenPGP Card specification [1]. > > If that situation has been resolved, then I'm more than happy to make > the SmartCard-HSM available as key store for GnuPG keys. It is not fully resolved yet (it's on going). As I addressed in the previous mail, some external tool would be required to create OpenPGP key which is associated to a private key in SmartCard-HSM. If SmartCard-HSM has capability to show its public key to its users, please implement READKEY method in app-sc-hsm.c. Then, it will be possible to write such an external tool. Combined together, I believe that gpg frontend will be able to use SmartCard-HSM as a backend of private key operation for OpenPGP (possibly, a small change would be required, but not that difficult). Given the situation GnuPG 2.1 supports ECC, it would be interesting if a user can use SmartCard-HSM as a key store of ECC. :-) -- From gniibe at fsij.org Fri Jul 10 02:30:00 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 10 Jul 2015 09:30:00 +0900 Subject: agent: Support non-NLS build. Message-ID: <559F1208.6010404@fsij.org> Hello, This is a fix for an issue: https://bugs.gnupg.org/gnupg/issue2032 I'm going to push this as it's obvious. * agent/agent.h: Use ENABLE_NLS and define L_() macro. diff --git a/agent/agent.h b/agent/agent.h index 2948bff..5a09254 100644 --- a/agent/agent.h +++ b/agent/agent.h @@ -300,6 +300,7 @@ typedef int (*lookup_ttl_t)(const char *hexgrip); and uses that to translate a string according to the locale set for the connection. The macro LunderscoreIMPL is used by i18n to actually define the inline function when needed. */ +#ifdef ENABLE_NLS #define L_(a) agent_Lunderscore (ctrl, (a)) #define LunderscorePROTO \ static inline const char *agent_Lunderscore (ctrl_t ctrl, \ @@ -312,6 +313,9 @@ typedef int (*lookup_ttl_t)(const char *hexgrip); return ctrl? i18n_localegettext (ctrl->lc_messages, string) \ /* */: gettext (string); \ } +#else +#define L_(a) (a) +#endif /*-- gpg-agent.c --*/ -- From andrew.p.clausen at gmail.com Sun Jul 12 17:47:28 2015 From: andrew.p.clausen at gmail.com (Andrew Clausen) Date: Sun, 12 Jul 2015 16:47:28 +0100 Subject: please change the default hashing algorithm Message-ID: <1436715919-sup-3054@laptop> Hi GPG developers, By default, GPG uses the SHA1 hashing algorithm, which has been believed to be weak for over 10 years.[1] Is it possible to change the default over to SHA256? I understand that there are several different uses for hashing algorithms, governed by the personal-digest-preferences and cert-digest-algo options. I would think it makes sense to switch both of these over to SHA256, but it's much more important to switch over personal-digest-preferences. Previous email discussions on this list have mentioned some kind of compatibility concerns. If we can't switch both over immediately, are there any compatibility concerns with just switching personal-digest-preferences over? Cheers, Andrew [1] https://www.schneier.com/blog/archives/2005/02/sha1_broken.html From dkg at fifthhorseman.net Mon Jul 13 01:12:09 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 12 Jul 2015 19:12:09 -0400 Subject: please change the default hashing algorithm In-Reply-To: <1436715919-sup-3054@laptop> References: <1436715919-sup-3054@laptop> Message-ID: <87lhel7yye.fsf@alice.fifthhorseman.net> On Sun 2015-07-12 11:47:28 -0400, Andrew Clausen wrote: > By default, GPG uses the SHA1 hashing algorithm, which has been > believed to be weak for over 10 years.[1] Is it possible to change the > default over to SHA256? I agree with you that SHA1 should not be the default in 2015 for any situation where collision resistance is necessary. What version of gpg are you testing? in the modern branch (testing version 2.1.6 here) the default is indeed SHA256 for certificate generation. Also, there are many places where digest algorithms are used; maybe you're looking at a different place than i'm looking at? If you can show the specific workflow you're using that defaults to SHA1, that would make it easier for other people to confirm the problem. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From flapflap at riseup.net Mon Jul 13 00:53:05 2015 From: flapflap at riseup.net (flapflap) Date: Sun, 12 Jul 2015 22:53:05 +0000 Subject: please change the default hashing algorithm In-Reply-To: <1436715919-sup-3054@laptop> References: <1436715919-sup-3054@laptop> Message-ID: <55A2EFD1.2020604@riseup.net> Andrew Clausen: > Hi GPG developers, > > By default, GPG uses the SHA1 hashing algorithm, which has been believed to be > weak for over 10 years.[1] Is it possible to change the default over to > SHA256? > > I understand that there are several different uses for hashing algorithms, > governed by the personal-digest-preferences and cert-digest-algo options. > I would think it makes sense to switch both of these over to SHA256, but > it's much more important to switch over personal-digest-preferences. > > Previous email discussions on this list have mentioned some kind of > compatibility concerns. If we can't switch both over immediately, are there > any compatibility concerns with just switching personal-digest-preferences > over? > > Cheers, > Andrew > > [1] https://www.schneier.com/blog/archives/2005/02/sha1_broken.html some additional opinions for the discussion: The "OpenPGP Best Practices" of Riseup also recommend against choosing SHA1 in some cases: https://help.riseup.net/en/security/message-security/openpgp/best-practices#self-signatures-should-not-use-sha1 and also SHA1 is highlighted in red when querying the key status with hopenpgp-tools: $ hkt export-pubkeys | hokey lint Cheers, flapflap -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From andrew.p.clausen at gmail.com Mon Jul 13 11:41:11 2015 From: andrew.p.clausen at gmail.com (Andrew Clausen) Date: Mon, 13 Jul 2015 10:41:11 +0100 Subject: please change the default hashing algorithm In-Reply-To: <87lhel7yye.fsf@alice.fifthhorseman.net> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> Message-ID: Hi Dan, On 13 July 2015 at 00:12, Daniel Kahn Gillmor wrote: > I agree with you that SHA1 should not be the default in 2015 for any > situation where collision resistance is necessary. > > What version of gpg are you testing? I initially tried the 1.4.16 and 2.0.22 packages in the latest Ubuntu long-term supported distribution. > If you can show the specific workflow you're using that defaults to SHA1, > that would make it easier for other people to confirm the problem. I couldn't build the latest versions (Ubuntu's gettext is too old), but I could build 1.4.18 with: git clone git://git.gnupg.org/gnupg.git cd gnupg git checkout gnupg-1.4.18 ./autogen.sh CFLAGS=-g ./configure --without-ldap --without-libcurl --without-libusb --without-mailprog make I tested it by making a test user account, and gpg --gen-key echo test > test.txt gpg --sign test.txt gpg -v < test.txt which gives: gpg: original file name='test.txt' test gpg: Signature made Mon 13 Jul 2015 10:16:53 BST using DSA key ID 73207F13 gpg: using PGP trust model gpg: Good signature from "test test (test) " gpg: binary signature, digest algorithm SHA1 I had trouble building gpg-2.0.28 (gettext too old) and gpg-2.0.26 (make didn't know how to build audit-event.h). I can dig deeper if that helps, but my guess is that this is clear enough... Cheers, Andrew From ben at adversary.org Tue Jul 14 19:47:45 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Jul 2015 03:47:45 +1000 Subject: please change the default hashing algorithm In-Reply-To: References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> Message-ID: <55A54B41.3090603@adversary.org> On 13/07/2015 7:41 pm, Andrew Clausen wrote: > > I tested it by making a test user account, and > gpg --gen-key > echo test > test.txt > gpg --sign test.txt > gpg -v < test.txt > > which gives: > > gpg: original file name='test.txt' > test > gpg: Signature made Mon 13 Jul 2015 10:16:53 BST using DSA key ID 73207F13 > gpg: using PGP trust model > gpg: Good signature from "test test (test) " > gpg: binary signature, digest algorithm SHA1 > > I had trouble building gpg-2.0.28 (gettext too old) and gpg-2.0.26 > (make didn't know how to build audit-event.h). I can dig deeper if > that helps, but my guess is that this is clear enough... That can be fixed with the digest preferences. If a key was generated before the gpg.conf file was set with stronger digest preferences first it will inherit the original settings with SHA1 as the preferred digest. Overriding that in gpg.conf before generating the key results in new keys using the preference order specified in gpg.conf. To change an existing key you need to edit that key and then use the setpref command to reorder those preferences. Don't forget to save instead of just quitting when done. The setpref command takes the same input as the default-preference-list in gpg.conf. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From andrew.p.clausen at gmail.com Tue Jul 14 20:23:46 2015 From: andrew.p.clausen at gmail.com (Andrew Clausen) Date: Tue, 14 Jul 2015 19:23:46 +0100 Subject: please change the default hashing algorithm In-Reply-To: <55A54B41.3090603@adversary.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> Message-ID: <1436897825-sup-9454@laptop> Excerpts from Ben McGinnes's message of 2015-07-14 18:47:45 +0100: > > gpg: original file name='test.txt' > > test > > gpg: Signature made Mon 13 Jul 2015 10:16:53 BST using DSA key ID 73207F13 > > gpg: using PGP trust model > > gpg: Good signature from "test test (test) " > > gpg: binary signature, digest algorithm SHA1 > > > > I had trouble building gpg-2.0.28 (gettext too old) and gpg-2.0.26 > > (make didn't know how to build audit-event.h). I can dig deeper if > > that helps, but my guess is that this is clear enough... > > That can be fixed with the digest preferences. It's kind of you to offer your help, but my email wasn't a request for support. I was requesting that GPG be modified so that it doesn't use insecure hashing algorithms by default. It seems that "modern" GPG does this, but not "classic" GPG, which I believe is more popular. Kind regards, Andrew From ben at adversary.org Tue Jul 14 20:47:07 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Jul 2015 04:47:07 +1000 Subject: please change the default hashing algorithm In-Reply-To: <1436897825-sup-9454@laptop> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <1436897825-sup-9454@laptop> Message-ID: <55A5592B.7010701@adversary.org> On 15/07/2015 4:23 am, Andrew Clausen wrote: > Excerpts from Ben McGinnes's message of 2015-07-14 18:47:45 +0100: >>> gpg: original file name='test.txt' >>> test >>> gpg: Signature made Mon 13 Jul 2015 10:16:53 BST using DSA key ID 73207F13 >>> gpg: using PGP trust model >>> gpg: Good signature from "test test (test) " >>> gpg: binary signature, digest algorithm SHA1 >>> >>> I had trouble building gpg-2.0.28 (gettext too old) and gpg-2.0.26 >>> (make didn't know how to build audit-event.h). I can dig deeper if >>> that helps, but my guess is that this is clear enough... >> >> That can be fixed with the digest preferences. > > It's kind of you to offer your help, but my email wasn't a request for support. > I was requesting that GPG be modified so that it doesn't use insecure hashing > algorithms by default. It seems that "modern" GPG does this, but not "classic" > GPG, which I believe is more popular. Ah, classic, if the concern pertains to the majority of end users that will be effectively neutralised when the switch to ECC forces them off classic and onto modern. If the concern is the remaining systems which continue to use classic due to ease of automation or integration with other APIs or systems (e.g. package managers), then leveraging modern via GPGME is probably the best way to go. Changing the default preferences can probably be done, but I'll wait for Werner to return from his holiday and comment on that. Also, there may be an additional complication with regards to the digest used with the self-signature packet during key creation. I just double-checked another key I made earlier this year which definitely had SHA512 as the preferred first choice hash in gpg.conf during key creation and it still has SHA1 in the self signatures. It was also generated with classic due to the key size (I was doing silly things to prove a point elsewhere). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jul 14 20:09:37 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Jul 2015 14:09:37 -0400 Subject: please change the default hashing algorithm In-Reply-To: <55A54B41.3090603@adversary.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> Message-ID: <55A55061.7040905@sixdemonbag.org> > That can be fixed with the digest preferences. Speaking of, what *are* the current default preference lists, as of GnuPG 2.1.6? It's been quite some time since I've looked at them, and I suspect they may have changed. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Tue Jul 14 21:37:41 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Jul 2015 05:37:41 +1000 Subject: please change the default hashing algorithm In-Reply-To: <1436900362-sup-6603@laptop> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <1436897825-sup-9454@laptop> <55A5592B.7010701@adversary.org> <1436900362-sup-6603@laptop> Message-ID: <55A56505.3000504@adversary.org> On 15/07/2015 5:13 am, Andrew Clausen wrote: > Excerpts from Ben McGinnes's message of 2015-07-14 19:47:07 +0100: >> >> Ah, classic, if the concern pertains to the majority of end users that >> will be effectively neutralised when the switch to ECC forces them off >> classic and onto modern. > > I worry that this might still be some time away. My main concern is > with signing messages and files, not signing keys. For example, > Ubuntu 14.04 LTS packages are signed with SHA-1 hashes. (Their newer > more experimental releases are using SHA-256, IIRC.) While they probably should switch entirely to 256 (or higher), they're unlikely to be in any danger during the period in which those packages are current (even with long-term support distributions). > Aside: many people are rightly nervous about switching to elliptic > curves. The maths is harder to understand, the most popular curves > have vulnerabilities (possibly by design!), and safe curves were only > developed quite recently. (See http://safecurves.cr.yp.to/) Yeah, I've read it. Though popular depends on who you speak to, it's probably better tosay the current NIST recommendations are vulnerable, whereas the most popular curve is not (and its popularity stems from the reaction to NIST and the undermining of NIST by NSA). > Of course, the switch will happen, but it might be slow. Perhaps > GPG could give users better guidance that they ought to be using > Curve 25519 rather than the vulnerable NIST or brainpool curves. > (I'm looking at https://www.gnupg.org/faq/whats-new-in-2.1.html#ecc, > which might be ought of date.) Work is currently being done to add 25519 for encryption to modern, in addition to its existing implementation for signing. With regards to recommendations, that's also being hashed out (if you'll pardon the pun) with the revision of RFC 4880. >> Changing the default preferences can probably be done, but I'll wait >> for Werner to return from his holiday and comment on that. Also, >> there may be an additional complication with regards to the digest >> used with the self-signature packet during key creation. I just >> double-checked another key I made earlier this year which definitely >> had SHA512 as the preferred first choice hash in gpg.conf during key >> creation and it still has SHA1 in the self signatures. It was also >> generated with classic due to the key size (I was doing silly things >> to prove a point elsewhere). > > This would be great, thanks! Like I said, it's Werner's call. He might just do it or he might wait until the IETF work is comlete and then bring all three branches into line with that. IIRC the current position is to move to SHA-512 or to SHA-3 once a decision has been made on that. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Tue Jul 14 21:51:03 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Jul 2015 05:51:03 +1000 Subject: please change the default hashing algorithm In-Reply-To: <55A55061.7040905@sixdemonbag.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <55A55061.7040905@sixdemonbag.org> Message-ID: <55A56827.2000504@adversary.org> On 15/07/2015 4:09 am, Robert J. Hansen wrote: >> That can be fixed with the digest preferences. > > Speaking of, what *are* the current default preference lists, as of > GnuPG 2.1.6? It's been quite some time since I've looked at them, and I > suspect they may have changed. Good question ... I checked, they're still pretty lame with the default RSA key type: Cipher: AES256, AES192, AES, 3DES Digest: SHA256, SHA384, SHA512, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify And the same is true of ECC: pub brainpoolP512r1/A675A51E created: 2015-07-14 expires: never usage: SC trust: ultimate validity: ultimate sub brainpoolP512r1/4CB4C289 created: 2015-07-14 expires: never usage: E [ultimate] (1). Benny (have you seen my jets?) gpg> showpref [ultimate] (1). Benny (have you seen my jets?) Cipher: AES256, AES192, AES, 3DES Digest: SHA256, SHA384, SHA512, SHA224, SHA1 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From andrew.p.clausen at gmail.com Tue Jul 14 21:13:20 2015 From: andrew.p.clausen at gmail.com (Andrew Clausen) Date: Tue, 14 Jul 2015 20:13:20 +0100 Subject: please change the default hashing algorithm In-Reply-To: <55A5592B.7010701@adversary.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <1436897825-sup-9454@laptop> <55A5592B.7010701@adversary.org> Message-ID: <1436900362-sup-6603@laptop> Excerpts from Ben McGinnes's message of 2015-07-14 19:47:07 +0100: > > It's kind of you to offer your help, but my email wasn't a request for support. > > I was requesting that GPG be modified so that it doesn't use insecure hashing > > algorithms by default. It seems that "modern" GPG does this, but not "classic" > > GPG, which I believe is more popular. > > Ah, classic, if the concern pertains to the majority of end users that > will be effectively neutralised when the switch to ECC forces them off > classic and onto modern. I worry that this might still be some time away. My main concern is with signing messages and files, not signing keys. For example, Ubuntu 14.04 LTS packages are signed with SHA-1 hashes. (Their newer more experimental releases are using SHA-256, IIRC.) Aside: many people are rightly nervous about switching to elliptic curves. The maths is harder to understand, the most popular curves have vulnerabilities (possibly by design!), and safe curves were only developed quite recently. (See http://safecurves.cr.yp.to/) Of course, the switch will happen, but it might be slow. Perhaps GPG could give users better guidance that they ought to be using Curve 25519 rather than the vulnerable NIST or brainpool curves. (I'm looking at https://www.gnupg.org/faq/whats-new-in-2.1.html#ecc, which might be ought of date.) > Changing the default preferences can probably be done, but I'll wait > for Werner to return from his holiday and comment on that. Also, > there may be an additional complication with regards to the digest > used with the self-signature packet during key creation. I just > double-checked another key I made earlier this year which definitely > had SHA512 as the preferred first choice hash in gpg.conf during key > creation and it still has SHA1 in the self signatures. It was also > generated with classic due to the key size (I was doing silly things > to prove a point elsewhere). This would be great, thanks! Kind regards, Andrew From rjh at sixdemonbag.org Tue Jul 14 22:20:38 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Jul 2015 16:20:38 -0400 Subject: please change the default hashing algorithm In-Reply-To: <55A56827.2000504@adversary.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <55A55061.7040905@sixdemonbag.org> <55A56827.2000504@adversary.org> Message-ID: <55A56F16.5000605@sixdemonbag.org> >> Speaking of, what *are* the current default preference lists, as >> of GnuPG 2.1.6? It's been quite some time since I've looked at >> them, and I suspect they may have changed. > > Good question ... > > I checked, they're still pretty lame with the default RSA key type: No, I meant the personal-digest-preferences, personal-cipher-preferences, etc. With respect to the key preference defaults, I don't know about you but it looks pretty solid to me. AES is still the best thing going, and 256-bit hash algorithms are recommended for use with 3072-bit keys. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Tue Jul 14 22:25:19 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Jul 2015 16:25:19 -0400 Subject: please change the default hashing algorithm In-Reply-To: <1436900362-sup-6603@laptop> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <1436897825-sup-9454@laptop> <55A5592B.7010701@adversary.org> <1436900362-sup-6603@laptop> Message-ID: <55A5702F.20406@sixdemonbag.org> > course, the switch will happen, but it might be slow. Perhaps GPG > could give users better guidance that they ought to be using Curve > 25519 rather than the vulnerable NIST or brainpool curves. (I'm "Vulnerable" NIST or Brainpool curves? I'm unaware of any attack against either NIST or Brainpool curves. If I missed something, I'd love to know about it. If this is about hypothetical or conjectured risks, then you should say that instead. "Vulnerable" is the sort of language we use to describe SHA-1 -- the risk is real, we're seeing attacks getting better over time, and so on. To my knowledge, that isn't the case for NIST or Brainpool. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Tue Jul 14 23:49:25 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Jul 2015 07:49:25 +1000 Subject: please change the default hashing algorithm In-Reply-To: <55A56F16.5000605@sixdemonbag.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <55A55061.7040905@sixdemonbag.org> <55A56827.2000504@adversary.org> <55A56F16.5000605@sixdemonbag.org> Message-ID: <55A583E5.3080505@adversary.org> On 15/07/2015 6:20 am, Robert J. Hansen wrote: >>> Speaking of, what *are* the current default preference lists, as >>> of GnuPG 2.1.6? It's been quite some time since I've looked at >>> them, and I suspect they may have changed. >> >> Good question ... >> >> I checked, they're still pretty lame with the default RSA key type: > > No, I meant the personal-digest-preferences, > personal-cipher-preferences, etc. Yeah, but that's what gets generated when you override the homedir to an empty directory that doesn't have a gpg.conf file at all. Hence that is the default. My regular gpg.conf file has this: default-preference-list TWOFISH CAMELLIA256 AES256 CAMELLIA192 AES192 CAMELLIA128 AES BLOWFISH IDEA 3DES CAST5 SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1 ZLIB BZIP2 ZIP Uncompressed personal-cipher-preferences TWOFISH CAMELLIA256 AES256 CAMELLIA192 AES192 CAMELLIA128 AES BLOWFISH IDEA 3DES CAST5 personal-digest-preferences SHA512 SHA384 SHA256 SHA224 RIPEMD160 SHA1 personal-compress-preferences ZLIB BZIP2 ZIP Uncompressed > With respect to the key preference defaults, I don't know about you > but it looks pretty solid to me. AES is still the best thing going, > and 256-bit hash algorithms are recommended for use with 3072-bit > keys. Really? I distinctly recall you recommending TWOFISH to me on gnupg-users some time ago (following which I did a good deal of reading on the AES selection process before moving TWOFISH ahead of Rijndael. Though after reading all that I'd've probably used Serpent if it had been included with GPG, but it isn't and we don't need to go through that debate again. Although it is included with gpgsm, but anyway. What else? Oh yeah, ignore the Camellia bits (as most of you do anyway), that's more because over here in the antipodes and APAC, there's a greater likelihood of running across correspondents who do use it and putting it ahead of AES makes it easier to get that selection through. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Wed Jul 15 00:14:35 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Jul 2015 08:14:35 +1000 Subject: please change the default hashing algorithm In-Reply-To: <55A5702F.20406@sixdemonbag.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <1436897825-sup-9454@laptop> <55A5592B.7010701@adversary.org> <1436900362-sup-6603@laptop> <55A5702F.20406@sixdemonbag.org> Message-ID: <55A589CB.6060108@adversary.org> On 15/07/2015 6:25 am, Robert J. Hansen wrote: >> course, the switch will happen, but it might be slow. Perhaps GPG >> could give users better guidance that they ought to be using Curve >> 25519 rather than the vulnerable NIST or brainpool curves. (I'm > > "Vulnerable" NIST or Brainpool curves? > > I'm unaware of any attack against either NIST or Brainpool curves. If I > missed something, I'd love to know about it. > > If this is about hypothetical or conjectured risks, then you should say > that instead. "Vulnerable" is the sort of language we use to describe > SHA-1 -- the risk is real, we're seeing attacks getting better over > time, and so on. To my knowledge, that isn't the case for NIST or > Brainpool. Yes, you're quite right, we should just say that they're suspect as a result of interference with NIST by NSA. Still, that is a pretty compelling argument, especially for those of us outside of the USA. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Wed Jul 15 00:23:41 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 14 Jul 2015 18:23:41 -0400 Subject: please change the default hashing algorithm In-Reply-To: <55A583E5.3080505@adversary.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <55A55061.7040905@sixdemonbag.org> <55A56827.2000504@adversary.org> <55A56F16.5000605@sixdemonbag.org> <55A583E5.3080505@adversary.org> Message-ID: <55A58BED.7040506@sixdemonbag.org> > Yeah, but that's what gets generated when you override the homedir > to an empty directory that doesn't have a gpg.conf file at all. > Hence that is the default. That's the default for certificate preferences (the preferences that get placed on a newly-generated certificate). That's not the same thing as the default personal-*-preferences. They may be the same, they may be different -- but internally to GnuPG, they are two different sets of preferences, so you can't point to certificate preferences and say "this is what's used as default personal-*-preferences". > Really? I distinctly recall you recommending TWOFISH to me on > gnupg-users some time ago If I did, I was absolutely in error to do so, and you should've known better than to believe me! I like TWOFISH for reasons that are pretty much irrelevant here. It's enough to say that I think TWOFISH is a better choice for me. Those last two words are important. My reasons probably don't apply to you. After all -- you're not me. Further, I'm not a cryppie. I don't know where people get the idea that I am one. A decade ago in graduate school I did some graduate-level work with cryptologic research, but I haven't kept current since then. Nobody should trust the judgment of an ex-cryppie who hasn't kept current over the judgment of the professional cryptologic community. *Nobody*. If you think my commentary on cryptology is interesting, I'm happy. If you think it's definitive, you're wrong. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From ben at adversary.org Wed Jul 15 01:29:19 2015 From: ben at adversary.org (Ben McGinnes) Date: Wed, 15 Jul 2015 09:29:19 +1000 Subject: please change the default hashing algorithm In-Reply-To: <55A58BED.7040506@sixdemonbag.org> References: <1436715919-sup-3054@laptop> <87lhel7yye.fsf@alice.fifthhorseman.net> <55A54B41.3090603@adversary.org> <55A55061.7040905@sixdemonbag.org> <55A56827.2000504@adversary.org> <55A56F16.5000605@sixdemonbag.org> <55A583E5.3080505@adversary.org> <55A58BED.7040506@sixdemonbag.org> Message-ID: <55A59B4F.4020200@adversary.org> On 15/07/2015 8:23 am, Robert J. Hansen wrote: >> Yeah, but that's what gets generated when you override the homedir >> to an empty directory that doesn't have a gpg.conf file at all. >> Hence that is the default. > > That's the default for certificate preferences (the preferences that get > placed on a newly-generated certificate). That's not the same thing as > the default personal-*-preferences. > > They may be the same, they may be different -- but internally to GnuPG, > they are two different sets of preferences, so you can't point to > certificate preferences and say "this is what's used as default > personal-*-preferences". I'd be surprised if they weren't the same, but on the other hand it's been so long since I've seen a default gpg.conf file that I really can't be sure. Still, a quick skim through gpg.c indicates that the default config settings are generated by gpg if there isn't a gpg.conf file when it is first invoked. So if cipher preferences are not set on the command line then that first key will end up with the default settings either way. Obviously I was far too lazy to try passing cipher preferences on the command line. ;) >> Really? I distinctly recall you recommending TWOFISH to me on >> gnupg-users some time ago > > If I did, I was absolutely in error to do so, and you should've known > better than to believe me! > > I like TWOFISH for reasons that are pretty much irrelevant here. It's > enough to say that I think TWOFISH is a better choice for me. Those > last two words are important. My reasons probably don't apply to you. > After all -- you're not me. Good thing I based my decision on other things then. Fear not, your suggestion only got me started in looking into why the defaults were the defaults and whether or not they were best for me. > Further, I'm not a cryppie. I don't know where people get the idea > that I am one. A decade ago in graduate school I did some > graduate-level work with cryptologic research, but I haven't kept > current since then. I'm not sure where that theory comes from either. I just tend to do what I always do when it comes to the more arcane aspects of any tech; research the positions of whoever the top people are in that field, and find use cases that are close(-ish) to my needs, then make a best guess. It usually works out, even with the voodoo of cryptography. > Nobody should trust the judgment of an ex-cryppie who hasn't kept > current over the judgment of the professional cryptologic community. > *Nobody*. If you think my commentary on cryptology is interesting, > I'm happy. If you think it's definitive, you're wrong. :) I don't even think Bruce Schneier's commentary is definitive, but I do pay attention to what he says. ;) I also pay attention to a more local friend and former colleague who, in his misspent youth, may have worked for a certain directorate around these parts and has been known, over a glass of single malt, to mention his own preferences in some of these things. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 630 bytes Desc: OpenPGP digital signature URL: From jeroen.ooms at stat.ucla.edu Wed Jul 15 10:42:14 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Wed, 15 Jul 2015 10:42:14 +0200 Subject: gpgme does not find engine on windows Message-ID: I wrote some gpgme bindings for the R programming language, and they work great on OSX and Linux, but I am having difficulty getting it to work on Windows. The gpgme library has been compiled with mingw-w64 (gcc 4.6.3). The code builds and links, but the program fails with 'Invalid crypto engine' when calling gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); I tried both using the gpg2.exe or gpgconf.exe engine from gpg4win as well as from msys2 but gpgme seems unable to find it. The debug traces are actually different when building for win32 then for win64, see the logs: https://gist.github.com/jeroenooms/89a5cce89f50399f183d . On win64 the program doesn't find the gpg executable at all, whereas on win32 the initialization fails with 'CreateProcess failed: ec=87'. I tried pointing gpgme to the correct path: gpgme_set_engine_info(GPGME_PROTOCOL_OpenPGP, "C:\\GNU\\GnuPG\\gpg2", NULL); And also tried setting global flags: gpgme_set_global_flag("gpgconf-name", "C:\\GNU\\GnuPG\\gpgconf"); gpgme_set_global_flag("gpg-name", "C:\\GNU\\GnuPG\\gpg2"); I also tried installing gpg4win in another directory, but the same errors remain. So my questions: are there working examples of gpgme on windows? Should it be possible for a mingw-w64 build of gpgme to use the gpg4win engine? From neal at walfield.org Wed Jul 15 16:25:45 2015 From: neal at walfield.org (Neal H. Walfield) Date: Wed, 15 Jul 2015 16:25:45 +0200 Subject: GnuPG talk at RMLL In-Reply-To: <87fv55oupx.wl-neal@walfield.org> References: <87fv55oupx.wl-neal@walfield.org> Message-ID: <878uahlcpi.wl-neal@walfield.org> Hi, At Fri, 03 Jul 2015 22:24:26 +0200, Neal H. Walfield wrote: > I'm going to be at RMLL next week. Specifically, I'll be there from > Monday through Thursday afternoon. On Monday afternoon, I'm going to > give a talk called "An Advanced Introduction to GnuPG". (I'll also be > giving a talk about ZFS on Monday.) If anyone is around and would > like to meet up, please drop me an email. I think the talk went rather well. At least, there was a lot of interest and I don't think anyone walked out :). The video has already been posted online: https://video.rmll.info/videos/202-introduction-avancee-sur-gnupg_/ Here are the slides as a PDF: https://2015.rmll.info/IMG/pdf/an-advanced-introduction-to-gnupg.pdf I'd be happy about any feedback (either on this list or privately, if you prefer) as I plan to given this talk again in the future. :) Neal From aheinecke at intevation.de Wed Jul 15 19:59:47 2015 From: aheinecke at intevation.de (Andre Heinecke) Date: Wed, 15 Jul 2015 19:59:47 +0200 Subject: gpgme does not find engine on windows In-Reply-To: References: Message-ID: <1641582.dkUgzFfGm7@esus> Hi, On Wednesday, July 15, 2015 10:42:14 AM Jeroen Ooms wrote: > I wrote some gpgme bindings for the R programming language, and they > work great on OSX and Linux, but I am having difficulty getting it to > work on Windows. The gpgme library has been compiled with mingw-w64 > (gcc 4.6.3). The code builds and links, but the program fails with > 'Invalid crypto engine' when calling gpgme is pretty much untested as 64bit binary on Windows. Gpg4win only uses it as a 32bit binary. So I would stick with a 32 bit version of gpgme to avoid problems. > gpgme_engine_check_version(GPGME_PROTOCOL_OpenPGP); Did you initialize gpgme with gpgme_check_version [1] before this call? > I tried both using the gpg2.exe or gpgconf.exe engine from gpg4win as > well as from msys2 but gpgme seems unable to find it. If you have a working gpgconf in your PATH environment variable you should not need to set anything for gpgme to work. Can you execute gpgconf from the command line on your system? (From another working directory) > So my questions: are there working examples of gpgme on windows? Of course, check out Kleopatra, GPA etc. and take a look at gpgme/tests especially gpgme-tool.c is a good example of how you can work with gpgme. > Should it be possible for a mingw-w64 build of gpgme to use the > gpg4win engine? To be clear: As the name mingw-w64 is ambigous: 32 bit builds with mingw-w64 (i686-w64-mingw32) are well tested and is the compiler gpg4win itself uses. 64 bit ( x86_64-w64-mingw32 ) versions are untested and I don't know if they work. 1: https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check.html#index-gpgme_005fcheck_005fversion Regards, Andre -- Andre Heinecke | ++49-541-335083-262 | http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabr?ck | AG Osnabr?ck, HR B 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner From jeroen.ooms at stat.ucla.edu Wed Jul 15 22:22:42 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Wed, 15 Jul 2015 22:22:42 +0200 Subject: gpgme does not find engine on windows In-Reply-To: <1641582.dkUgzFfGm7@esus> References: <1641582.dkUgzFfGm7@esus> Message-ID: On Wed, Jul 15, 2015 at 7:59 PM, Andre Heinecke wrote: > Did you initialize gpgme with gpgme_check_version [1] before this call? Yes obliviously (otherwise it wouldn't have worked on other platforms i suppose) > If you have a working gpgconf in your PATH environment variable you should not > need to set anything for gpgme to work. Can you execute gpgconf from the > command line on your system? (From another working directory) Yes, gpg.exe gpg2.exe and gpgconf.exe are all available from the cmd shell. > Of course, check out Kleopatra, GPA etc. and take a look at gpgme/tests > especially gpgme-tool.c is a good example of how you can work with gpgme. I tried several executables in gpgme/tests such as 'run-keylist.exe' and each fails with the same error: Invalid crypto engine. I am able to execute gpgme-tool.exe (which is in ./src, not ./tests), however looking at the source it does call gpgme_engine_check_version? I am not sure how to use gpgme-tool, what command can I run to test if it actually found the engine? From gniibe at fsij.org Thu Jul 16 10:41:02 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 16 Jul 2015 17:41:02 +0900 Subject: scd: Use openpgpdefs.h for constants. Message-ID: <55A76E1E.4040603@fsij.org> Hello, Here is a simple change for better code. I'm going to commit this to master. I'll support writing key attribute for ECC after this change. * scd/app-openpgp.c: Include openpgpdefs.h. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index f5911f3..1c6d6ec 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -68,6 +68,7 @@ #include "app-common.h" #include "tlv.h" #include "host2net.h" +#include "openpgpdefs.h" /* A table describing the DOs of the card. */ @@ -748,13 +749,13 @@ static unsigned char get_algo_byte (int keynumber, key_type_t key_type) { if (key_type == KEY_TYPE_ECC && keynumber != 1) - return 19; + return PUBKEY_ALGO_ECDSA; else if (key_type == KEY_TYPE_ECC && keynumber == 1) - return 18; + return PUBKEY_ALGO_ECDH; else if (key_type == KEY_TYPE_EDDSA) - return 22; + return PUBKEY_ALGO_EDDSA; else - return 1; /* RSA */ + return PUBKEY_ALGO_RSA; } #define MAX_ARGS_STORE_FPR 3 @@ -977,7 +978,9 @@ send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int number) get_ecc_key_parameters (app->app_local->keyattr[number].ecc.curve, &n_bits, &curve_oid); snprintf (buffer, sizeof buffer, "%d %d %u %s", - number+1, number==1? 18: 19, n_bits, curve_oid); + number+1, + number==1? PUBKEY_ALGO_ECDH: PUBKEY_ALGO_ECDSA, + n_bits, curve_oid); } else if (app->app_local->keyattr[number].key_type == KEY_TYPE_EDDSA) { @@ -1071,8 +1074,9 @@ do_getattr (app_t app, ctrl_t ctrl, const char *name) app->app_local->extcap.max_certlen_3, app->app_local->extcap.algo_attr_change, (app->app_local->extcap.sm_supported - ? (app->app_local->extcap.sm_algo == 0? 2 : - (app->app_local->extcap.sm_algo == 1? 7 : 9)) + ? (app->app_local->extcap.sm_algo == 0? CIPHER_ALGO_3DES : + (app->app_local->extcap.sm_algo == 1? + CIPHER_ALGO_AES : CIPHER_ALGO_AES256)) : 0), app->app_local->status_indicator, app->app_local->extcap.has_decrypt, @@ -2832,7 +2836,7 @@ change_keyattr (app_t app, int keyno, unsigned int nbits, relptr = get_one_do (app, 0xC1+keyno, &buffer, &buflen, NULL); if (!relptr) return gpg_error (GPG_ERR_CARD); - if (buflen < 6 || buffer[0] != 1) + if (buflen < 6 || buffer[0] != PUBKEY_ALGO_RSA) { /* Attriutes too short or not an RSA key. */ xfree (relptr); @@ -2899,8 +2903,8 @@ change_keyattr_from_string (app_t app, err = gpg_error (GPG_ERR_INV_DATA); else if (keyno < 1 || keyno > 3) err = gpg_error (GPG_ERR_INV_ID); - else if (algo != 1) - err = gpg_error (GPG_ERR_PUBKEY_ALGO); /* Not RSA. */ + else if (algo != PUBKEY_ALGO_RSA) + err = gpg_error (GPG_ERR_PUBKEY_ALGO); else if (nbits < 1024) err = gpg_error (GPG_ERR_TOO_SHORT); else @@ -4433,7 +4437,7 @@ parse_algorithm_attribute (app_t app, int keyno) if (opt.verbose) log_info ("Key-Attr-%s ..: ", desc[keyno]); - if (*buffer == 1 && (buflen == 5 || buflen == 6)) + if (*buffer == PUBKEY_ALGO_RSA && (buflen == 5 || buflen == 6)) { app->app_local->keyattr[keyno].rsa.n_bits = (buffer[1]<<8 | buffer[2]); app->app_local->keyattr[keyno].rsa.e_bits = (buffer[3]<<8 | buffer[4]); @@ -4457,7 +4461,7 @@ parse_algorithm_attribute (app_t app, int keyno) app->app_local->keyattr[keyno].rsa.format == RSA_CRT? "crt" : app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N?"crt+n":"?"); } - else if (*buffer == 18 || *buffer == 19) /* ECDH or ECDSA */ + else if (*buffer == PUBKEY_ALGO_ECDH || *buffer == PUBKEY_ALGO_ECDSA) { app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECC; app->app_local->keyattr[keyno].ecc.curve @@ -4467,7 +4471,7 @@ parse_algorithm_attribute (app_t app, int keyno) ("ECC, curve=%s\n", get_curve_name (app->app_local->keyattr[keyno].ecc.curve)); } - else if (*buffer == 22) /* EdDSA */ + else if (*buffer == PUBKEY_ALGO_EDDSA) { app->app_local->keyattr[keyno].key_type = KEY_TYPE_EDDSA; app->app_local->keyattr[keyno].eddsa.curve -- From jeroen.ooms at stat.ucla.edu Fri Jul 17 00:16:00 2015 From: jeroen.ooms at stat.ucla.edu (Jeroen Ooms) Date: Fri, 17 Jul 2015 00:16:00 +0200 Subject: gpgme does not find engine on windows In-Reply-To: References: <1641582.dkUgzFfGm7@esus> Message-ID: On Wed, Jul 15, 2015 at 10:22 PM, Jeroen Ooms wrote: > I tried several executables in gpgme/tests such as 'run-keylist.exe' > and each fails with the same error: Invalid crypto engine. I am still stuck on this. Is my understanding correct that there is currently no support for linking gpgme directly to libgcrypt without the need for finding and calling gpg executables at runtime? All I really need is some bindings to verify pgp signatures, but it is surprisingly difficult to implement this using only libgcrypt. From gniibe at fsij.org Fri Jul 17 06:07:07 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 Jul 2015 13:07:07 +0900 Subject: scd: change_keyattr_from_string for ECC. Message-ID: <55A87F6B.70904@fsij.org> Hello, Here is a change for ECC support. With OpenPGPcard version 3.0, it is possible to change key attribute. So far, GnuPG's scdaemon only changes the key attribute for RSA when it's size is different. And that was done during processing "keytocard" command. In this change, I deliberately introduce an incompatible change not to change key attribute during processing "keytocard" command. I think that it is better for the gpg frontend to have a command changing key attribute and a user should check if it's correctly supported. This change is only scdaemon part. It's comming soon for gpg frontend part. Tested with Gnuk. Following commands worked. $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 2 18 nistp256" /bye $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 3 22 ed25519" /bye diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 1c6d6ec..5ca526c 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -57,12 +57,12 @@ #include "options.h" #include "errors.h" #include "memory.h" -#include "util.h" #include "cardglue.h" #else /* GNUPG_MAJOR_VERSION != 1 */ #include "scdaemon.h" #endif /* GNUPG_MAJOR_VERSION != 1 */ +#include "util.h" #include "i18n.h" #include "iso7816.h" #include "app-common.h" @@ -2818,54 +2818,25 @@ build_ecc_privkey_template (app_t app, int keyno, /* Helper for do_writekley to change the size of a key. Not ethat this deletes the entire key without asking. */ static gpg_error_t -change_keyattr (app_t app, int keyno, unsigned int nbits, +change_keyattr (app_t app, int keyno, const unsigned char *buf, size_t buflen, gpg_error_t (*pincb)(void*, const char *, char **), void *pincb_arg) { gpg_error_t err; - unsigned char *buffer; - size_t buflen; - void *relptr; assert (keyno >=0 && keyno <= 2); - if (nbits > 4096) - return gpg_error (GPG_ERR_TOO_LARGE); - - /* Read the current attributes into a buffer. */ - relptr = get_one_do (app, 0xC1+keyno, &buffer, &buflen, NULL); - if (!relptr) - return gpg_error (GPG_ERR_CARD); - if (buflen < 6 || buffer[0] != PUBKEY_ALGO_RSA) - { - /* Attriutes too short or not an RSA key. */ - xfree (relptr); - return gpg_error (GPG_ERR_CARD); - } - - /* We only change n_bits and don't touch anything else. Before we - do so, we round up NBITS to a sensible way in the same way as - gpg's key generation does it. This may help to sort out problems - with a few bits too short keys. */ - nbits = ((nbits + 31) / 32) * 32; - buffer[1] = (nbits >> 8); - buffer[2] = nbits; - /* Prepare for storing the key. */ err = verify_chv3 (app, pincb, pincb_arg); if (err) - { - xfree (relptr); - return err; - } + return err; /* Change the attribute. */ - err = iso7816_put_data (app->slot, 0, 0xC1+keyno, buffer, buflen); - xfree (relptr); + err = iso7816_put_data (app->slot, 0, 0xC1+keyno, buf, buflen); if (err) - log_error ("error changing size of key %d to %u bits\n", keyno+1, nbits); + log_error ("error changing key attribute (key=%d)\n", keyno+1); else - log_info ("size of key %d changed to %u bits\n", keyno+1, nbits); + log_info ("key attribute changed (key=%d)\n", keyno+1); flush_cache (app); parse_algorithm_attribute (app, keyno); app->did_chv1 = 0; @@ -2875,18 +2846,21 @@ change_keyattr (app_t app, int keyno, unsigned int nbits, } -/* Helper to process an setattr command for name KEY-ATTR. It expects - a string "--force " in (VALUE,VALUELEN). */ +/* Helper to process an setattr command for name KEY-ATTR. + In (VALUE,VALUELEN), it expects following string: + RSA: "--force " + ECC: "--force " + */ static gpg_error_t change_keyattr_from_string (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), void *pincb_arg, const void *value, size_t valuelen) { - gpg_error_t err; + gpg_error_t err = 0; char *string; int keyno, algo; - unsigned int nbits; + int n = 0; /* VALUE is expected to be a string but not guaranteed to be terminated. Thus copy it to an allocated buffer first. */ @@ -2899,17 +2873,91 @@ change_keyattr_from_string (app_t app, /* Because this function deletes the key we require the string "--force" in the data to make clear that something serious might happen. */ - if (sscanf (string, " --force %d %d %u", &keyno, &algo, &nbits) != 3) - err = gpg_error (GPG_ERR_INV_DATA); - else if (keyno < 1 || keyno > 3) + sscanf (string, " --force %d %d %n", &keyno, &algo, &n); + if (n < 13) + { + err = gpg_error (GPG_ERR_INV_DATA); + goto leave; + } + + if (keyno < 1 || keyno > 3) err = gpg_error (GPG_ERR_INV_ID); - else if (algo != PUBKEY_ALGO_RSA) - err = gpg_error (GPG_ERR_PUBKEY_ALGO); - else if (nbits < 1024) - err = gpg_error (GPG_ERR_TOO_SHORT); + else if (algo == PUBKEY_ALGO_RSA) + { + unsigned int nbits; + + errno = 0; + nbits = strtoul (string+n, NULL, 10); + if (errno) + err = gpg_error (GPG_ERR_INV_DATA); + else if (nbits < 1024) + err = gpg_error (GPG_ERR_TOO_SHORT); + else if (nbits > 4096) + err = gpg_error (GPG_ERR_TOO_LARGE); + else + { + unsigned char *buf; + size_t buflen; + void *relptr; + + /* Read the current attributes into a buffer. */ + relptr = get_one_do (app, 0xC1+keyno, &buf, &buflen, NULL); + if (!relptr) + { + err = gpg_error (GPG_ERR_CARD); + goto leave; + } + if (buflen < 6 || buf[0] != PUBKEY_ALGO_RSA) + { + /* Attriutes too short or not an RSA key. */ + xfree (relptr); + err = gpg_error (GPG_ERR_CARD); + goto leave; + } + + /* We only change n_bits and don't touch anything else. Before we + do so, we round up NBITS to a sensible way in the same way as + gpg's key generation does it. This may help to sort out problems + with a few bits too short keys. */ + nbits = ((nbits + 31) / 32) * 32; + buf[1] = (nbits >> 8); + buf[2] = nbits; + err = change_keyattr (app, keyno-1, buf, buflen, pincb, pincb_arg); + xfree (relptr); + } + } + else if (algo == PUBKEY_ALGO_ECDH || algo == PUBKEY_ALGO_ECDSA + || algo == PUBKEY_ALGO_EDDSA) + { + const char *oidstr; + + oidstr = openpgp_curve_to_oid (string+n, NULL); + if (!oidstr) + err = gpg_error (GPG_ERR_INV_DATA); + else + { + gcry_mpi_t m; + + err = openpgp_oid_from_str (oidstr, &m); + if (!err) + { + unsigned int len; + const unsigned char *buf = gcry_mpi_get_opaque (m, &len); + + /* We have enough room at STRING. */ + len = buf[0]; + string[0] = algo; + memcpy (string+1, buf+1, len++); + err = change_keyattr (app, keyno-1, string, len, + pincb, pincb_arg); + gcry_mpi_release (m); + } + } + } else - err = change_keyattr (app, keyno-1, nbits, pincb, pincb_arg); + err = gpg_error (GPG_ERR_PUBKEY_ALGO); + leave: xfree (string); return err; } @@ -3032,14 +3080,6 @@ rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), if (opt.verbose) log_info ("RSA modulus size is %u bits (%u bytes)\n", nbits, (unsigned int)rsa_n_len); - if (nbits && nbits != maxbits - && app->app_local->extcap.algo_attr_change) - { - /* Try to switch the key to a new length. */ - err = change_keyattr (app, keyno, nbits, pincb, pincb_arg); - if (!err) - maxbits = app->app_local->keyattr[keyno].rsa.n_bits; - } if (nbits != maxbits) { log_error (_("RSA modulus missing or not of size %d bits\n"), -- From neal at walfield.org Fri Jul 17 14:24:12 2015 From: neal at walfield.org (Neal H. Walfield) Date: Fri, 17 Jul 2015 14:24:12 +0200 Subject: TOFU Design Message-ID: <87615jkm4z.wl-neal@walfield.org> I'd like to informally present the high-level design that I'm working on for TOFU in GnuPG and some open questions. I'm interested in feedback. But if all you have to say is that you think TOFU is a bad idea, please restrain yourself. Thanks! Neal Threat Model ============ Recall that TOFU is trying to check the long-term *consistency* of bindings between identities (as embodied by the OpenPGP user id) and keys. That is, the attack we are interested in preventing is: Mallory creates a key with Alice's identify and sends a mail to Bob signed with that key so as to trick him into thinking it came from Alice. If Bob communicated with Alice before, then TOFU can detect this attack, because the key used to sign the message has changed. For convenience, I'll refer to this as the false key attack. If there is a better name for it, please correct me. Identity ======== The first issue is defining an identity. In OpenPGP, the identity is, by convention, an RFC 2822 name-addr, which has the form "John Doe (comment)" (without the quotes). There are three parts: the name, the email address and the comment. The question is: should we use the whole thing as the identity or just some pieces? In the very least, we should completely ignore the comment field. That is, a difference in the comment field of two name-addrs should not mean different identities. For example, "John Doe " and "John Doe (work)" should be considered to refer to the same identity. The reason for this is, becase the comment field is usually blank and its semantics are not well defined, most unsophisticated users wouldn't realize that differences in the comment field mean a different identity. As such, when TOFU prompts the user to accept a new identity / key binding instead of flagging a conflict, most of these users would just blindly accept the new binding. The practical result is that allowing the comment field to define identity makes users susceptible to the false key attack. We could use the name, but checking this should probably be reserved for advanced users. The first problem is that names are not globally unique. In fact, conflicts are frequent. I think that most people in the cultures that I'm familiar with probably know a few people with the same name. This would cause false negatives (the implementation identifying conflicts where, in reality, there are none). After a few incorrectly identified conflicts: most users will just click the dialog away, which would defeat the purpose of this system. Another reason to not use names is that people are liberal in identifying equivalent names and it is hard to codify this type of equivalence. For instance, strcmp would indicate that "John Doe" and "John A. Doe" are different identities. Most people, however, would say they refer to the same person. As in the comment case, these false positives simplify the false key attack. Finally, we'd have to regularize names. At least for latin and germanic languages, UTF-8 canonicalization, space compression and down casing should be enough. But, I'm not sure about other languages where letters are combined. For the same reasons, we don't want to use the combined name and email address. This leaves the email address. Although it is possible to use unicode to make two email addresses appear visually similar, but compare differently at the bit level, such discrepancies should be caught by email clients, which should check that the sender and the signer are identical. If they are not, they should issue a warning. (However, only kmail actually implements this check, as far as I know.) In conclusion: I think we should just use the regularized email address and, perhaps allow checking names for advanced users. This is similar to how ssh works. Making sure the host key for a given ip address doesn't change is nice for sophisticated users, but it results in a lot of false positives due to wideuse of a small portion of the private ip space (i.e., 192.168.1.0/24) and dongles containing the MAC address, which results in dhcp assigning the same IP to different hosts. Note: it is unclear what to do when the OpenPGP User ID is not in RFC 2822 form or there is no email address. Verification ============ To verify a message, we check a database to see if the identity / key binding has changed. Since keys can have multiple user ids, we do this for each valid user id. For each user id, we first extract and normalize the email address. - If the email address and key binding are known, we are done. - If the email address is unknown, but the key is known, then the sender added a new uid and we ask the user whether to create a new binding (good, bad, decide later). Note: we shouldn't silently create the binding. Consider an attacker who emails you (or, perhaps a mailing list you are subscribed to) a message signed with the key "John Doe ". Since it doesn't look suspicious, you download the key and add the binding to your TOFU database. Then, the attacker adds a new UID "Glenn Greenwald " and your software automatically refreshes the key. Now, messages from the attacker with the identity "Glenn Greenwald " will be trusted! Note: we could also prompt the user to call the recipient and verify the fingerprint manually. In this case we could offer multiple levels of verification. - If the email address is known, but the key isn't, the user might have a new key. In this case, we indicate this to the user as well as some information about the old key and the new key and ask whether to create the new binding. - If no bindings contain either the email address or the key, then we ask the user whether to accept the new binding. One potentially helpful thing we could do at this point is to fetch the key from the key server and to conduct a search on the email address. This would help identify potential attacks. The above method only works if the key is actually available. Of course, for new bindings, the key is probably not yet available and if the user hasn't enabled auto-key-locate (which is disabled by default), then we can't do the verification nor can we update the database. There are a couple of things that we could do here: - Issue a warning and suggest enabling auto-key-locate or running gpg2 --key-recv KEYID and then reverifing the message. - Add the key to a list of pending keys. This list can be processed by, e.g., parcimonie. Then, the next time a message signed with this key is verified, the user will be prompted about the key. Encryption ========== When encrypting a message, we should check whether the recipient is trusted. This means iterating over each of the uids associated with the key and checking whether a good binding exists in the database. If not and the binding is simply unknown, we can proceed as above with unknown bindings. If the binding is bad, then we should show an error message and abort. Export ====== Should TOFU bindings be exportable? TOFU reveals the user's social graph even more than the web of trust. However, this would allow us to implement something like the perspectives system [1]. This would make the false key attack much harder: keys would be verified via multiple network paths. On the other hard, since the data is being provided by untrusted users, it is possible for an attack to poison the data. This needs a lot more thought. [1] https://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008/ Additional Metadata =================== To make understanding binding conflicts easier, we can record previously seen messages. In particular, when we verify a message, we also save the message's hash and the signature creation time keyed on each identity / key binding. We need the message's hash to prevent adding the same message multiple times. The signature creation time is taken from the signature packet in the message. When there is a conflict or the user has added a new user id to a key, we can show the history of the key(s) (e.g., number of message signed by this key per month). If a user has received messages over many years from one key and none from another, then the new key requires further scrutiny. Implementation Details ====================== We are going to use SQLite to store the data rather than a custom binary format. SQLite is highly portable and has the nice ACID properties. This should significantly simplify the implementation. It would be nice to make the database synchronizable. For instance, when using unison, I can't synchronize my keyring since if I change both the keyring on my laptop and on my desktop, there is no easy way to merge them. By storing the data related to each binding in a separate file, it should be possible to synchronize most files. (This is based on the assumption that updates between two sychronizations by both computers to the same file are significantly less likely than updates by both computers in general.) From rjh at sixdemonbag.org Fri Jul 17 16:11:18 2015 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 17 Jul 2015 10:11:18 -0400 Subject: TOFU Design In-Reply-To: <87615jkm4z.wl-neal@walfield.org> References: <87615jkm4z.wl-neal@walfield.org> Message-ID: <55A90D06.2070903@sixdemonbag.org> > I'd like to informally present the high-level design that I'm > working on for TOFU in GnuPG and some open questions. I'm interested > in feedback. But if all you have to say is that you think TOFU is a > bad idea, please restrain yourself. I didn't see any discussion about the use case where there are multiple certificates associated with an email address. There are many people who have such arrangements for a variety of reasons: for instance, up until very recently I had an RSA certificate for signing Fedora RPMs, a DSA2 certificate I used for most email, an RSA certificate I used for testing Enigmail's smartcard support, and an ECDSA certificate I used to test Enigmail's ECC support. There needs to be some consideration for the case of multiple certificates for a given email address. It's just too commonplace to ignore. > Should TOFU bindings be exportable? Definitely not in 1.0. Get a basic system bootstrapped and running, and then revisit this issue. From gniibe at fsij.org Sat Jul 18 04:25:33 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 18 Jul 2015 11:25:33 +0900 Subject: scd: change_keyattr_from_string for ECC. In-Reply-To: <55A87F6B.70904@fsij.org> References: <55A87F6B.70904@fsij.org> Message-ID: <55A9B91D.3010109@fsij.org> Hello, This message is Cc-ed to gnupg-devel. I'm going to implement changing key attribute by scdaemon of GnuPG. For the existing OpenPGPcard implementation (of v2.0), GnuPG only partially supports changing the key attribute. That is, it only changes the length of key for RSA. To do so, scdaemon asks the card about key attribute DO, changes the bit, and sends back it to the card. Now, it will be expected to change the attribute fully for ECC. On 07/17/2015 01:07 PM, NIIBE Yutaka wrote: > With OpenPGPcard version 3.0, it is possible to change key attribute. [...] > $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye > $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 2 18 nistp256" /bye > $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 3 22 ed25519" /bye While this (change to ECC) works, I wonder how we could implement changing back to RSA from ECC. For RSA, the last byte of key attribute specifies the format of RSA key. There is no information in the host about the format of RSA of the card, when its key attribute is ECC. I think that it would be not good for host to try all possible cases until it successes. Also, it would not be good to detect manufacturer and change the behavior. It would be cleaner if host could just compose the value of '00' for the RSA format specifier and send this DO for the key attribute, and it's up to the card to change the value accordingly. I'm afraid if it conforms ISO 7816 or card things. -- From neal at walfield.org Mon Jul 20 11:16:13 2015 From: neal at walfield.org (Neal H. Walfield) Date: Mon, 20 Jul 2015 11:16:13 +0200 Subject: TOFU Design In-Reply-To: <55A90D06.2070903@sixdemonbag.org> References: <87615jkm4z.wl-neal@walfield.org> <55A90D06.2070903@sixdemonbag.org> Message-ID: <87380jkx42.wl-neal@walfield.org> Hi Robert, Thanks for taking a look at my proposal. At Fri, 17 Jul 2015 10:11:18 -0400, Robert J. Hansen wrote: > > I'd like to informally present the high-level design that I'm > > working on for TOFU in GnuPG and some open questions. I'm interested > > in feedback. But if all you have to say is that you think TOFU is a > > bad idea, please restrain yourself. > > I didn't see any discussion about the use case where there are multiple > certificates associated with an email address. There are many people > who have such arrangements for a variety of reasons: for instance, up > until very recently I had an RSA certificate for signing Fedora RPMs, a > DSA2 certificate I used for most email, an RSA certificate I used for > testing Enigmail's smartcard support, and an ECDSA certificate I used to > test Enigmail's ECC support. > > There needs to be some consideration for the case of multiple > certificates for a given email address. It's just too commonplace to > ignore. This is a good point and I should have covered it explicitly in my design document. When you say that there are multiple certificates associated with a single email address, I think you mean multiple primary keys and not multiple subkeys. When a message is signed using a subkey, I plan to use the primary key for the binding. So, in this case, nothing special needs to be done. When there are multiple primary keys with a single email address, the following happens: - The first time the email / key binding is seen, the user is prompted to verify the new binding (as usual). - When a message is verified and the email address is known, but the key isn't, then, as I wrote in my note, we assume the user might have a new key. In this case, we indicate this to the user as well as some information about the old key and the new key and ask whether to create the new binding. (I should have written all of the old keys.) What I didn't say in my previous note, but should have made explicit is that the old binding is not removed. This is because the user might still want to verify messages signed by the old key. It might make sense to say that the new key supersedes the old key and that any signatures made after the new key's creation time should be marked as suspect. However, this should be an advanced option. In the case you mention, we obviously don't want to mark the old key being superseded by the new one. > > Should TOFU bindings be exportable? > > Definitely not in 1.0. Get a basic system bootstrapped and running, and > then revisit this issue. I agree with this advice. Thanks for your feedback! :) Neal From wk at gnupg.org Mon Jul 20 12:55:11 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 12:55:11 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <559A9248.60202@giepa.de> (Alexander Strobel's message of "Mon, 6 Jul 2015 16:35:52 +0200") References: <559A3484.4020800@rundquadrat.at> <559A9248.60202@giepa.de> Message-ID: <877fpvm73k.fsf@vigenere.g10code.de> On Mon, 6 Jul 2015 16:35, Alexander.Strobel at giepa.de said: > in my opinion. As colors might be displayed wrong (if you don't use > something like web safe colors), there are some people outside which are > color blind or live in a culture where the meaning of a color is Tyre, but for the majority of users a colored frame is a good and easy to grasp hint. We do this in Kmail for about a decade and all tests showed that it worked as expected. I know that this is harder to do in Outlook. But well, security aware people won't use OL at all. > Because of this I would prefer icons and/or a textual representation. That is fine in addition to a different rendering. Inline-icons and strings are easy to fake, though. > To implement this for PGP/MIME was our understanding too. We are able to > read PGP/MIME without problems. Creating RFC conform PGP/MIME in > contrast _is_ a problem for us, as Outlook/Exchange inserts an empty > MIME part and destroys the content-type of the email and the first empty Are you using MAPISecureMessage::GetBaseMessage ? According to a telco I once did with the Outlook dev team this and the AfterWrite event allows to do perform any kind of message mangling without Outlook kicking in. We have not tested this due to the lack of funds, though. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 20 13:03:12 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 13:03:12 +0200 Subject: [TESTING] Curve25519 encryption support (update) In-Reply-To: <559C71F6.1070607@fsij.org> (NIIBE Yutaka's message of "Wed, 08 Jul 2015 09:42:30 +0900") References: <559657AE.2050900@fsij.org> <559C71F6.1070607@fsij.org> Message-ID: <87380jm6q7.fsf@vigenere.g10code.de> On Wed, 8 Jul 2015 02:42, gniibe at fsij.org said: > There are things we need to decide: OID, algo ID, and format. > Currently, I use: > > OID: 1.3.6.1.4.1.3029.1.5.1 > algo ID: ECC = 18 (not 22 nor 23) > Public key OpenPGP format: prefix 0x40 and native little endian > Libgcrypt SEXP format: Use (flags eddsa) to specify DJB format/processing > (flags comp) for prefix 0x40 I am in general fine with this because this is basically compliant with RFC-6637. The use of the the 0x40 prefix is not defined by 6637 but given that an implementation needs to understand our OID anyway I don't see a problem using a not-yet-standard prefix. The only question is whether we should use the above OID (from Peter Gutmann's arc) or use our own one. Peter: do you know whether your OID is already in use? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 20 13:11:50 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 13:11:50 +0200 Subject: Pinentry: secure memory In-Reply-To: <878uatm5j7.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 06 Jul 2015 15:48:12 -0400") References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> <87381r29tj.wl-neal@walfield.org> <878uatm5j7.fsf@alice.fifthhorseman.net> Message-ID: <87y4ibkrrd.fsf@vigenere.g10code.de> On Mon, 6 Jul 2015 21:48, dkg at fifthhorseman.net said: > Is swap the only reason to use the secure memory? Defending against Yes, for Pinentry because there is only single confidential data object to protect and we know the places were we may want to wipe it. For GnuPG this is more complicated because the secure memory area is also used to automatically wipe malloc-ed memory before a free. > So I'm not convinced the tradeoff for secure memory is worthwhile. If > you're relying on graphical toolkits, you end up relying on the toolkits > to do the right thing anyway. Looks to me that we have a rough consensus to do away with secure memory in Pinentry. > depending on native implementations for visually-integrated UI seems > like it might be a better approach, both for usability and for security. A Secure-Attention-Key like feature would be nice (i.e. greying out the entire screen except for the Pinentry) but that must be provided by the OS kernel or at least the GUI kernel. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Jul 20 16:25:43 2015 From: wk at gnupg.org (Werner Koch) Date: Mon, 20 Jul 2015 16:25:43 +0200 Subject: scd: change_keyattr_from_string for ECC. In-Reply-To: <55A9B91D.3010109@fsij.org> (NIIBE Yutaka's message of "Sat, 18 Jul 2015 11:25:33 +0900") References: <55A87F6B.70904@fsij.org> <55A9B91D.3010109@fsij.org> Message-ID: <87twsylxco.fsf@vigenere.g10code.de> On Sat, 18 Jul 2015 04:25, gniibe at fsij.org said: >> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 3 22 ed25519" /bye > > While this (change to ECC) works, I wonder how we could implement > changing back to RSA from ECC. Why not use SCD SETATTR KEY-ATTR --force 3 1 rsa2048 and handle card specific details in app-openpgp.c ? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From achim at pietig.com Mon Jul 20 15:36:33 2015 From: achim at pietig.com (Achim Pietig) Date: Mon, 20 Jul 2015 15:36:33 +0200 Subject: scd: change_keyattr_from_string for ECC. In-Reply-To: <55A9B91D.3010109@fsij.org> References: <55A87F6B.70904@fsij.org> <55A9B91D.3010109@fsij.org> Message-ID: <55ACF961.5070202@pietig.com> Hi all, I had no time to answer earlier, here noe some suggestions... Reagrds Achim Am 18.07.2015 um 04:25 schrieb NIIBE Yutaka: > Hello, > > This message is Cc-ed to gnupg-devel. > > I'm going to implement changing key attribute by scdaemon of GnuPG. > > For the existing OpenPGPcard implementation (of v2.0), GnuPG only > partially supports changing the key attribute. That is, it only > changes the length of key for RSA. To do so, scdaemon asks the card > about key attribute DO, changes the bit, and sends back it to the > card. > > Now, it will be expected to change the attribute fully for ECC. > > On 07/17/2015 01:07 PM, NIIBE Yutaka wrote: >> With OpenPGPcard version 3.0, it is possible to change key attribute. > [...] >> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 1 19 nistp256" /bye >> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 2 18 nistp256" /bye >> $ gpg-connect-agent "SCD SETATTR KEY-ATTR --force 3 22 ed25519" /bye > The card may support only one version of the specified algorithms - this may vary from maufacturer to manufacturer (developer). Actual we did not define a feature list that shows all possibilities, but i think this is not important. If a user wll change the default values he should reset the card, change the algo-attributes and then pass it to GnuPG to adminstrate the keys etc. To change the values a developer/manufacturer should suppliy a special tool that knows the card features - it is enough that GnuPG deals with the results. Changing these values will not happen very often and it is an optional feature. > While this (change to ECC) works, I wonder how we could implement > changing back to RSA from ECC. > See abouve, there should be a separete tool from the card vendor that can handle the card features... > For RSA, the last byte of key attribute specifies the format of RSA > key. > > There is no information in the host about the format of RSA of the > card, when its key attribute is ECC. I think that it would be not > good for host to try all possible cases until it successes. Also, it > would not be good to detect manufacturer and change the behavior. > No - it's no good idea to try every possible values - a special tool for teh specific card should do thus. Otherwise we need a feature list in the card that presents all possiblilties. > It would be cleaner if host could just compose the value of '00' for > the RSA format specifier and send this DO for the key attribute, and > it's up to the card to change the value accordingly. > In my implementation the card rejects wrong entries during PUT DATA, but this is a feature abd there may be implementations that do not (in ISO the values in a PUT DATA are transparent to the card). > I'm afraid if it conforms ISO 7816 or card things. > Yes, ISO is weak in that matter - but you can implement additional things and provide special tools for that. A generic software like GnuPG is not able to support all variants at the moment. From simon at josefsson.org Mon Jul 20 23:41:54 2015 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 20 Jul 2015 23:41:54 +0200 Subject: TOFU Design In-Reply-To: <87615jkm4z.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 17 Jul 2015 14:24:12 +0200") References: <87615jkm4z.wl-neal@walfield.org> Message-ID: <87wpxu1p7h.fsf@latte.josefsson.org> "Neal H. Walfield" writes: > In conclusion: I think we should just use the regularized email > address I agree. Remember that the local part is not case sensitive. > and, perhaps allow checking names for advanced users. This is similar > to how ssh works. Making sure the host key for a given ip address > doesn't change is nice for sophisticated users, but it results in a > lot of false positives due to wideuse of a small portion of the > private ip space (i.e., 192.168.1.0/24) and dongles containing the MAC > address, which results in dhcp assigning the same IP to different > hosts. I'm not sure this is useful, nor that this comparison is relevant. > Note: it is unclear what to do when the OpenPGP User ID is not in RFC > 2822 form or there is no email address. If this is about PGP or email, I suspect to just ignore those cases? There is use of OpenPGP for host keys, which puts the hostname in the User ID, but I'm not sure this TOFU stuff is applicable to those use-cases. Maybe it is though, TOFU is often used for host connections. > We are going to use SQLite to store the data rather than a custom > binary format. SQLite is highly portable and has the nice ACID > properties. This should significantly simplify the implementation. Sounds good. Have you thought about MUA considerations? How would MUAs implement and use this? How would the APIs look like? /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gniibe at fsij.org Tue Jul 21 01:23:07 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 21 Jul 2015 08:23:07 +0900 Subject: scd: change_keyattr_from_string for ECC. In-Reply-To: <87twsylxco.fsf@vigenere.g10code.de> References: <55A87F6B.70904@fsij.org> <55A9B91D.3010109@fsij.org> <87twsylxco.fsf@vigenere.g10code.de> Message-ID: <55AD82DB.2040203@fsij.org> On 07/20/2015 11:25 PM, Werner Koch wrote: > Why not use > > SCD SETATTR KEY-ATTR --force 3 1 rsa2048 > > and handle card specific details in app-openpgp.c ? Yes, I'd like to support that. And, I'm wondering HOW we can implement that. When SCDaemon composes the data to be sent, it's like: 01 08 00 00 20 00 where 01: RSA 08 00: 2048-bit modulus size (of n) 00 20: 32-bit exponent size (of e) 00: private key format from host to card is (e, p, q) OpenPGPcard allows four formats for RSA key (to be stored into the card); 00: e, p, q 01: e, p, q, n 02: e, p, q, dp, dq 03: e, p, q, dp, dq, n When the key attribute is for RSA, and being asked (by a user) to change the size of RSA key, SCDaemon only change the size of public key in the key attribute data object (by reading out the data object, then writing the changed value). That is, SCDaemon does not change the format specifier of the key attribute. When the key attribute is for ECC, and being asked to change it back to RSA, SCDaemon doesn't have an idea what format the card supports. So, I wonder: SCDaemon to (1) try all those four possibilities (2) have a card specific information which card/version support what (3) assume that (in future) the card has flag to specify which format (4) assume that the card ignore the format specifier by SCDaemon (5) not specify the format specifier and let the card decide it but... sending only 5-byte (01 08 00 00 20) for PUT DATA is OK? If (5) doesn't violate ISO 7816, this sounds good. -- From ca+gnupg-devel at esmtp.org Tue Jul 21 03:50:35 2015 From: ca+gnupg-devel at esmtp.org (Claus Assmann) Date: Mon, 20 Jul 2015 18:50:35 -0700 Subject: local part of e-mail addresses (was: TOFU Design) In-Reply-To: <87wpxu1p7h.fsf@latte.josefsson.org> References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> Message-ID: <20150721015035.GA23425@x2.esmtp.org> On Mon, Jul 20, 2015, Simon Josefsson wrote: > "Neal H. Walfield" writes: > > In conclusion: I think we should just use the regularized email > > address > I agree. Remember that the local part is not case sensitive. Wrong... the interpretation of the local part is subject to the rules of the final destination. RFC 2821 Simple Mail Transfer Protocol April 2001 ... 2.3.10 Mailbox and Address ... applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. See also the discussions on the DANE lists about looking up e-mail addresses for PGP and S/MIME keys -- there's always a large disagreement. From pgut001 at cs.auckland.ac.nz Tue Jul 21 06:02:45 2015 From: pgut001 at cs.auckland.ac.nz (Peter Gutmann) Date: Tue, 21 Jul 2015 04:02:45 +0000 Subject: [TESTING] Curve25519 encryption support (update) In-Reply-To: <87380jm6q7.fsf@vigenere.g10code.de> References: <559657AE.2050900@fsij.org> <559C71F6.1070607@fsij.org>,<87380jm6q7.fsf@vigenere.g10code.de> Message-ID: <9A043F3CF02CD34C8E74AC1594475C73AB067601@uxcn10-tdc05.UoA.auckland.ac.nz> Werner Koch writes: >The only question is whether we should use the above OID (from Peter >Gutmann's arc) or use our own one. Peter: do you know whether your OID is >already in use? If you mean whether it's still reserved for 25519 rather than being assigned to something else then no, it's permanently assigned to 25519 so won't get used for anything else. If you mean is anything else using it for 25519 then I don't know, 25519 is so new, and non-standardised for ASN.1 use, that I'm not sure whether anything's using it with things like certs. That's why I set up that OID for it, to allow it to be used in ASN.1 objects. Peter. From achim at pietig.com Tue Jul 21 08:37:09 2015 From: achim at pietig.com (Achim Pietig) Date: Tue, 21 Jul 2015 08:37:09 +0200 Subject: scd: change_keyattr_from_string for ECC. In-Reply-To: <55AD82DB.2040203@fsij.org> References: <55A87F6B.70904@fsij.org> <55A9B91D.3010109@fsij.org> <87twsylxco.fsf@vigenere.g10code.de> <55AD82DB.2040203@fsij.org> Message-ID: <55ADE895.8090202@pietig.com> Hi, answers in the text. Regards Achim Am 21.07.2015 um 01:23 schrieb NIIBE Yutaka: > On 07/20/2015 11:25 PM, Werner Koch wrote: >> Why not use >> >> SCD SETATTR KEY-ATTR --force 3 1 rsa2048 >> >> and handle card specific details in app-openpgp.c ? > > Yes, I'd like to support that. And, I'm wondering HOW we can > implement that. > > When SCDaemon composes the data to be sent, it's like: > > 01 08 00 00 20 00 > > where > > 01: RSA > 08 00: 2048-bit modulus size (of n) > 00 20: 32-bit exponent size (of e) > 00: private key format from host to card is (e, p, q) > > OpenPGPcard allows four formats for RSA key (to be stored into the > card); > > 00: e, p, q > 01: e, p, q, n > 02: e, p, q, dp, dq > 03: e, p, q, dp, dq, n > My cards <= V2 do not allow to change the private key format byte and algo-ID, because it is hardware specific. You can change only byte 2-7. Cards >= V3 allow changing byte one (algo-ID) and dependent from that changing byte 2-7 (RSA) or OID (ECC). Other values are rejected. Plain ISO cards that do not support parsing of data in PUT DATA may have a different behaviour - in most caeses they will not support this in general. > When the key attribute is for RSA, and being asked (by a user) to > change the size of RSA key, SCDaemon only change the size of public > key in the key attribute data object (by reading out the data object, > then writing the changed value). That is, SCDaemon does not change > the format specifier of the key attribute. > That is OK for all card <= V2. > When the key attribute is for ECC, and being asked to change it back > to RSA, SCDaemon doesn't have an idea what format the card supports. > That is a problem because there is no feature list available - Extended Capabilites show only values needed for runtime. Can be solved only by special tools from the card developers. > So, I wonder: SCDaemon to > > (1) try all those four possibilities > (2) have a card specific information which card/version support what > (3) assume that (in future) the card has flag to specify which format > (4) assume that > the card ignore the format specifier by SCDaemon > (5) not specify the format specifier and let the card decide it > but... sending only 5-byte (01 08 00 00 20) for PUT DATA is OK? > > If (5) doesn't violate ISO 7816, this sounds good. > A featue list (all missing possibilities of the card) can be added, because there is only few usage I did not mention it up to now. In PUT DATA the whole DO has to be sent, partial data are not possible. A card may check the values (my do) and reject incompatible input - but there may be implementations that do not pasrse and allow all values. In that case the card will not run properly after the changes. From wk at gnupg.org Tue Jul 21 11:26:59 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Jul 2015 11:26:59 +0200 Subject: [TESTING] Curve25519 encryption support (update) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AB067601@uxcn10-tdc05.UoA.auckland.ac.nz> (Peter Gutmann's message of "Tue, 21 Jul 2015 04:02:45 +0000") References: <559657AE.2050900@fsij.org> <559C71F6.1070607@fsij.org> <87380jm6q7.fsf@vigenere.g10code.de> <9A043F3CF02CD34C8E74AC1594475C73AB067601@uxcn10-tdc05.UoA.auckland.ac.nz> Message-ID: <874mkxj1y4.fsf@vigenere.g10code.de> On Tue, 21 Jul 2015 06:02, pgut001 at cs.auckland.ac.nz said: > If you mean whether it's still reserved for 25519 rather than being assigned > to something else then no, it's permanently assigned to 25519 so won't get I expected nothing else. > I don't know, 25519 is so new, and non-standardised for ASN.1 use, that I'm > not sure whether anything's using it with things like certs. That's why I set > up that OID for it, to allow it to be used in ASN.1 objects. Okay, to avoid using several OIDs for the same thing we will use it in GnuPG and hopefully also in rfc4880bis. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Tue Jul 21 13:24:42 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 21 Jul 2015 13:24:42 +0200 Subject: local part of e-mail addresses (was: TOFU Design) In-Reply-To: <20150721015035.GA23425@x2.esmtp.org> References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> <20150721015035.GA23425@x2.esmtp.org> Message-ID: <87si8hkb2d.wl-neal@walfield.org> At Mon, 20 Jul 2015 18:50:35 -0700, Claus Assmann wrote: > > On Mon, Jul 20, 2015, Simon Josefsson wrote: > > "Neal H. Walfield" writes: > > > > In conclusion: I think we should just use the regularized email > > > address > > > I agree. Remember that the local part is not case sensitive. > > Wrong... the interpretation of the local part is subject to > the rules of the final destination. > > RFC 2821 Simple Mail Transfer Protocol April 2001 > ... > 2.3.10 Mailbox and Address > ... > applications than simple "user names". Consequently, and due to a > long history of problems when intermediate hosts have attempted to > optimize transport by modifying them, the local-part MUST be > interpreted and assigned semantics only by the host specified in the > domain part of the address. > > > See also the discussions on the DANE lists about looking up e-mail > addresses for PGP and S/MIME keys -- there's always a large > disagreement. This is a good point. However, I think in this case, it makes sense to regularize the local part as well. Imagine an attacker creates a key with the email address Neal at walfield.org and my key has neal at walfield.org. If you already have a TOFU entry for my key and then you get an email signed with the bad key, then not regularizing the email address will result in gpg prompting the user to create a new TOFU entry. On the other hand, if we regularize the email address, then GnuPG will detect a conflict. Of course, this introduces a potential for false positives. However, I think it is extremely rare that email addresses like neal at walfield.org and Neal at walfield.org are distinct. Thus, I think in this case, regularizing is the right approach. Thanks! :) Neal From neal at walfield.org Tue Jul 21 13:58:16 2015 From: neal at walfield.org (Neal H. Walfield) Date: Tue, 21 Jul 2015 13:58:16 +0200 Subject: TOFU Design In-Reply-To: <87wpxu1p7h.fsf@latte.josefsson.org> References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> Message-ID: <87r3o1k9if.wl-neal@walfield.org> Hi Simon, Thanks for your thoughts! At Mon, 20 Jul 2015 23:41:54 +0200, Simon Josefsson wrote: > "Neal H. Walfield" writes: > > and, perhaps allow checking names for advanced users. This is similar > > to how ssh works. Making sure the host key for a given ip address > > doesn't change is nice for sophisticated users, but it results in a > > lot of false positives due to wideuse of a small portion of the > > private ip space (i.e., 192.168.1.0/24) and dongles containing the MAC > > address, which results in dhcp assigning the same IP to different > > hosts. > > I'm not sure this is useful, nor that this comparison is relevant. The point of the comparison is that like the ssh ip address check checking the name would result in many false positives, which most people find very annoying. But, for the truly paranoid, this check provides value. Consider the following two bindings: - Neal H. Walfield / KEY1 - Neal H. Walfield / KEY2 Just using the email address would result in a prompt for a new TOFU entry. Checking the name reveals a possible attack. But, the following two are probably legitimate: John Smith John Smith > > Note: it is unclear what to do when the OpenPGP User ID is not in RFC > > 2822 form or there is no email address. > > If this is about PGP or email, I suspect to just ignore those cases? > There is use of OpenPGP for host keys, which puts the hostname in the > User ID, but I'm not sure this TOFU stuff is applicable to those > use-cases. Maybe it is though, TOFU is often used for host connections. This is about verifying all OpenPGP messages, not just email messages. I'm a bit confused by the first sentence in this paragraph. Do you mean over instead of or? If you really mean or, can you please elaborate? The point of hostnames is a good one. Probably if the user-id does not appear to be a legitimate 2822 name-addr, then we should just use the whole thing (after regularizing it). > Have you thought about MUA considerations? How would MUAs implement and > use this? How would the APIs look like? I don't think MUAs have to be modified much at all. Assuming they use gpg --verify to check mails, the user just needs to set the right trust model. For most of the required interactions, we can simply use pinentry. Thanks! :) Neal From wk at gnupg.org Tue Jul 21 14:24:42 2015 From: wk at gnupg.org (Werner Koch) Date: Tue, 21 Jul 2015 14:24:42 +0200 Subject: local part of e-mail addresses In-Reply-To: <87si8hkb2d.wl-neal@walfield.org> (Neal H. Walfield's message of "Tue, 21 Jul 2015 13:24:42 +0200") References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> <20150721015035.GA23425@x2.esmtp.org> <87si8hkb2d.wl-neal@walfield.org> Message-ID: <87twsxhf5h.fsf@vigenere.g10code.de> On Tue, 21 Jul 2015 13:24, neal at walfield.org said: > introduces a potential for false positives. However, I think it is > extremely rare that email addresses like neal at walfield.org and > Neal at walfield.org are distinct. Thus, I think in this case, > regularizing is the right approach. I concur. People actually tend to change capitalization of mail addresses so that common MUA configurations ignore the case. GnuPG's PKA system hashes the local-part but downcases all plain ASCII characters first. Characters with the MSB set are not touched and hashed verbatim. The reason for that the latter is that the rules for changing the case of characters > 127 depend on the locale and are sometimes not correctly implemented if at all well defined. This is all done on the UTF-8 encoding without any IDNA transformation. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Alexander.Strobel at giepa.de Wed Jul 22 09:34:21 2015 From: Alexander.Strobel at giepa.de (Alexander Strobel) Date: Wed, 22 Jul 2015 09:34:21 +0200 Subject: Memory Hole discussion / OpenPGP e-mail header protection In-Reply-To: <877fpvm73k.fsf@vigenere.g10code.de> References: <559A3484.4020800@rundquadrat.at> <559A9248.60202@giepa.de> <877fpvm73k.fsf@vigenere.g10code.de> Message-ID: <55AF477D.9000005@giepa.de> > I know that this is harder to do in Outlook. But well, security aware > people won't use OL at all. Well, this depends on the threat model. ;) >> Because of this I would prefer icons and/or a textual representation. > > That is fine in addition to a different rendering. Inline-icons and > strings are easy to fake, though. Right, this way I didn't see it until now. But I like the idea of Mailvelope with displaying an user defined icon. >> To implement this for PGP/MIME was our understanding too. >> We are able to read PGP/MIME without problems. Creating RFC conform >> PGP/MIME in contrast _is_ a problem for us, as Outlook/Exchange >> inserts an empty MIME part and destroys the content-type of the >> email and the first empty > > Are you using MAPISecureMessage::GetBaseMessage ? According to a telco > I once did with the Outlook dev team this and the AfterWrite event > allows to do perform any kind of message mangling without Outlook > kicking in. We have not tested this due to the lack of funds, though. No, as this is in non managed code and we try not to mix up these as far as possible. But it is an interesting starting point and we will evaluate if this might work for us. Regards Alex Strobel www.gpg4o.com Am 20.07.2015 um 12:55 schrieb Werner Koch: > On Mon, 6 Jul 2015 16:35, Alexander.Strobel at giepa.de said: > >> in my opinion. As colors might be displayed wrong (if you don't use >> something like web safe colors), there are some people outside which are >> color blind or live in a culture where the meaning of a color is > > Tyre, but for the majority of users a colored frame is a good and easy > to grasp hint. We do this in Kmail for about a decade and all tests > showed that it worked as expected. > > I know that this is harder to do in Outlook. But well, security aware > people won't use OL at all. > >> Because of this I would prefer icons and/or a textual representation. > > That is fine in addition to a different rendering. Inline-icons and > strings are easy to fake, though. > >> To implement this for PGP/MIME was our understanding too. We are able to >> read PGP/MIME without problems. Creating RFC conform PGP/MIME in >> contrast _is_ a problem for us, as Outlook/Exchange inserts an empty >> MIME part and destroys the content-type of the email and the first empty > > Are you using MAPISecureMessage::GetBaseMessage ? According to a telco > I once did with the Outlook dev team this and the AfterWrite event > allows to do perform any kind of message mangling without Outlook > kicking in. We have not tested this due to the lack of funds, though. > > > > Shalom-Salam, > > Werner > > From koto at google.com Wed Jul 22 09:26:04 2015 From: koto at google.com (Krzysztof Kotowicz) Date: Wed, 22 Jul 2015 09:26:04 +0200 Subject: Checksum error when importing unencrypted ECC private keys Message-ID: When trying to import unencrypted ECDSA/ECDH private key into GnuPG 2.1.5/2.1.6, I'm getting the following error: gpg: key F8BE8F0F/F8BE8F0F: error sending to agent: Checksum error The same key imports correctly once it's encrypted to a passphrase, also the public key imports ok. Keypair has been generated by Google End-To-End. The issue, together with the offending key, is described in greater details at https://github.com/google/end-to-end/issues/326#issuecomment-123585977, but the keypair is basically: # off=0 ctb=c5 tag=5 hlen=6 plen=165 new-ctb :secret key packet: version 4, algo 19, created 0, expires 0 pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7) pkey[1]: [515 bits] iter+salt S2K, algo: 9, SHA1 protection, hash: 2, salt: C976A61DE8AFB85D protect count: 65536 (96) protect IV: 02 38 f0 2b 32 04 1f 69 41 6d 41 8e 78 a5 14 b5 skey[2]: [v4 protected] keyid: 03288C74F8BE8F0F # off=171 ctb=cd tag=13 hlen=6 plen=22 new-ctb :user ID packet: "" # off=199 ctb=c2 tag=2 hlen=6 plen=141 new-ctb :signature packet: algo 19, keyid 03288C74F8BE8F0F version 4, created 1437396427, md5len 0, sigclass 0x10 digest algo 8, begin of digest 88 12 critical hashed subpkt 2 len 4 (sig created 2015-07-20) critical hashed subpkt 11 len 1 (pref-sym-algos: 9) critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F) critical hashed subpkt 21 len 4 (pref-hash-algos: 8 9 10 11) critical hashed subpkt 22 len 2 (pref-zip-algos: 1 2) critical hashed subpkt 27 len 1 (key flags: 03) critical hashed subpkt 30 len 1 (features: 01) data: [252 bits] data: [253 bits] # off=346 ctb=c7 tag=7 hlen=6 plen=169 new-ctb :secret sub key packet: version 4, algo 18, created 0, expires 0 pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7) pkey[1]: [515 bits] pkey[2]: [32 bits] iter+salt S2K, algo: 9, SHA1 protection, hash: 2, salt: CA65C8117A0CDB81 protect count: 65536 (96) protect IV: 2d ed 4f 26 04 2f 44 10 8d 6a dc 69 a7 93 93 82 skey[3]: [v4 protected] keyid: A6ED196C7C513F1E # off=521 ctb=c2 tag=2 hlen=6 plen=109 new-ctb :signature packet: algo 19, keyid 03288C74F8BE8F0F version 4, created 1437396427, md5len 0, sigclass 0x18 digest algo 8, begin of digest f3 c1 critical hashed subpkt 2 len 4 (sig created 2015-07-20) critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F) critical hashed subpkt 27 len 1 (key flags: 0C) data: [256 bits] data: [256 bits] # off=636 ctb=c6 tag=6 hlen=6 plen=82 new-ctb :public key packet: version 4, algo 19, created 0, expires 0 pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7) pkey[1]: [515 bits] keyid: 03288C74F8BE8F0F # off=724 ctb=cd tag=13 hlen=6 plen=22 new-ctb :user ID packet: "" # off=752 ctb=c2 tag=2 hlen=6 plen=141 new-ctb :signature packet: algo 19, keyid 03288C74F8BE8F0F version 4, created 1437396427, md5len 0, sigclass 0x10 digest algo 8, begin of digest 88 12 critical hashed subpkt 2 len 4 (sig created 2015-07-20) critical hashed subpkt 11 len 1 (pref-sym-algos: 9) critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F) critical hashed subpkt 21 len 4 (pref-hash-algos: 8 9 10 11) critical hashed subpkt 22 len 2 (pref-zip-algos: 1 2) critical hashed subpkt 27 len 1 (key flags: 03) critical hashed subpkt 30 len 1 (features: 01) data: [252 bits] data: [253 bits] # off=899 ctb=ce tag=14 hlen=6 plen=86 new-ctb :public sub key packet: version 4, algo 18, created 0, expires 0 pkey[0]: [72 bits] nistp256 (1.2.840.10045.3.1.7) pkey[1]: [515 bits] pkey[2]: [32 bits] keyid: A6ED196C7C513F1E # off=991 ctb=c2 tag=2 hlen=6 plen=109 new-ctb :signature packet: algo 19, keyid 03288C74F8BE8F0F version 4, created 1437396427, md5len 0, sigclass 0x18 digest algo 8, begin of digest f3 c1 critical hashed subpkt 2 len 4 (sig created 2015-07-20) critical hashed subpkt 16 len 8 (issuer key ID 03288C74F8BE8F0F) critical hashed subpkt 27 len 1 (key flags: 0C) data: [255 bits] data: [256 bits] -----BEGIN PGP PRIVATE KEY BLOCK----- Charset: UTF-8 Version: End-To-End v0.3.1342 xf8AAAClBAAAAAATCCqGSM49AwEHAgMEmUwnXtxBvQY+nXvduAbd626NmYshRVi4 HULGQ9fAHjKqfld4qWk97o+ggZDAnhQJ/Jm3ljtXr3/SosXUsSh7AP4JAwLJdqYd 6K+4XWACOPArMgQfaUFtQY54pRS1Vo98N4Jpw7o0iYAr80y40s5DaBIcUD5UuMHM p5no4vv8/hVCkIWJvoD/08rIzJDYEc9h2S4Lzf8AAAAWPGV4YW1wbGVAYW5vdGhl ci50ZXN0PsL/AAAAjQQQEwgAP/8AAAAFglWs7cv/AAAAAosJ/wAAAAmQAyiMdPi+ jw//AAAABZUICQoL/wAAAAOWAQL/AAAAApsD/wAAAAKeAQAAiBIA/AvNA8R65IiA QxxeRFoLszPoFE2+MZiHUwCdsBlDp0zqAP0aVriTSlN5HbZ55qnHvPP/4zfFRdR6 NATjR9W+3UVeIsf/AAAAqQQAAAAAEggqhkjOPQMBBwIDBMn29++Qg1NOQtwV4xWN 7RmxhJhq04DY9JQM3W4u01ZubYh4nXDVjx0kD0vGjJsoB9tzryJEwZiXQh0d/JRi A/4DAQgH/gkDAsplyBF6DNuBYC3tTyYEL0QQjWrcaaeTk4JSb93mog6QlL610EO5 +muowWT9Dl8Ll77BjQSpj7mmqGHIj/IxJubOYqa+iW1e4pj5qlXCaBbC/wAAAG0E GBMIAB//AAAABYJVrO3L/wAAAAmQAyiMdPi+jw//AAAAApsMAADzwQEAq95OmyQ8 3XRyVDpN4IWqWrnWOEHlmHM9KrrgKEHunycBAJr1olmd5A68wOq43/W+kkoy8Mcd cH4SAiy4DMvQO18vxv8AAABSBAAAAAATCCqGSM49AwEHAgMEmUwnXtxBvQY+nXvd uAbd626NmYshRVi4HULGQ9fAHjKqfld4qWk97o+ggZDAnhQJ/Jm3ljtXr3/SosXU sSh7AM3/AAAAFjxleGFtcGxlQGFub3RoZXIudGVzdD7C/wAAAI0EEBMIAD//AAAA BYJVrO3L/wAAAAKLCf8AAAAJkAMojHT4vo8P/wAAAAWVCAkKC/8AAAADlgEC/wAA AAKbA/8AAAACngEAAIgSAPwLzQPEeuSIgEMcXkRaC7Mz6BRNvjGYh1MAnbAZQ6dM 6gD9Gla4k0pTeR22eeapx7zz/+M3xUXUejQE40fVvt1FXiLO/wAAAFYEAAAAABII KoZIzj0DAQcCAwTJ9vfvkINTTkLcFeMVje0ZsYSYatOA2PSUDN1uLtNWbm2IeJ1w 1Y8dJA9LxoybKAfbc68iRMGYl0IdHfyUYgP+AwEIB8L/AAAAbQQYEwgAH/8AAAAF glWs7cv/AAAACZADKIx0+L6PD/8AAAACmwwAAPPBAP9qFpKqiAx+VKUYlFRnpBvn UQBpgEHmcv+7VyRYuH8IIQEAzzcIXOHWolfNieXkMk0A+ePiMmAkq1LE6Gdu+WTr bDE= =Sgsj -----END PGP PRIVATE KEY BLOCK----- It seems to be the same issue as mentioned in https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029444.html (was it fixed then?). -- koto@ / Krzysztof Kotowicz / Google From wk at gnupg.org Wed Jul 22 12:01:41 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jul 2015 12:01:41 +0200 Subject: TOFU Design In-Reply-To: <87615jkm4z.wl-neal@walfield.org> (Neal H. Walfield's message of "Fri, 17 Jul 2015 14:24:12 +0200") References: <87615jkm4z.wl-neal@walfield.org> Message-ID: <87mvyofr3u.fsf@vigenere.g10code.de> On Fri, 17 Jul 2015 14:24, neal at walfield.org said: > Finally, we'd have to regularize names. At least for latin and > germanic languages, UTF-8 canonicalization, space compression and down > casing should be enough. But, I'm not sure about other languages > where letters are combined. Just to clarify: GnuPG only knows about UTF-8 (as per OpenPGP) and it does not handle IDNA etc. Any mapping to the encoding required for example by rfc822 has to be done outside of GnuPG. > Note: it is unclear what to do when the OpenPGP User ID is not in RFC > 2822 form or there is no email address. I suggest to ignore such a user id. See gnupg/common/mbox-util.c:mailbox_from_userid on GnuPG parses userids. > Verification > ============ > - If no bindings contain either the email address or the key, then > we ask the user whether to accept the new binding. For TOFU alone this would be okay but TOFU is only one part of the story. We need to limit user interaction to the bare minimum. Thus in this case we need to lookup the key using DNS (PKA style CERT records) by th mail address. The binding should have a "Initial-Source" field to record that the binding has been created from a) PKA b) keyserver lookup by fingerprint c) a key send with a message d) the verification of a signed message e) a manually imported key with verified fingerprint (keysigning). This information can be useful in cae of a conflict. For example a manually imported key should be more trustworthy than one take from a keyserver. The exact rules need to be worked out but tracking the source needs to be there right from the beginning. > course, for new bindings, the key is probably not yet available and if > the user hasn't enabled auto-key-locate (which is disabled by > default), then we can't do the verification nor can we update the We need to change some of the defaults - at least for email use. Traffic patterns are anyway not protected and thus it does not sense to avoid network access by default. For those who need it they can use --disable-dirmngr to avoid all kind of network access or use the proposed --enable-tor option. The goal is to increase the use of encrypted mail and not to be safe against targeted attacks by default. > Export > ====== > > Should TOFU bindings be exportable? TOFU reveals the user's social No. That should be kept local like the trustdb. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jul 22 12:57:36 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jul 2015 12:57:36 +0200 Subject: [PATCH] GPGME: remove BUILD_TIMESTAMP In-Reply-To: <1436375850-26861-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 8 Jul 2015 13:17:30 -0400") References: <1436375850-26861-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87io9cfoin.fsf@vigenere.g10code.de> On Wed, 8 Jul 2015 19:17, dkg at fifthhorseman.net said: > If removal of BUILD_TIMESTAMP isn't acceptable for gpgme, we should > allow it to be externally set for people who are trying to rebuild the > package reproducibly. Last year you added this to libgpg-error: This patch allows an external build system to set this embedded timestamp explicitly, which appears to make the package build repeatably when ./configure is called with (for example) --enable-build-timestamp=2014-09-23T01:02+0000 The default is to use the actual time for the build, using --disable-build-timestamp will use "" for the timestamp. We should use a default for all packages. At least for Windows the build timestamp is useful for debugging and thus I would like to keep it. However, changing the default to is also fine with me. For Gpg4win I would then change the default. Shall I change all packages to this scheme? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jul 22 13:13:46 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jul 2015 13:13:46 +0200 Subject: [PATCH] improve documentation about VALIDSIG In-Reply-To: <1436284816-5796-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 7 Jul 2015 12:00:16 -0400") References: <1436284816-5796-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87si8ge979.fsf@vigenere.g10code.de> Applied, thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Jul 22 13:13:38 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 22 Jul 2015 13:13:38 +0200 Subject: [PATCH] clarify constraints on who modifies files in ~/.gnupg In-Reply-To: <1436275001-32684-1-git-send-email-dkg@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 7 Jul 2015 09:16:41 -0400") References: <1436275001-32684-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <87wpxse97h.fsf@vigenere.g10code.de> Applied, thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Wed Jul 22 17:17:49 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 22 Jul 2015 17:17:49 +0200 Subject: [PATCH] GPGME: remove BUILD_TIMESTAMP In-Reply-To: <87io9cfoin.fsf@vigenere.g10code.de> References: <1436375850-26861-1-git-send-email-dkg@fifthhorseman.net> <87io9cfoin.fsf@vigenere.g10code.de> Message-ID: <87zj2oi5lu.fsf@alice.fifthhorseman.net> On Wed 2015-07-22 12:57:36 +0200, Werner Koch wrote: > On Wed, 8 Jul 2015 19:17, dkg at fifthhorseman.net said: > >> If removal of BUILD_TIMESTAMP isn't acceptable for gpgme, we should >> allow it to be externally set for people who are trying to rebuild the >> package reproducibly. > > Last year you added this to libgpg-error: > > This patch allows an external build system to set this embedded > timestamp explicitly, which appears to make the package build > repeatably when ./configure is called with (for example) > --enable-build-timestamp=2014-09-23T01:02+0000 > > The default is to use the actual time for the build, using > --disable-build-timestamp will use "" for the timestamp. We > should use a default for all packages. > > At least for Windows the build timestamp is useful for debugging and > thus I would like to keep it. However, changing the default to > is also fine with me. For Gpg4win I would then change the default. > > Shall I change all packages to this scheme? I'd be happy to have --disable-build-timestamp as the default for all packages. Thanks for the consideration! --dkg From cloos at jhcloos.com Thu Jul 23 01:37:56 2015 From: cloos at jhcloos.com (James Cloos) Date: Wed, 22 Jul 2015 19:37:56 -0400 Subject: local part of e-mail addresses In-Reply-To: <20150721015035.GA23425@x2.esmtp.org> (Claus Assmann's message of "Mon, 20 Jul 2015 18:50:35 -0700") References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> <20150721015035.GA23425@x2.esmtp.org> Message-ID: >>>>> "CA" == Claus Assmann writes: CA> Wrong... the interpretation of the local part is subject to CA> the rules of the final destination. This came up recently on the dane list. Even though it may not be the case for smtp et alia, localparts are case-insensitive in openpgp. In, evidently, every implementation, if not in the rfc. (Although maybe there, too.) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From gniibe at fsij.org Thu Jul 23 07:17:59 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 23 Jul 2015 14:17:59 +0900 Subject: scd: Format change to specify "rsa2048" for KEY-ATTR. Message-ID: <55B07907.2010800@fsij.org> Hello, While new OpenPGPcard supports keys other than RSA, here is a kind of clean up. I'm going to push this. More will come soon. * g10/card-util.c (do_change_keysize): Put "rsa". * scd/app-openpgp.c (change_keyattr, change_keyattr_from_string): Change the command format. (rsa_writekey): Check key type. (do_writekey): Remove "ecdh" and "ecdsa" support which was available in experimental libgcrypt before 1.6.0. diff --git a/g10/card-util.c b/g10/card-util.c index dbd530e..890bf2d 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -1332,7 +1332,7 @@ do_change_keysize (int keyno, unsigned int nbits) gpg_error_t err; char args[100]; - snprintf (args, sizeof args, "--force %d 1 %u", keyno+1, nbits); + snprintf (args, sizeof args, "--force %d 1 rsa%u", keyno+1, nbits); err = agent_scd_setattr ("KEY-ATTR", args, strlen (args), NULL); if (err) log_error (_("error changing size of key %d to %u bits: %s\n"), diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 5ca526c..81b4923 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -2848,7 +2848,7 @@ change_keyattr (app_t app, int keyno, const unsigned char *buf, size_t buflen, /* Helper to process an setattr command for name KEY-ATTR. In (VALUE,VALUELEN), it expects following string: - RSA: "--force " + RSA: "--force rsa" ECC: "--force " */ static gpg_error_t @@ -2887,7 +2887,7 @@ change_keyattr_from_string (app_t app, unsigned int nbits; errno = 0; - nbits = strtoul (string+n, NULL, 10); + nbits = strtoul (string+n+3, NULL, 10); if (errno) err = gpg_error (GPG_ERR_INV_DATA); else if (nbits < 1024) @@ -2985,6 +2985,13 @@ rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), unsigned char fprbuf[20]; u32 created_at = 0; + if (app->app_local->keyattr[keyno].key_type != KEY_TYPE_RSA) + { + log_error (_("unsupported algorithm: %s"), "RSA"); + err = gpg_error (GPG_ERR_INV_VALUE); + goto leave; + } + last_depth1 = depth; while (!(err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)) && depth && depth >= last_depth1) @@ -3519,10 +3526,7 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; if (tok && toklen == 3 && memcmp ("rsa", tok, toklen) == 0) err = rsa_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); - else if (tok - && ((toklen == 3 && memcmp ("ecc", tok, toklen) == 0) - || (toklen == 4 && memcmp ("ecdh", tok, toklen) == 0) - || (toklen == 5 && memcmp ("ecdsa", tok, toklen) == 0))) + else if (tok && toklen == 3 && memcmp ("ecc", tok, toklen) == 0) err = ecc_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); else { -- From gniibe at fsij.org Thu Jul 23 09:06:50 2015 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 23 Jul 2015 16:06:50 +0900 Subject: scd: more changes for ECC. In-Reply-To: <55B07907.2010800@fsij.org> References: <55B07907.2010800@fsij.org> Message-ID: <55B0928A.3020501@fsij.org> On 07/23/2015 02:17 PM, NIIBE Yutaka wrote: > More will come soon. Here is more clean up for ECC. With this, curves defined in libgcrypt can be used. I don't test it, but, I believe that Brainpool works if card support it. diff --git a/g10/call-agent.c b/g10/call-agent.c index edee66e..0df572a 100644 --- a/g10/call-agent.c +++ b/g10/call-agent.c @@ -645,14 +645,32 @@ learn_status_cb (void *opaque, const char *line) } else if (keywordlen == 8 && !memcmp (keyword, "KEY-ATTR", keywordlen)) { - int keyno, algo, nbits; + int keyno = 0; + int algo = PUBKEY_ALGO_RSA; + int n = 0; - sscanf (line, "%d %d %d", &keyno, &algo, &nbits); + sscanf (line, "%d %d %n", &keyno, &algo, &n); keyno--; - if (keyno >= 0 && keyno < DIM (parm->key_attr)) + if (keyno < 0 || keyno >= DIM (parm->key_attr)) + return 0; + + parm->key_attr[keyno].algo = algo; + if (algo == PUBKEY_ALGO_RSA) + parm->key_attr[keyno].nbits = strtoul (line+n+3, NULL, 10); + else if (algo == PUBKEY_ALGO_ECDH || algo == PUBKEY_ALGO_ECDSA + || algo == PUBKEY_ALGO_EDDSA) { - parm->key_attr[keyno].algo = algo; - parm->key_attr[keyno].nbits = nbits; + const char *curve; + + i = 0; + do + { + curve = openpgp_enum_curves (&i); + if (!strcmp (curve, line+n)) + break; + } + while (curve != NULL); + parm->key_attr[keyno].curve = curve; } } else if (keywordlen == 12 && !memcmp (keyword, "PRIVATE-DO-", 11) diff --git a/g10/call-agent.h b/g10/call-agent.h index df570a4..70421db 100644 --- a/g10/call-agent.h +++ b/g10/call-agent.h @@ -55,7 +55,10 @@ struct agent_card_info_s int chvretry[3]; /* Allowed retries for the CHV; 0 = blocked. */ struct { /* Array with key attributes. */ int algo; /* Algorithm identifier. */ - unsigned int nbits; /* Supported keysize. */ + union { + unsigned int nbits; /* Supported keysize. */ + const char *curve; /* Name of curve. */ + }; } key_attr[3]; struct { unsigned int ki:1; /* Key import available. */ diff --git a/g10/card-util.c b/g10/card-util.c index 890bf2d..ed69058 100644 --- a/g10/card-util.c +++ b/g10/card-util.c @@ -471,9 +471,14 @@ card_status (estream_t fp, char *serialno, size_t serialnobuflen) es_fprintf (fp, "forcepin:%d:::\n", !info.chv1_cached); for (i=0; i < DIM (info.key_attr); i++) - if (info.key_attr[0].algo) + if (info.key_attr[0].algo == PUBKEY_ALGO_RSA) es_fprintf (fp, "keyattr:%d:%d:%u:\n", i+1, info.key_attr[i].algo, info.key_attr[i].nbits); + else if (info.key_attr[i].algo == PUBKEY_ALGO_ECDH + || info.key_attr[i].algo == PUBKEY_ALGO_ECDSA + || info.key_attr[i].algo == PUBKEY_ALGO_EDDSA) + es_fprintf (fp, "keyattr:%d:%d:%s:\n", i+1, + info.key_attr[i].algo, info.key_attr[i].curve); es_fprintf (fp, "maxpinlen:%d:%d:%d:\n", info.chvmaxlen[0], info.chvmaxlen[1], info.chvmaxlen[2]); es_fprintf (fp, "pinretry:%d:%d:%d:\n", @@ -553,12 +558,12 @@ card_status (estream_t fp, char *serialno, size_t serialnobuflen) { tty_fprintf (fp, "Key attributes ...:"); for (i=0; i < DIM (info.key_attr); i++) - tty_fprintf (fp, " %u%c", - info.key_attr[i].nbits, - info.key_attr[i].algo == 1? 'R': - info.key_attr[i].algo == 17? 'D': - info.key_attr[i].algo == 18? 'e': - info.key_attr[i].algo == 19? 'E': '?'); + if (info.key_attr[i].algo == PUBKEY_ALGO_RSA) + tty_fprintf (fp, " rsa%u", info.key_attr[i].nbits); + else if (info.key_attr[i].algo == PUBKEY_ALGO_ECDH + || info.key_attr[i].algo == PUBKEY_ALGO_ECDSA + || info.key_attr[i].algo == PUBKEY_ALGO_EDDSA) + tty_fprintf (fp, " %s", info.key_attr[i].curve); tty_fprintf (fp, "\n"); } tty_fprintf (fp, "Max. PIN lengths .: %d %d %d\n", diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 81b4923..72f7640 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -126,7 +126,6 @@ static struct { typedef enum { KEY_TYPE_ECC, - KEY_TYPE_EDDSA, KEY_TYPE_RSA, } key_type_t; @@ -144,18 +143,6 @@ typedef enum rsa_key_format_t; -/* Elliptic Curves. */ -enum - { - CURVE_NIST_P256, - CURVE_NIST_P384, - CURVE_NIST_P521, - CURVE_SEC_P256K1, - CURVE_ED25519, - CURVE_UNKNOWN, - }; - - /* One cache item for DOs. */ struct cache_s { struct cache_s *next; @@ -241,15 +228,14 @@ struct app_local_s { rsa_key_format_t format; } rsa; struct { - int curve; + const char *oid; + int flags; } ecc; - struct { - int curve; - } eddsa; }; } keyattr[3]; }; +#define ECC_FLAG_EDDSA (1 << 0) /***** Local prototypes *****/ @@ -745,25 +731,12 @@ parse_login_data (app_t app) } -static unsigned char -get_algo_byte (int keynumber, key_type_t key_type) -{ - if (key_type == KEY_TYPE_ECC && keynumber != 1) - return PUBKEY_ALGO_ECDSA; - else if (key_type == KEY_TYPE_ECC && keynumber == 1) - return PUBKEY_ALGO_ECDH; - else if (key_type == KEY_TYPE_EDDSA) - return PUBKEY_ALGO_EDDSA; - else - return PUBKEY_ALGO_RSA; -} - #define MAX_ARGS_STORE_FPR 3 /* Note, that FPR must be at least 20 bytes. */ static gpg_error_t store_fpr (app_t app, int keynumber, u32 timestamp, unsigned char *fpr, - key_type_t key_type, ...) + int algo, ...) { unsigned int n, nbits; unsigned char *buffer, *p; @@ -776,21 +749,17 @@ store_fpr (app_t app, int keynumber, u32 timestamp, unsigned char *fpr, int i; n = 6; /* key packet version, 4-byte timestamps, and algorithm */ - if (keynumber == 1 && key_type == KEY_TYPE_ECC) + if (algo == PUBKEY_ALGO_ECDH) argc = 3; else argc = 2; - va_start (ap, key_type); + va_start (ap, algo); for (i = 0; i < argc; i++) { m[i] = va_arg (ap, const unsigned char *); mlen[i] = va_arg (ap, size_t); - if (key_type != KEY_TYPE_EDDSA) - /* strip off leading zeroes */ - for (; mlen[i] && !*m[i]; mlen[i]--, m[i]++) - ; - if (key_type == KEY_TYPE_RSA || i == 1) + if (algo == PUBKEY_ALGO_RSA || i == 1) n += 2; n += mlen[i]; } @@ -808,11 +777,11 @@ store_fpr (app_t app, int keynumber, u32 timestamp, unsigned char *fpr, *p++ = timestamp >> 16; *p++ = timestamp >> 8; *p++ = timestamp; - *p++ = get_algo_byte (keynumber, key_type); + *p++ = algo; for (i = 0; i < argc; i++) { - if (key_type == KEY_TYPE_RSA || i == 1) + if (algo == PUBKEY_ALGO_RSA || i == 1) { nbits = count_bits (m[i], mlen[i]); *p++ = nbits >> 8; @@ -924,70 +893,25 @@ send_key_data (ctrl_t ctrl, const char *name, static void -get_ecc_key_parameters (int curve, int *r_n_bits, const char **r_curve_oid) -{ - if (curve == CURVE_NIST_P256) - { - *r_n_bits = 256; - *r_curve_oid = "1.2.840.10045.3.1.7"; - } - else if (curve == CURVE_NIST_P384) - { - *r_n_bits = 384; - *r_curve_oid = "1.3.132.0.34"; - } - else if (curve == CURVE_NIST_P521) - { - *r_n_bits = 521; - *r_curve_oid = "1.3.132.0.35"; - } - else if (curve == CURVE_SEC_P256K1) - { - *r_n_bits = 256; - *r_curve_oid = "1.3.132.0.10"; - } - else if (curve == CURVE_ED25519) - { - *r_n_bits = 255; - *r_curve_oid = "1.3.6.1.4.1.11591.15.1"; - } - else - { - *r_n_bits = 0; - *r_curve_oid = "1.3.6.1.4.1.11591.2.12242973"; /* gnu.gnupg.badoid */ - } -} - -static void -send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int number) +send_key_attr (ctrl_t ctrl, app_t app, const char *keyword, int keyno) { char buffer[200]; - int n_bits; - const char *curve_oid; - assert (number >=0 && number < DIM(app->app_local->keyattr)); + assert (keyno >=0 && keyno < DIM(app->app_local->keyattr)); - if (app->app_local->keyattr[number].key_type == KEY_TYPE_RSA) - snprintf (buffer, sizeof buffer, "%d 1 %u %u %d", - number+1, - app->app_local->keyattr[number].rsa.n_bits, - app->app_local->keyattr[number].rsa.e_bits, - app->app_local->keyattr[number].rsa.format); - else if (app->app_local->keyattr[number].key_type == KEY_TYPE_ECC) - { - get_ecc_key_parameters (app->app_local->keyattr[number].ecc.curve, - &n_bits, &curve_oid); - snprintf (buffer, sizeof buffer, "%d %d %u %s", - number+1, - number==1? PUBKEY_ALGO_ECDH: PUBKEY_ALGO_ECDSA, - n_bits, curve_oid); - } - else if (app->app_local->keyattr[number].key_type == KEY_TYPE_EDDSA) + if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA) + snprintf (buffer, sizeof buffer, "%d 1 rsa%u %u %d", + keyno+1, + app->app_local->keyattr[keyno].rsa.n_bits, + app->app_local->keyattr[keyno].rsa.e_bits, + app->app_local->keyattr[keyno].rsa.format); + else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECC) { - get_ecc_key_parameters (app->app_local->keyattr[number].eddsa.curve, - &n_bits, &curve_oid); - snprintf (buffer, sizeof buffer, "%d 22 %u %s", - number+1, n_bits, curve_oid); + snprintf (buffer, sizeof buffer, "%d %d %s", + keyno+1, + app->app_local->keyattr[keyno].ecc.flags? PUBKEY_ALGO_EDDSA: + (keyno==1? PUBKEY_ALGO_ECDH: PUBKEY_ALGO_ECDSA), + openpgp_oid_to_curve (app->app_local->keyattr[keyno].ecc.oid)); } else snprintf (buffer, sizeof buffer, "0 0 UNKNOWN"); @@ -1295,24 +1219,6 @@ retrieve_key_material (FILE *fp, const char *hexkeyid, #endif /*GNUPG_MAJOR_VERSION > 1*/ -static const char * -get_curve_name (int curve) -{ - if (curve == CURVE_NIST_P256) - return "NIST P-256"; - else if (curve == CURVE_NIST_P384) - return "NIST P-384"; - else if (curve == CURVE_NIST_P521) - return "NIST P-521"; - else if (curve == CURVE_SEC_P256K1) - return "secp256k1"; - else if (curve == CURVE_ED25519) - return "Ed25519"; - else - return "unknown"; -} - - /* Get the public key for KEYNO and store it as an S-expresion with the APP handle. On error that field gets cleared. If we already know about the public key we will just return. Note that this does @@ -1480,7 +1386,9 @@ get_public_key (app_t app, int keyno) goto leave; } /* Prepend numbers with a 0 if needed. */ - if (app->app_local->keyattr[keyno].key_type != KEY_TYPE_EDDSA + if ((app->app_local->keyattr[keyno].key_type == KEY_TYPE_RSA + || (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECC + && !app->app_local->keyattr[keyno].ecc.flags)) && mlen && (*m & 0x80)) { *mbuf = 0; @@ -1526,35 +1434,12 @@ get_public_key (app_t app, int keyno) } else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_ECC) { - const char *curve_name - = get_curve_name (app->app_local->keyattr[keyno].ecc.curve); - - err = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecc(curve%s)(q%b)))", - curve_name, (int)mlen, mbuf); - if (err) - goto leave; - - len = gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, NULL, 0); - - keybuf = xtrymalloc (len); - if (!keybuf) - { - gcry_sexp_release (s_pkey); - err = gpg_error_from_syserror (); - goto leave; - } - gcry_sexp_sprint (s_pkey, GCRYSEXP_FMT_CANON, keybuf, len); - gcry_sexp_release (s_pkey); - } - else if (app->app_local->keyattr[keyno].key_type == KEY_TYPE_EDDSA) - { - const char *curve_name - = get_curve_name (app->app_local->keyattr[keyno].eddsa.curve); - err = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecc(curve%s)(flags eddsa)(q%b)))", - curve_name, (int)mlen, mbuf); + "(public-key(ecc(curve%s)%s(q%b)))", + openpgp_oid_to_curve (app->app_local->keyattr[keyno].ecc.oid), + app->app_local->keyattr[keyno].ecc.flags? + "(flags eddsa)" : "", + (int)mlen, mbuf); if (err) goto leave; @@ -3256,7 +3141,7 @@ rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), goto leave; } - err = store_fpr (app, keyno, created_at, fprbuf, KEY_TYPE_RSA, + err = store_fpr (app, keyno, created_at, fprbuf, PUBKEY_ALGO_RSA, rsa_n, rsa_n_len, rsa_e, rsa_e_len); if (err) goto leave; @@ -3280,11 +3165,10 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), const unsigned char *ecc_q = NULL; const unsigned char *ecc_d = NULL; size_t ecc_q_len, ecc_d_len; - unsigned char *template = NULL; - size_t template_len; - unsigned char fprbuf[20]; u32 created_at = 0; - int curve = CURVE_UNKNOWN; + const char *oidstr = NULL; + int flag_eddsa = 0; + int algo; /* (private-key(ecc(curve%s)(q%m)(d%m))(created-at%d)): curve = "NIST P-256" */ @@ -3306,21 +3190,30 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), if (tok && toklen == 5 && !memcmp (tok, "curve", 5)) { + unsigned char *curve; + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) goto leave; - if (tok && toklen == 10 && !memcmp (tok, "NIST P-256", 10)) - curve = CURVE_NIST_P256; - else if (tok && toklen == 9 && !memcmp (tok, "secp256k1", 9)) - curve = CURVE_SEC_P256K1; - else if (tok && toklen == 7 && !memcmp (tok, "Ed25519", 7)) - curve = CURVE_ED25519; - else + curve = xtrymalloc (toklen+1); + if (!curve) { - log_error (_("unsupported curve\n")); - err = gpg_error (GPG_ERR_INV_VALUE); + err = gpg_error_from_syserror (); goto leave; } + + memcpy (curve, tok, toklen); + curve[toklen] = 0; + oidstr = openpgp_curve_to_oid (curve, NULL); + xfree (curve); + } + else if (tok && toklen == 5 && !memcmp (tok, "flags", 5)) + { + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + + if (tok && toklen == 5 && !memcmp (tok, "eddsa", 5)) + flag_eddsa = 1; } else if (tok && toklen == 1) { @@ -3340,7 +3233,7 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), } if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) goto leave; - if (tok && buf2 && curve != CURVE_ED25519) + if (tok && buf2 && !flag_eddsa) /* It's MPI. Strip off leading zero bytes and save. */ for (;toklen && !*tok; toklen--, tok++) ; @@ -3391,12 +3284,33 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), /* Check that we have all parameters and that they match the card description. */ + if (!oidstr) + { + log_error (_("unsupported curve\n")); + err = gpg_error (GPG_ERR_INV_VALUE); + goto leave; + } if (!created_at) { log_error (_("creation timestamp missing\n")); err = gpg_error (GPG_ERR_INV_VALUE); goto leave; } + if (flag_eddsa && keyno != 1) + algo = PUBKEY_ALGO_EDDSA; + else if (keyno == 1) + algo = PUBKEY_ALGO_ECDH; + else + algo = PUBKEY_ALGO_ECDSA; + + if (app->app_local->keyattr[keyno].key_type != KEY_TYPE_ECC + || app->app_local->keyattr[keyno].ecc.oid != oidstr + || app->app_local->keyattr[keyno].ecc.flags != flag_eddsa) + { + log_error ("key attribute on card doesn't match\n"); + err = gpg_error (GPG_ERR_INV_VALUE); + goto leave; + } if (opt.verbose) log_info ("ECC private key size is %u bytes\n", (unsigned int)ecc_d_len); @@ -3411,6 +3325,8 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), { /* Build the private key template as described in section 4.3.3.7 of the OpenPGP card specs version 2.0. */ + unsigned char *template; + size_t template_len; int exmode; err = build_ecc_privkey_template (app, keyno, @@ -3422,7 +3338,10 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), /* Prepare for storing the key. */ err = verify_chv3 (app, pincb, pincb_arg); if (err) - goto leave; + { + xfree (template); + goto leave; + } /* Store the key. */ if (app->app_local->cardcap.ext_lc_le && template_len > 254) @@ -3433,32 +3352,41 @@ ecc_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), exmode = 0; err = iso7816_put_data_odd (app->slot, exmode, 0x3fff, template, template_len); + xfree (template); } else - return gpg_error (GPG_ERR_NOT_SUPPORTED); + err = gpg_error (GPG_ERR_NOT_SUPPORTED); if (err) { log_error (_("failed to store the key: %s\n"), gpg_strerror (err)); goto leave; } + else + { + gcry_mpi_t oid; + const unsigned char *oidbuf; + size_t oid_len; + unsigned char fprbuf[20]; - err = store_fpr (app, keyno, created_at, fprbuf, - curve == CURVE_ED25519 ? KEY_TYPE_EDDSA : KEY_TYPE_ECC, - curve == CURVE_ED25519 ? - "\x09\x2b\x06\x01\x04\x01\xda\x47\x0f\x01" - : curve == CURVE_NIST_P256 ? - "\x08\x2a\x86\x48\xce\x3d\x03\x01\x07" - : "\x05\x2b\x81\x04\x00\x0a", - (size_t)(curve == CURVE_ED25519 ? 10 - : curve == CURVE_NIST_P256? 9 : 6), - ecc_q, ecc_q_len, "\x03\x01\x08\x07", (size_t)4); - if (err) - goto leave; + err = openpgp_oid_from_str (oidstr, &oid); + if (err) + goto leave; + oidbuf = gcry_mpi_get_opaque (oid, &oid_len); + if (!oidbuf) + { + err = gpg_error_from_syserror (); + gcry_mpi_release (oid); + goto leave; + } + err = store_fpr (app, keyno, created_at, fprbuf, algo, + oidbuf, oid_len, ecc_q, ecc_q_len, + "\x03\x01\x08\x07", (size_t)4); + gcry_mpi_release (oid); + } leave: - xfree (template); return err; } @@ -3661,7 +3589,7 @@ do_genkey (app_t app, ctrl_t ctrl, const char *keynostr, unsigned int flags, send_status_info (ctrl, "KEY-CREATED-AT", numbuf, (size_t)strlen(numbuf), NULL, 0); - rc = store_fpr (app, keyno, (u32)created_at, fprbuf, KEY_TYPE_RSA, + rc = store_fpr (app, keyno, (u32)created_at, fprbuf, PUBKEY_ALGO_RSA, m, mlen, e, elen); if (rc) goto leave; @@ -4014,18 +3942,21 @@ do_auth (app_t app, const char *keyidstr, && indatalen > 101) /* For a 2048 bit key. */ return gpg_error (GPG_ERR_INV_VALUE); - if (app->app_local->keyattr[2].key_type == KEY_TYPE_ECC - && (indatalen == 51 || indatalen == 67 || indatalen == 83)) - { - const char *p = (const char *)indata + 19; - indata = p; - indatalen -= 19; - } - else if (app->app_local->keyattr[2].key_type == KEY_TYPE_EDDSA) + if (app->app_local->keyattr[2].key_type == KEY_TYPE_ECC) { - const char *p = (const char *)indata + 15; - indata = p; - indatalen -= 15; + if (!app->app_local->keyattr[2].ecc.flags + && (indatalen == 51 || indatalen == 67 || indatalen == 83)) + { + const char *p = (const char *)indata + 19; + indata = p; + indatalen -= 19; + } + else + { + const char *p = (const char *)indata + 15; + indata = p; + indatalen -= 15; + } } /* Check whether an OpenPGP card of any version has been requested. */ @@ -4429,25 +4360,25 @@ parse_historical (struct app_local_s *apploc, } -static int -parse_ecc_curve (const unsigned char *buffer, size_t buflen) +static const char * +ecc_oid (unsigned char *buf, size_t buflen) { - int curve; - - if (buflen == 5 && buffer[5] == 0x22) - curve = CURVE_NIST_P384; - else if (buflen == 5 && buffer[5] == 0x23) - curve = CURVE_NIST_P521; - else if (buflen == 8) - curve = CURVE_NIST_P256; - else if (buflen == 5 && buffer[5] == 0x0a) - curve = CURVE_SEC_P256K1; - else if (buflen == 9) - curve = CURVE_ED25519; - else - curve = CURVE_UNKNOWN; - - return curve; + gcry_mpi_t oid; + char *oidstr; + const char *result; + + oid = gcry_mpi_set_opaque (NULL, buf, buflen * 8); + if (!oid) + return NULL; + + oidstr = openpgp_oid_to_str (oid); + gcry_mpi_release (oid); + if (!oidstr) + return NULL; + + result = openpgp_curve_to_oid (oidstr, NULL); + xfree (oidstr); + return result; } @@ -4505,25 +4436,16 @@ parse_algorithm_attribute (app_t app, int keyno) app->app_local->keyattr[keyno].rsa.format == RSA_CRT? "crt" : app->app_local->keyattr[keyno].rsa.format == RSA_CRT_N?"crt+n":"?"); } - else if (*buffer == PUBKEY_ALGO_ECDH || *buffer == PUBKEY_ALGO_ECDSA) + else if (*buffer == PUBKEY_ALGO_ECDH || *buffer == PUBKEY_ALGO_ECDSA + || *buffer == PUBKEY_ALGO_EDDSA) { app->app_local->keyattr[keyno].key_type = KEY_TYPE_ECC; - app->app_local->keyattr[keyno].ecc.curve - = parse_ecc_curve (buffer + 1, buflen - 1); - if (opt.verbose) - log_printf - ("ECC, curve=%s\n", - get_curve_name (app->app_local->keyattr[keyno].ecc.curve)); - } - else if (*buffer == PUBKEY_ALGO_EDDSA) - { - app->app_local->keyattr[keyno].key_type = KEY_TYPE_EDDSA; - app->app_local->keyattr[keyno].eddsa.curve - = parse_ecc_curve (buffer + 1, buflen - 1); + app->app_local->keyattr[keyno].ecc.oid = ecc_oid (buffer + 1, buflen - 1); + app->app_local->keyattr[keyno].ecc.flags = (*buffer == PUBKEY_ALGO_EDDSA); if (opt.verbose) log_printf - ("EdDSA, curve=%s\n", - get_curve_name (app->app_local->keyattr[keyno].eddsa.curve)); + ("ECC, curve=%s%s\n", app->app_local->keyattr[keyno].ecc.oid, + app->app_local->keyattr[keyno].ecc.flags ? " (eddsa)": ""); } else if (opt.verbose) log_printhex ("", buffer, buflen); -- From wk at gnupg.org Thu Jul 23 12:21:52 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Jul 2015 12:21:52 +0200 Subject: local part of e-mail addresses In-Reply-To: (James Cloos's message of "Wed, 22 Jul 2015 19:37:56 -0400") References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> <20150721015035.GA23425@x2.esmtp.org> Message-ID: <877fprcgxr.fsf@vigenere.g10code.de> On Thu, 23 Jul 2015 01:37, cloos at jhcloos.com said: > This came up recently on the dane list. Even though it may not be the > case for smtp et alia, localparts are case-insensitive in openpgp. OpenPGP does not know about mail addresses. There is only a recommendation: By convention, it includes an RFC 2822 [](#RFC2822) mail name-addr, but there are no restrictions on its content. gpg does a case insensitive search by default but you may also use an exact search (=USERID) Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Jul 23 14:11:59 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 23 Jul 2015 14:11:59 +0200 Subject: scd: Format change to specify "rsa2048" for KEY-ATTR. In-Reply-To: <55B07907.2010800@fsij.org> (NIIBE Yutaka's message of "Thu, 23 Jul 2015 14:17:59 +0900") References: <55B07907.2010800@fsij.org> Message-ID: <87380fcbu8.fsf@vigenere.g10code.de> On Thu, 23 Jul 2015 07:17, gniibe at fsij.org said: > While new OpenPGPcard supports keys other than RSA, here is > a kind of clean up. I'm going to push this. Okay. > + log_error (_("unsupported algorithm: %s"), "RSA"); Thanks for using an already translated string. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From neal at walfield.org Sat Jul 25 18:16:08 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 25 Jul 2015 18:16:08 +0200 Subject: local part of e-mail addresses In-Reply-To: <87twsxhf5h.fsf@vigenere.g10code.de> References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> <20150721015035.GA23425@x2.esmtp.org> <87si8hkb2d.wl-neal@walfield.org> <87twsxhf5h.fsf@vigenere.g10code.de> Message-ID: <87d1zgnrg7.wl-neal@walfield.org> Hi, At Tue, 21 Jul 2015 14:24:42 +0200, Werner Koch wrote: > > On Tue, 21 Jul 2015 13:24, neal at walfield.org said: > > > introduces a potential for false positives. However, I think it is > > extremely rare that email addresses like neal at walfield.org and > > Neal at walfield.org are distinct. Thus, I think in this case, > > regularizing is the right approach. > > I concur. People actually tend to change capitalization of mail > addresses so that common MUA configurations ignore the case. > > GnuPG's PKA system hashes the local-part but downcases all plain ASCII > characters first. Characters with the MSB set are not touched and > hashed verbatim. The reason for that the latter is that the rules for > changing the case of characters > 127 depend on the locale and are > sometimes not correctly implemented if at all well defined. This is all > done on the UTF-8 encoding without any IDNA transformation. I'm not familiar with this problem. Here are my thoughts. We want to prevent attacks whereby an attacker creates a key that appears legitimate, but does not trigger a conflict. Concretely, if the user's email address is: alice at example.org Then: Alice at example.org should result in a conflict. Let's assume that 'A' maps to different lower case letters in different locales (say, 'a' and 'b'): 'A' -> 'a' 'A' -> 'b' Moreover, let's assume that other letters also sometimes map to 'a' (say 'B'): 'B' -> 'a' 'B' -> 'b' If we map all of these letters to one representative letter, say 'x', then 'alice' maps to 'xlice' and 'Alice' maps to 'xlice' and we correctly identify a conflict! The tradeoff is that we increase the false positive rate (i.e., we suggest there is a conflict where this is none). But, if the equivalent classes are relatively small, these should be manageable. Thoughts? Neal From neal at walfield.org Sat Jul 25 18:23:04 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sat, 25 Jul 2015 18:23:04 +0200 Subject: TOFU Design In-Reply-To: <87mvyofr3u.fsf@vigenere.g10code.de> References: <87615jkm4z.wl-neal@walfield.org> <87mvyofr3u.fsf@vigenere.g10code.de> Message-ID: <87bnf0nr4n.wl-neal@walfield.org> At Wed, 22 Jul 2015 12:01:41 +0200, Werner Koch wrote: > On Fri, 17 Jul 2015 14:24, neal at walfield.org said: > > > Finally, we'd have to regularize names. At least for latin and > > germanic languages, UTF-8 canonicalization, space compression and down > > casing should be enough. But, I'm not sure about other languages > > where letters are combined. > > Just to clarify: GnuPG only knows about UTF-8 (as per OpenPGP) and it > does not handle IDNA etc. Any mapping to the encoding required for > example by rfc822 has to be done outside of GnuPG. This is related to another email that you sent in this thread and to which I just followed up. Let's continue the discussion there. > > Note: it is unclear what to do when the OpenPGP User ID is not in RFC > > 2822 form or there is no email address. > > I suggest to ignore such a user id. > See gnupg/common/mbox-util.c:mailbox_from_userid on GnuPG parses userids. I don't see why we should implement TOFU for hostnames. This also open an opportunity for an attack. If the attacker just replaces the @ with a similar looking character, we'll ignore the key. I don't think that's a good idea. > > Verification > > ============ > > > > - If no bindings contain either the email address or the key, then > > we ask the user whether to accept the new binding. > > For TOFU alone this would be okay but TOFU is only one part of the > story. We need to limit user interaction to the bare minimum. Thus in > this case we need to lookup the key using DNS (PKA style CERT records) > by th mail address. The binding should have a "Initial-Source" field to > record that the binding has been created from > > a) PKA > b) keyserver lookup by fingerprint > c) a key send with a message > d) the verification of a signed message > e) a manually imported key with verified fingerprint (keysigning). > > This information can be useful in cae of a conflict. For example a > manually imported key should be more trustworthy than one take from a > keyserver. The exact rules need to be worked out but tracking the > source needs to be there right from the beginning. This is a good idea. > > course, for new bindings, the key is probably not yet available and if > > the user hasn't enabled auto-key-locate (which is disabled by > > default), then we can't do the verification nor can we update the > > We need to change some of the defaults - at least for email use. > Traffic patterns are anyway not protected and thus it does not sense to > avoid network access by default. For those who need it they can use > --disable-dirmngr to avoid all kind of network access or use the > proposed --enable-tor option. The goal is to increase the use of > encrypted mail and not to be safe against targeted attacks by default. Ok. > > Export > > ====== > > > > Should TOFU bindings be exportable? TOFU reveals the user's social > > No. That should be kept local like the trustdb. I think reasonable people can disagree about this. But, as Robert said, let's defer this discussion. Thanks! :) Neal From cloos at jhcloos.com Sat Jul 25 19:54:19 2015 From: cloos at jhcloos.com (James Cloos) Date: Sat, 25 Jul 2015 13:54:19 -0400 Subject: local part of e-mail addresses In-Reply-To: <877fprcgxr.fsf@vigenere.g10code.de> (Werner Koch's message of "Thu, 23 Jul 2015 12:21:52 +0200") References: <87615jkm4z.wl-neal@walfield.org> <87wpxu1p7h.fsf@latte.josefsson.org> <20150721015035.GA23425@x2.esmtp.org> <877fprcgxr.fsf@vigenere.g10code.de> Message-ID: >>>>> "WK" == Werner Koch writes: WK> gpg does a case insensitive search by default but you may also use an WK> exact search (=USERID) I did not know that gnupg could do a case sensitive search, but as I understand it that puts it in the minority. It is good to know that fact; danke. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From patrick at enigmail.net Sun Jul 26 11:31:44 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Sun, 26 Jul 2015 11:31:44 +0200 Subject: GnuPG 2.1.6: Failure with using fingerprint for expired key Message-ID: <55B4A900.2020802@enigmail.net> I just found the following error with GnuPG 2.1.6 (I didn't try older versions): If I run the following command for an expired key (example with Bernhard's old key), GnuPG will run into an endless loop and needs to be killed: > gpg2 --status-fd 2 -e -r 0xC17B4E355CF2C8022295C2FF87D6A0DDDA4A1116 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 (this will continue forever) Using the same command with the short key specification work correctly: > gpg2 --status-fd 2 -e -r 0xDA4A1116 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 [GNUPG:] KEYEXPIRED 1359650467 gpg: 0xDA4A1116: skipped: Unusable public key [GNUPG:] INV_RECP 0 0xDA4A1116 gpg: [stdin]: encryption failed: Unusable public key -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From neal at walfield.org Sun Jul 26 19:40:33 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 26 Jul 2015 19:40:33 +0200 Subject: Pinentry: secure memory In-Reply-To: <87y4ibkrrd.fsf@vigenere.g10code.de> References: <87y4kh5b9s.fsf@vigenere.g10code.de> <87k2w158ew.fsf@vigenere.g10code.de> <878ucg6hek.fsf@vigenere.g10code.de> <874mms4tzc.wl-neal@walfield.org> <87r3prqk5x.wl-neal@walfield.org> <873826fqms.fsf_-_@vigenere.g10code.de> <87381r29tj.wl-neal@walfield.org> <878uatm5j7.fsf@alice.fifthhorseman.net> <87y4ibkrrd.fsf@vigenere.g10code.de> Message-ID: <877fpmom0e.wl-neal@walfield.org> Hi, At Mon, 20 Jul 2015 13:11:50 +0200, Werner Koch wrote: > > On Mon, 6 Jul 2015 21:48, dkg at fifthhorseman.net said: > > > Is swap the only reason to use the secure memory? Defending against > > Yes, for Pinentry because there is only single confidential data object > to protect and we know the places were we may want to wipe it. For > GnuPG this is more complicated because the secure memory area is also > used to automatically wipe malloc-ed memory before a free. > > > So I'm not convinced the tradeoff for secure memory is worthwhile. If > > you're relying on graphical toolkits, you end up relying on the toolkits > > to do the right thing anyway. > > Looks to me that we have a rough consensus to do away with secure memory > in Pinentry. I've implemented and pushed this for the gtk2 widget. See commit f9db937. :) Neal From neal at walfield.org Sun Jul 26 20:07:43 2015 From: neal at walfield.org (Neal H. Walfield) Date: Sun, 26 Jul 2015 20:07:43 +0200 Subject: [PATCH] pinentry: More gseal/gtk3 compatibility in the gtk+3 UI. In-Reply-To: <87y4kmus0p.wl-neal@walfield.org> References: <1415012703-7153-1-git-send-email-dimitri.j.ledkov@intel.com> <87y4kmus0p.wl-neal@walfield.org> Message-ID: <876156okr4.wl-neal@walfield.org> At Mon, 18 May 2015 11:57:58 +0200, Neal H. Walfield wrote: > I've created an issue for this so it doesn't get completely lost: > > https://bugs.gnupg.org/gnupg/issue1990 I replaced our custom entry widget with the standard Gtk+ widget. This makes the changes to the secure entry redundant. I did apply the tooltip changes (c9c3576) and the gtk_widget_get_window changed (70a106) from your patch. Thanks. Thanks, :) Neal From ueno at gnu.org Mon Jul 27 09:19:52 2015 From: ueno at gnu.org (Daiki Ueno) Date: Mon, 27 Jul 2015 16:19:52 +0900 Subject: [PATCH gpgme] Relax ttyname_r error checks Message-ID: Hello, This patch was originally attached to: https://lists.gnupg.org/pipermail/gnupg-devel/2015-July/030090.html I am re-sending it with a slight modification. "make check" passed on both chrooted and non-chrooted environments on Fedora 22. Regards, -- Daiki Ueno -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Relax-ttyname_r-error-checks.patch Type: text/x-patch Size: 4489 bytes Desc: not available URL: From wk at gnupg.org Wed Jul 29 16:25:11 2015 From: wk at gnupg.org (Werner Koch) Date: Wed, 29 Jul 2015 16:25:11 +0200 Subject: GnuPG 2.1.6: Failure with using fingerprint for expired key In-Reply-To: <55B4A900.2020802@enigmail.net> (Patrick Brunschwig's message of "Sun, 26 Jul 2015 11:31:44 +0200") References: <55B4A900.2020802@enigmail.net> Message-ID: <87wpxj11o8.fsf@vigenere.g10code.de> On Sun, 26 Jul 2015 11:31, patrick at enigmail.net said: >> gpg2 --status-fd 2 -e -r 0xC17B4E355CF2C8022295C2FF87D6A0DDDA4A1116 > [GNUPG:] KEYEXPIRED 1359650467 > (this will continue forever) I can't replicate this. In my test it stopped but returned "Legacy Key" instead of "Unusable Key". This is fixed with 23d8609. So, this depends on the order of regular and legacy keys in the keyring. On my test the expired key was directly followed by a Legacy key. Are you using a keyring or a keybox? That can make a difference. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From patrick at enigmail.net Wed Jul 29 16:34:49 2015 From: patrick at enigmail.net (Patrick Brunschwig) Date: Wed, 29 Jul 2015 16:34:49 +0200 Subject: GnuPG 2.1.6: Failure with using fingerprint for expired key In-Reply-To: <87wpxj11o8.fsf@vigenere.g10code.de> References: <55B4A900.2020802@enigmail.net> <87wpxj11o8.fsf@vigenere.g10code.de> Message-ID: <55B8E489.6020807@enigmail.net> On 29.07.15 16:25, Werner Koch wrote: > On Sun, 26 Jul 2015 11:31, patrick at enigmail.net said: > >>> gpg2 --status-fd 2 -e -r 0xC17B4E355CF2C8022295C2FF87D6A0DDDA4A1116 >> [GNUPG:] KEYEXPIRED 1359650467 > >> (this will continue forever) > > I can't replicate this. In my test it stopped but returned "Legacy Key" > instead of "Unusable Key". This is fixed with 23d8609. > > So, this depends on the order of regular and legacy keys in the keyring. > On my test the expired key was directly followed by a Legacy key. > > Are you using a keyring or a keybox? That can make a difference. I'm using a keybox. Would it help you to get access to my pubring.kbx file? -Patrick -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Jul 30 12:35:26 2015 From: wk at gnupg.org (Werner Koch) Date: Thu, 30 Jul 2015 12:35:26 +0200 Subject: GnuPG 2.1.6: Failure with using fingerprint for expired key In-Reply-To: <55B8E489.6020807@enigmail.net> (Patrick Brunschwig's message of "Wed, 29 Jul 2015 16:34:49 +0200") References: <55B4A900.2020802@enigmail.net> <87wpxj11o8.fsf@vigenere.g10code.de> <55B8E489.6020807@enigmail.net> Message-ID: <87a8ue0w7l.fsf@vigenere.g10code.de> On Wed, 29 Jul 2015 16:34, patrick at enigmail.net said: > I'm using a keybox. Would it help you to get access to my pubring.kbx file? That would definitely be helpful. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Jul 31 12:07:51 2015 From: wk at gnupg.org (Werner Koch) Date: Fri, 31 Jul 2015 12:07:51 +0200 Subject: GnuPG 2.1.6: Failure with using fingerprint for expired key In-Reply-To: <55B8E489.6020807@enigmail.net> (Patrick Brunschwig's message of "Wed, 29 Jul 2015 16:34:49 +0200") References: <55B4A900.2020802@enigmail.net> <87wpxj11o8.fsf@vigenere.g10code.de> <55B8E489.6020807@enigmail.net> Message-ID: <871tfoy70o.fsf@vigenere.g10code.de> On Wed, 29 Jul 2015 16:34, patrick at enigmail.net said: > I'm using a keybox. Would it help you to get access to my pubring.kbx file? Thanks for the file. Actually it would have been possible to create an expired key and try to access if by fingerprint. But with your support it was just a few minutes with gdb. Pretty straight bug resulting from not flushing a cache as needed. Commit 328a6b6 fixes this. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Fri Jul 31 21:31:42 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 31 Jul 2015 15:31:42 -0400 Subject: Memory Hole protected e-mail headers Message-ID: <87egjo86ox.fsf@alice.fifthhorseman.net> Hi folks-- Several of us have been talking about how to protect e-mail headers, in the way that we currently can protect e-mail bodies. The working name for this approach is "Memory Hole". We've made quite a bit of progress over the last few weeks, and i wanted to encourage more people to get engaged with it. Work is ongoing -- we're not anywhere near "done" -- but we want more eyes to make sure things are working right. https://modernpgp.org/memoryhole/ https://github.com/ModernPGP/memoryhole/ If you're an implementor of a Mail User Agent (MUA) that handles or generates OpenPGP-signed or -encrypted messages, we want to make sure this makes sense to you. And if you're a user of any MUA (even ones that don't do OpenPGP at all), you can contribute by trying to load our example corpus into your MUA and sending us screenshots of how the messages render (or don't) for you. What we've got: * a description of how protected headers are structured, and how to interpret them * rough guidance on how to generate different forms of these messages. * a corpus of e-mails that conform or don't conform to the standard. we want people to try these (both in memoryhole-aware and non-memoryhole-aware MUAs) and make sure they look/behave as expected. If you have ideas, please send and discuss here on gnupg-devel (if it gets too noisy, we'll spin off a separate mailing list). If you have patches, you can send them here, send them to me privately, or prepare them as pull requests on github. If you have screenshots, i think they'll probably be too large for the list here: if you can post them someplace and send a link to them on the list, or send them to me privately, i can import them into our screenshot database. Happy hacking, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: