From hans at guardianproject.info Sat Feb 1 04:16:21 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 31 Jan 2014 22:16:21 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <87wqhgy4sy.fsf@vigenere.g10code.de> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> <52EAACD4.3090908@guardianproject.info> <52EAAE62.4060005@guardianproject.info> <52EB0868.1090805@guardianproject.info> <87wqhgy4sy.fsf@vigenere.g10code.de> Message-ID: <52EC6705.5010809@guardianproject.info> On 01/31/2014 02:43 AM, Werner Koch wrote: > On Fri, 31 Jan 2014 03:20, hans at guardianproject.info said: > >> libgcrypt from master to the 1.6.x branch, which does not include "Parse >> /proc/cpuinfo for ARM HW features". So its likely building with NEON > > I'll have a look at it. The adventure continues... now that the "Parse /proc/cpuinfo" patch is in LIBGCRYPT-1-6-BRANCH and I removed --disable-neon-support to rely on auto-detection, it builds for NEON and it now passes all of the libgcrypt tests on the emulator. But now gpgme tests fail: Running gpgme/run-import --verbose pubkey-1.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-import --verbose pubdemo.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-import --verbose pubkey-1.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-keylist --verbose run-keylist: file run-support.h line 133: Invalid crypto engine The complete build and test log is here: https://dev.guardianproject.info/attachments/download/1141/gpga-build-and-test-log-neon-build-with-proc-cpuinfo.txt.bz2 So without the /proc/cpuinfo patch, all the tests pass (expect fdpassing and fips random) and it also passes my manual tests on a device. Happy FOSDEM for those who are there! .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From openpgp at brainhub.org Sat Feb 1 07:09:42 2014 From: openpgp at brainhub.org (Andrey Jivsov) Date: Fri, 31 Jan 2014 22:09:42 -0800 Subject: Catch 22 in ECC support of OpenPGP? In-Reply-To: <1391154601.2806.10.camel@cfw2.gniibe.org> References: <1391140017.2806.7.camel@cfw2.gniibe.org> <52EB3FEE.9070205@brainhub.org> <1391154601.2806.10.camel@cfw2.gniibe.org> Message-ID: <52EC8FA6.90900@brainhub.org> On 01/30/2014 11:50 PM, NIIBE Yutaka wrote: > Thank you for comments. > > On 2014-01-30 at 22:17 -0800, Andrey Jivsov wrote: >> I am fine with 22. > > Good. > >> I think it's premature to think that the 23 EdDSA is ready to go along >> the side of ECDSA. I am not saying that this will never happen, but >> rather that this needs to be discussed and benefits stated. ( Would it >> work to perhaps claim some higher-numbered ID in the mean time? If it >> turns to be popular, we can "upgrade" it later to the permanent number) > > Thank you for your suggestion. It's good idea. (I had an experience > of analyzing a bug report of gnupg which was in fact kernel > incompatibility issue. It was caused by newly introduced system call > number difference [0].) > > It seems for me that OpenSSH are adopting EdDSA, so, GnuPG users will > want to use EdDSA soon through gpg-agent's feature of SSH > authentication. > >> As for compact representation, I recently updated >> http://http://tools.ietf.org/html/draft-jivsov-ecc-compact to include >> curves other than simple Weierstrass curves. I would recommend it as a >> format for OpenPGP. NIIBE, perhaps you could double-check that you are >> OK with the representation for Curve25519. > > Thank you for the reference. I didn't know you have updated it. > > Let me explain my understandings for current situation of Curve25519 > and Ed25519 in libgcrypt. > > In libgcrypt, there's no support for Curve25519 yet, but Ed25519 > (specifically for EdDSA). Ed25519 has its own compact representation > for elliptic curve point. Namely, because x can be represented in > 255-bit, we have another bit to represent the sign in 256th-bit. If this is a standard method that everybody would be using, then this will work. I think that a compact representation of a point that fits the size of the scalar (or x coordinate, the underlying field) is the ideal encoding, as opposed to an encoding with a prefix. > > When Curve25519 will be supported in GnuPG, I think that it's only for > ECDH (since people use EdDSA with Ed25519, instead of ECDSA with > Curve25519). Thus, there will be no problem with the compact > representation (even though there is no condition p mod 4 == 3). The type of compression is not so important with ECDH, because you are using only the x coordinate as a shared secret (so the y will not need to be calculated). There are more choices because of this. > > [0] Debian bug report to gnupg: http://bugs.debian.org/714107 > From gniibe at fsij.org Sat Feb 1 15:14:27 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 01 Feb 2014 23:14:27 +0900 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys In-Reply-To: <52E0F046.309@heidler.eu> References: <52E0F046.309@heidler.eu> Message-ID: <1391264067.3650.1.camel@latx1.gniibe.org> Thank you for your report also sending to me. It required some time for me to understand the context (I misunderstood as it were bug 1549). On 2014-01-23 at 11:34 +0100, Dominik Heidler wrote: > From: Dominik Heidler > > * g10/card-util.c (card_store_subkey): allow PUBKEY_USAGE_CERT > > GnuPG-bug-id: 1548 > Signed-off-by: Dominik Heidler Let me rephrase. I think that you have a primary key with C-flag only and want to import that key to smartcard. I guess that you have a subkey for signing only. Or you are considering such a use case. --- (*) I could understand this. Life cycle would be different between primary key and signing only key. I know some Debian developers who use signing only subkey. Currently, OpenPGP card specification doesn't fit the use case of (*) very well, if a person wants to import both of primary key (for signing only) and signing only subkey. It defines only a single key, which is used to both purposes. It would be good if OpenPGP card specification allows an optional signing key, so that it could support the use case of (*). Then, your patch will fully make sense. Do you claim the use case above? Or, is your patch just a theoretical? In my opinion, we need to discuss enhancement of OpenPGP card specification at first, if the use case is really common or its support is needed. -- From dominik at heidler.eu Sat Feb 1 15:23:41 2014 From: dominik at heidler.eu (Dominik Heidler) Date: Sat, 01 Feb 2014 15:23:41 +0100 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys In-Reply-To: <1391264067.3650.1.camel@latx1.gniibe.org> References: <52E0F046.309@heidler.eu> <1391264067.3650.1.camel@latx1.gniibe.org> Message-ID: <52ED036D.2060403@heidler.eu> I'm using the card as you described it: I applied the patch to my local gnupg to be able to upload my C-Only primary-key to the card. Then I created some offline backup for that key as well and deleted the primary key from my computer. I have two subkeys: One for signing and one for encryption. I can exchange them at any time without loosing my WOT as the WOT is bound to the primary key. So to make that clear: On this smartcard I have only one key: The primary C-only key. I'm running this setup now for some time and it's working quite well. Am 01.02.2014 15:14, schrieb NIIBE Yutaka: > Thank you for your report also sending to me. It required some time > for me to understand the context (I misunderstood as it were bug > 1549). > > On 2014-01-23 at 11:34 +0100, Dominik Heidler wrote: >> From: Dominik Heidler >> >> * g10/card-util.c (card_store_subkey): allow PUBKEY_USAGE_CERT >> >> GnuPG-bug-id: 1548 >> Signed-off-by: Dominik Heidler > > Let me rephrase. > > I think that you have a primary key with C-flag only and want to > import that key to smartcard. I guess that you have a subkey for > signing only. Or you are considering such a use case. --- (*) > > I could understand this. Life cycle would be different between > primary key and signing only key. I know some Debian developers who > use signing only subkey. > > Currently, OpenPGP card specification doesn't fit the use case of (*) > very well, if a person wants to import both of primary key (for > signing only) and signing only subkey. It defines only a single key, > which is used to both purposes. > > It would be good if OpenPGP card specification allows an optional > signing key, so that it could support the use case of (*). Then, > your patch will fully make sense. > > > > Do you claim the use case above? Or, is your patch just a > theoretical? > > In my opinion, we need to discuss enhancement of OpenPGP card > specification at first, if the use case is really common or its > support is needed. > From dominik at heidler.eu Sat Feb 1 15:27:13 2014 From: dominik at heidler.eu (Dominik Heidler) Date: Sat, 01 Feb 2014 15:27:13 +0100 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys In-Reply-To: <1391264067.3650.1.camel@latx1.gniibe.org> References: <52E0F046.309@heidler.eu> <1391264067.3650.1.camel@latx1.gniibe.org> Message-ID: <52ED0441.2060402@heidler.eu> Am 01.02.2014 15:14, schrieb NIIBE Yutaka: > Currently, OpenPGP card specification doesn't fit the use case of (*) > very well, if a person wants to import both of primary key (for > signing only) and signing only subkey. It defines only a single key, > which is used to both purposes. > > It would be good if OpenPGP card specification allows an optional > signing key, so that it could support the use case of (*). Then, > your patch will fully make sense. Yes - that's the only downside: I need the C-Key smartcard to sign other users keys. But I'm not signing that often, so that's ok for me. From jussi.kivilinna at iki.fi Sun Feb 2 20:31:11 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Sun, 02 Feb 2014 21:31:11 +0200 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52EC6705.5010809@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> <52EAACD4.3090908@guardianproject.info> <52EAAE62.4060005@guardianproject.info> <52EB0868.1090805@guardianproject.info> <87wqhgy4sy.fsf@vigenere.g10code.de> <52EC6705.5010809@guardianproject.info> Message-ID: <52EE9CFF.9020806@iki.fi> On 01.02.2014 05:16, Hans-Christoph Steiner wrote: > > On 01/31/2014 02:43 AM, Werner Koch wrote: >> On Fri, 31 Jan 2014 03:20, hans at guardianproject.info said: >> >>> libgcrypt from master to the 1.6.x branch, which does not include "Parse >>> /proc/cpuinfo for ARM HW features". So its likely building with NEON >> >> I'll have a look at it. > > The adventure continues... now that the "Parse /proc/cpuinfo" patch is in > LIBGCRYPT-1-6-BRANCH and I removed --disable-neon-support to rely on > auto-detection, it builds for NEON and it now passes all of the libgcrypt > tests on the emulator. But now gpgme tests fail: > > Running gpgme/run-import --verbose pubkey-1.asc > run-import: file run-support.h line 133: Invalid crypto engine > Running gpgme/run-import --verbose pubdemo.asc > run-import: file run-support.h line 133: Invalid crypto engine > Running gpgme/run-import --verbose pubkey-1.asc > run-import: file run-support.h line 133: Invalid crypto engine > Running gpgme/run-keylist --verbose > run-keylist: file run-support.h line 133: Invalid crypto engine > > The complete build and test log is here: > https://dev.guardianproject.info/attachments/download/1141/gpga-build-and-test-log-neon-build-with-proc-cpuinfo.txt.bz2 > > So without the /proc/cpuinfo patch, all the tests pass (expect fdpassing and > fips random) and it also passes my manual tests on a device. Does the attached patch help? For me, the tests succeed with 'release' CFLAGS + -mno-unaligned-access and removed --disable-neon-support when using this patch to fix 'ARMv6 or newer' detection for libgcrypt configure. -Jussi > > Happy FOSDEM for those who are there! > > .hc > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-fix-armv6-detection.patch Type: text/x-patch Size: 1969 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 730 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Feb 3 09:00:11 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 03 Feb 2014 17:00:11 +0900 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys In-Reply-To: <52ED0441.2060402@heidler.eu> References: <52E0F046.309@heidler.eu> <1391264067.3650.1.camel@latx1.gniibe.org> <52ED0441.2060402@heidler.eu> Message-ID: <1391414411.1529.3.camel@cfw2.gniibe.org> On 2014-02-01 at 15:27 +0100, Dominik Heidler wrote: > Am 01.02.2014 15:14, schrieb NIIBE Yutaka: > > Currently, OpenPGP card specification doesn't fit the use case of (*) > > very well, if a person wants to import both of primary key (for > > signing only) and signing only subkey. It defines only a single key, > > which is used to both purposes. > > > > It would be good if OpenPGP card specification allows an optional > > signing key, so that it could support the use case of (*). Then, > > your patch will fully make sense. > > Yes - that's the only downside: I need the C-Key smartcard to sign other > users keys. But I'm not signing that often, so that's ok for me. Let me explain my understanding of OpenPGP card. It does not support all features of OpenPGP, but common ones. An OpenPGP card offers three keys. One is for primary key of OpenPGP, with a capability of signing other keys (certify, C-flag) and a capability of making signatures (S-flag). Second is for subkey for decryption (E-flag), and third is for subkey for authentication (A-flag). Features are subset of what OpenPGP can do. As GnuPG's default action of --gen-key is generating a primary key with S+C and a subkey with E, I think that we can say that OpenPGP card supports most common case. The particular use case of yours would be beyond the scope of OpenPGP card specification, possibly. Even with current GnuPG, you have a workaround pretending as if your key had a capability of making signatures when you import your key to the card. * * * I rather would like to support the idea of adding signing only key to OpenPGP card (and/or its specification), as an optional feature. -- From dominik at heidler.eu Mon Feb 3 09:08:18 2014 From: dominik at heidler.eu (Dominik Heidler) Date: Mon, 03 Feb 2014 09:08:18 +0100 Subject: ***SPAM*** Re: [PATCH] gpg: enable key-to-card upload for cert-only keys In-Reply-To: <1391414411.1529.3.camel@cfw2.gniibe.org> References: <52E0F046.309@heidler.eu> <1391264067.3650.1.camel@latx1.gniibe.org> <52ED0441.2060402@heidler.eu> <1391414411.1529.3.camel@cfw2.gniibe.org> Message-ID: <5775ab6e-51e5-434a-b107-6b5eabe6a7fd@email.android.com> On 3. Februar 2014 09:00:11 MEZ, NIIBE Yutaka wrote: >On 2014-02-01 at 15:27 +0100, Dominik Heidler wrote: >> Am 01.02.2014 15:14, schrieb NIIBE Yutaka: >> > Currently, OpenPGP card specification doesn't fit the use case of >(*) >> > very well, if a person wants to import both of primary key (for >> > signing only) and signing only subkey. It defines only a single >key, >> > which is used to both purposes. >> > >> > It would be good if OpenPGP card specification allows an optional >> > signing key, so that it could support the use case of (*). Then, >> > your patch will fully make sense. >> >> Yes - that's the only downside: I need the C-Key smartcard to sign >other >> users keys. But I'm not signing that often, so that's ok for me. > >Let me explain my understanding of OpenPGP card. > >It does not support all features of OpenPGP, but common ones. > >An OpenPGP card offers three keys. One is for primary key of OpenPGP, >with a capability of signing other keys (certify, C-flag) and a >capability of making signatures (S-flag). Second is for subkey for >decryption (E-flag), and third is for subkey for authentication >(A-flag). Features are subset of what OpenPGP can do. > >As GnuPG's default action of --gen-key is generating a primary key >with S+C and a subkey with E, I think that we can say that OpenPGP >card supports most common case. > >The particular use case of yours would be beyond the scope of OpenPGP >card specification, possibly. Even with current GnuPG, you have a >workaround pretending as if your key had a capability of making >signatures when you import your key to the card. > > * * * > >I rather would like to support the idea of adding signing only key to >OpenPGP card (and/or its specification), as an optional feature. If I understand you correctly, you want to add a S-only slot to the card. That would only make sence, if the existing SC slot would then allow C-only keys. So your idea is about having the following key slots on the card: S1: C (or SC?) S2: S S3: E S4: A From wk at gnupg.org Mon Feb 3 15:17:38 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Feb 2014 15:17:38 +0100 Subject: legacy-list-mode Message-ID: <87d2j4wa9p.fsf@vigenere.g10code.de> Hi! we recently talked about how to format a key listing for ECC. I gave it a shot and here are some examples: $ g10/gpg2 --legacy-list-mode --list-key 1E42B367 pub 2048D/1E42B367 2007-12-31 [expires: 2018-12-31] uid Werner Koch uid Werner Koch uid Werner Koch sub 1024D/77F95F95 2011-11-02 sub 2048R/664D7444 2014-01-02 [expires: 2016-12-31] This is bascially how it has been done since PGP-2 $ g10/gpg2 --list-key 1E42B367 pub dsa2048/1E42B367 2007-12-31 [expires: 2018-12-31] uid Werner Koch uid Werner Koch uid Werner Koch sub dsa1024/77F95F95 2011-11-02 sub rsa2048/664D7444 2014-01-02 [expires: 2016-12-31] $ g10/gpg2 --list-key 658BF9C2 pub nistp256/658BF9C2 2013-09-23 nistp256 uid Test for GCRY_PK_ECC change sub nistp256/67F0948F 2013-09-23 nistp256 This is the new format which includes the name of the curves. The curve names are longer than what we have now. We may even see "brainpoolP256r1/12345678". Of course could use shorter names but in any case it will be longer and for unknown curves even much longer (gpg would print the OID instead of the name) The problem is that it does not anymore nicely align up in columns. We could use some padding to cover the common cases. However that would also mean to indent the uid even more. I don't think that will be a good idea. If we could agree on completly departing from the old format, a format like pub 1E42B367 2007-12-31 dsa2948 [expires: 2018-12-31] uid Werner Koch uid Werner Koch uid Werner Koch sub 77F95F95 2011-11-02 dsa1024 sub 664D7444 2014-01-02 rsa2048 [expires: 2016-12-31] might be better. Note that we sometimes print strings like "[marginal]" in front of the UID which won't fit anymore if short keyids are used. We could of course use abbreviations here: [ revoked] => [rev] [ expired] => [exp] [ unknown] => [ - ] [ undef ] => [ / ] [marginal] => [mar] [ full ] => [ful] [ultimate] => [ult] To complete the picture, here is how I changed the format used by --edit-key. First the old format: $ g10/gpg2 --legacy-list-mode --edit-key 1E42B367 pub 2048D/1E42B367 created: 2007-12-31 expires: 2018-12-31 usage: SC trust: unknown validity: unknown sub 2048R/FA8FE1F9 created: 2008-03-21 expired: 2011-12-30 usage: E sub 1024D/77F95F95 created: 2011-11-02 expires: never usage: S sub 2048R/C193565B created: 2011-11-07 expired: 2013-12-31 usage: E sub 2048R/664D7444 created: 2014-01-02 expires: 2016-12-31 usage: E [ unknown] (1). Werner Koch [ unknown] (2) Werner Koch [ unknown] (3) Werner Koch And here is the new one. $ g10/gpg2 --edit-key 1E42B367 pub dsa2048/1E42B367 created: 2007-12-31 expires: 2018-12-31 usage: SC trust: unknown validity: unknown sub rsa2048/FA8FE1F9 created: 2008-03-21 expired: 2011-12-30 usage: E sub dsa1024/77F95F95 created: 2011-11-02 expires: never usage: S sub rsa2048/C193565B created: 2011-11-07 expired: 2013-12-31 usage: E sub rsa2048/664D7444 created: 2014-01-02 expires: 2016-12-31 usage: E [ unknown] (1). Werner Koch [ unknown] (2) Werner Koch [ unknown] (3) Werner Koch I am not really satisfied. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From chris.gilg at link-comm.com Mon Feb 3 19:02:53 2014 From: chris.gilg at link-comm.com (Chris) Date: Mon, 3 Feb 2014 18:02:53 +0000 (UTC) Subject: gpgme Message-ID: How does GPGME handle "--ignore-time-conflict" ? Is there something in gpgme that would allow me to use this option? From wk at gnupg.org Mon Feb 3 21:36:49 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 03 Feb 2014 21:36:49 +0100 Subject: gpgme In-Reply-To: (Chris's message of "Mon, 3 Feb 2014 18:02:53 +0000 (UTC)") References: Message-ID: <87sis0ue5a.fsf@vigenere.g10code.de> On Mon, 3 Feb 2014 19:02, chris.gilg at link-comm.com said: > How does GPGME handle "--ignore-time-conflict" ? Is there > something in gpgme that would allow me to use this option? No. In general this is not required. If you have this problem you better simply add this option to gpg.conf. If you still want to check whether someone send OpenPGP data with an too old timestamp; you may check the time yourself. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Tue Feb 4 02:54:06 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 04 Feb 2014 10:54:06 +0900 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys In-Reply-To: <5775ab6e-51e5-434a-b107-6b5eabe6a7fd@email.android.com> References: <52E0F046.309@heidler.eu> <1391264067.3650.1.camel@latx1.gniibe.org> <52ED0441.2060402@heidler.eu> <1391414411.1529.3.camel@cfw2.gniibe.org> <5775ab6e-51e5-434a-b107-6b5eabe6a7fd@email.android.com> Message-ID: <1391478846.1756.1.camel@cfw2.gniibe.org> On 2014-02-03 at 09:08 +0100, Dominik Heidler wrote: > If I understand you correctly, you want to add a S-only slot to the > card. Yes. More specifically, I am considering to extend the _specification_, so that a card (in future) can optionally has S-only slot. > That would only make sence, if the existing SC slot would then allow > C-only keys. My point is that C-only slot will make sense more coherently, when we modify (or clarify) the specification of OpenPGP card. > So your idea is about having the following key slots on the card: > S1: C (or SC?) > S2: S > S3: E > S4: A Fundamental difference is that, a key (or a subkey) in OpenPGP has flags, while a key in _OpenPGP card_ has predefined capability for a slot. Thus, OpenPGP card cannot cover all possible usages of OpenPGP key, but some parts of them. For example, a OpenPGP key with flag C+S+E+A can't map to a single key of OpenPGP card. (For such a key, GnuPG requires user's decision to which slot and which usage, when user asks importing.) Currently, the specification of OpenPGP card is defined as: S1: S2: S3: And, while a key in a slot with and are more or less as similar as a key E and A in OpenPGP, is somewhat ambiguous or there is a room of different interpretations. I think that is interpreted as S+C in OpenPGP (which is common for a primary key). But I know people who put their S-only subkey to slot. And you want to put your C-only primary key to slot. My idea is something like: S1: For OpenPGP primary key (Certification, and Signature possibly) S2: Encryption (for OpenPGP subkey with E-only) S3: Authentication (for OpenPGP subkey with A-only) Optional S4: Signature (for OpenPGP subkey with S-only, or others) I think that this covers all existing usages (including yours) and my own usage in future. Well, it would be me who go too far. Let's consider a specification or an interpretation with no optional S4 slot. It's most likely to me: (A) S1: For OpenPGP primary key (Certification plus Signature) S2: Encryption (for OpenPGP subkey with E-only) S3: Authentication (for OpenPGP subkey with A-only) With this, it is a kind of abuse for a user to import S-only subkey to S1 (although it works with current implementation of GnuPG). It is correct for GnuPG not to support importing C-only key for S1 slot. It would be: (B) S1: For OpenPGP primary key (Certification, and Signature possibly) S2: Encryption (for OpenPGP subkey with E-only) S3: Authentication (for OpenPGP subkey with A-only) With this, C-only key should be supported for S1. Or: (C) S1: For any OpenPGP key/subkey (Certification, or Signature, others) S2: Encryption (for OpenPGP subkey with E-only) S3: Authentication (for OpenPGP subkey with A-only) With this, C-only key should be supported for S1, too. If (A) is the case for current specification, modifying the implementation based on (B)/(C) is wrong. -- From dominik at heidler.eu Tue Feb 4 08:33:33 2014 From: dominik at heidler.eu (Dominik Heidler) Date: Tue, 04 Feb 2014 08:33:33 +0100 Subject: [PATCH] gpg: enable key-to-card upload for cert-only keys In-Reply-To: <1391478846.1756.1.camel@cfw2.gniibe.org> References: <52E0F046.309@heidler.eu> <1391264067.3650.1.camel@latx1.gniibe.org> <52ED0441.2060402@heidler.eu> <1391414411.1529.3.camel@cfw2.gniibe.org> <5775ab6e-51e5-434a-b107-6b5eabe6a7fd@email.android.com> <1391478846.1756.1.camel@cfw2.gniibe.org> Message-ID: <10c79557-f996-4577-87ed-5a70d41f1b4a@email.android.com> Would changing the specification require a new gnupg-card with updated card-os? How difficult is it to perform such a change? On 4. Februar 2014 02:54:06 MEZ, NIIBE Yutaka wrote: >On 2014-02-03 at 09:08 +0100, Dominik Heidler wrote: >> If I understand you correctly, you want to add a S-only slot to the >> card. > >Yes. More specifically, I am considering to extend the >_specification_, so that a card (in future) can optionally has S-only >slot. > >> That would only make sence, if the existing SC slot would then allow >> C-only keys. > >My point is that C-only slot will make sense more coherently, when >we modify (or clarify) the specification of OpenPGP card. > >> So your idea is about having the following key slots on the card: >> S1: C (or SC?) >> S2: S >> S3: E >> S4: A > >Fundamental difference is that, a key (or a subkey) in OpenPGP has >flags, while a key in _OpenPGP card_ has predefined capability for a >slot. Thus, OpenPGP card cannot cover all possible usages of OpenPGP >key, but some parts of them. For example, a OpenPGP key with flag >C+S+E+A can't map to a single key of OpenPGP card. (For such a key, >GnuPG requires user's decision to which slot and which usage, when >user asks importing.) > >Currently, the specification of OpenPGP card is defined as: > > S1: > S2: > S3: > >And, while a key in a slot with and are more or less as >similar as a key E and A in OpenPGP, is somewhat ambiguous or >there is a room of different interpretations. I think that is >interpreted as S+C in OpenPGP (which is common for a primary key). >But I know people who put their S-only subkey to slot. And you >want to put your C-only primary key to slot. > >My idea is something like: > > S1: For OpenPGP primary key (Certification, and Signature possibly) > S2: Encryption (for OpenPGP subkey with E-only) > S3: Authentication (for OpenPGP subkey with A-only) > Optional S4: Signature (for OpenPGP subkey with S-only, or others) > >I think that this covers all existing usages (including yours) and my >own usage in future. > >Well, it would be me who go too far. > >Let's consider a specification or an interpretation with no optional >S4 slot. > >It's most likely to me: > > (A) > S1: For OpenPGP primary key (Certification plus Signature) > S2: Encryption (for OpenPGP subkey with E-only) > S3: Authentication (for OpenPGP subkey with A-only) > >With this, it is a kind of abuse for a user to import S-only subkey to >S1 (although it works with current implementation of GnuPG). It is >correct for GnuPG not to support importing C-only key for S1 slot. > >It would be: > > (B) > S1: For OpenPGP primary key (Certification, and Signature possibly) > S2: Encryption (for OpenPGP subkey with E-only) > S3: Authentication (for OpenPGP subkey with A-only) > >With this, C-only key should be supported for S1. > > >Or: > > (C) > S1: For any OpenPGP key/subkey (Certification, or Signature, others) > S2: Encryption (for OpenPGP subkey with E-only) > S3: Authentication (for OpenPGP subkey with A-only) > >With this, C-only key should be supported for S1, too. > > >If (A) is the case for current specification, modifying the >implementation based on (B)/(C) is wrong. From info at mailvelope.com Tue Feb 4 12:53:40 2014 From: info at mailvelope.com (=?ISO-8859-1?Q?Thomas_Obernd=F6rfer?=) Date: Tue, 4 Feb 2014 12:53:40 +0100 Subject: Subkey revocation signature Message-ID: Hello, I'm trying to verify subkey revocation signatures created with GPG. RFC4880 says: "Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked" http://tools.ietf.org/html/rfc4880#section-5.2.4 But when I compute the hash data only with the subkey packet the verification fails. I then tried to hash primary and subkey packet together and the verification succeeded. So it looks like GPG is calculating subkey revocation signature (type 0x28) in the same way as the binding signature (type 0x18). Is this correct? And if yes is this not a deviation from RFC4880? I'm currently implementing this verification in OpenPGP.js and not sure how to handle this case. Thanks, Thomas From dkg at fifthhorseman.net Tue Feb 4 16:28:34 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 04 Feb 2014 10:28:34 -0500 Subject: Subkey revocation signature In-Reply-To: References: Message-ID: <52F10722.6080201@fifthhorseman.net> On 02/04/2014 06:53 AM, Thomas Obernd?rfer wrote: > I'm trying to verify subkey revocation signatures created with GPG. > > RFC4880 says: > "Key revocation signatures (types 0x20 and 0x28) hash only the key > being revoked" > http://tools.ietf.org/html/rfc4880#section-5.2.4 > > But when I compute the hash data only with the subkey packet the > verification fails. > > I then tried to hash primary and subkey packet together and the > verification succeeded. > > So it looks like GPG is calculating subkey revocation signature > (type 0x28) in the same way as the binding signature (type 0x18). > > Is this correct? And if yes is this not a deviation from RFC4880? > I'm currently implementing this verification in OpenPGP.js and > not sure how to handle this case. This is an error in the RFC, which i reported here: http://www.rfc-editor.org/errata_search.php?rfc=4880&eid=3298 Please see the discussion on openpgp at ietf.org starting here: https://www.ietf.org/mail-archive/web/openpgp/current/msg07067.html Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From info at mailvelope.com Tue Feb 4 17:21:03 2014 From: info at mailvelope.com (=?ISO-8859-1?Q?Thomas_Obernd=F6rfer?=) Date: Tue, 4 Feb 2014 17:21:03 +0100 Subject: Subkey revocation signature In-Reply-To: <65E46A6F-CFFF-402B-B48B-84973B72C1A5@jabberwocky.com> References: <65E46A6F-CFFF-402B-B48B-84973B72C1A5@jabberwocky.com> Message-ID: Ok, that explains it. Thanks for pointing to errata and discussion. Thomas On Tue, Feb 4, 2014 at 4:32 PM, David Shaw wrote: > On Feb 4, 2014, at 6:53 AM, Thomas Obernd?rfer wrote: > >> Hello, >> >> I'm trying to verify subkey revocation signatures created with GPG. >> >> RFC4880 says: >> "Key revocation signatures (types 0x20 and 0x28) hash only the key >> being revoked" >> http://tools.ietf.org/html/rfc4880#section-5.2.4 >> >> But when I compute the hash data only with the subkey packet the >> verification fails. >> >> I then tried to hash primary and subkey packet together and the >> verification succeeded. >> >> So it looks like GPG is calculating subkey revocation signature >> (type 0x28) in the same way as the binding signature (type 0x18). >> >> Is this correct? And if yes is this not a deviation from RFC4880? >> I'm currently implementing this verification in OpenPGP.js and >> not sure how to handle this case. > > This is correct - a subkey revocation hashes both the primary and subkeys, similar to a binding signature. The language in 4880 was in error, and an errata was filed for it: http://www.rfc-editor.org/errata_search.php?rfc=4880&eid=3298 > > David > From dshaw at jabberwocky.com Tue Feb 4 16:32:39 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 4 Feb 2014 10:32:39 -0500 Subject: Subkey revocation signature In-Reply-To: References: Message-ID: <65E46A6F-CFFF-402B-B48B-84973B72C1A5@jabberwocky.com> On Feb 4, 2014, at 6:53 AM, Thomas Obernd?rfer wrote: > Hello, > > I'm trying to verify subkey revocation signatures created with GPG. > > RFC4880 says: > "Key revocation signatures (types 0x20 and 0x28) hash only the key > being revoked" > http://tools.ietf.org/html/rfc4880#section-5.2.4 > > But when I compute the hash data only with the subkey packet the > verification fails. > > I then tried to hash primary and subkey packet together and the > verification succeeded. > > So it looks like GPG is calculating subkey revocation signature > (type 0x28) in the same way as the binding signature (type 0x18). > > Is this correct? And if yes is this not a deviation from RFC4880? > I'm currently implementing this verification in OpenPGP.js and > not sure how to handle this case. This is correct - a subkey revocation hashes both the primary and subkeys, similar to a binding signature. The language in 4880 was in error, and an errata was filed for it: http://www.rfc-editor.org/errata_search.php?rfc=4880&eid=3298 David From abc3def at gmail.com Tue Feb 4 23:57:42 2014 From: abc3def at gmail.com (alex) Date: Wed, 5 Feb 2014 02:57:42 +0400 Subject: Cleartext signing with CR character. Message-ID: Hello. I am trying to generate a cleartext signed message using BouncyCastle. And I validate results using GnuPGP. I have a problem with CR (\r) characters. The data on input "A\rB" I write such text into cleartext section "-----BEGIN PGP SIGNED MESSAGE-----\r\n" "Hash: SHA1\r\n" "A\rB\r\n" "-----BEGIN PGP SIGNATURE-----\r\n" Then I compute signature from string "A\rB" and write the remaining of the "PGP SIGNATURE" section... Then I try to validate result message using "gpg2 --verify 01.asc" but I get this error: "BAD signature" The main question that I have is: "If I ask GnuPGP to sign/verify "A\rB" text, what bytes will it send to signature generator?" I have found a function copy_clearsig_text in gnupg-2.0.20\g10\textfilter.c that seems to be computing signature for cleartext signed messages. And, if I've understood code correctly, there is no difference for GnuPGP between \r or \t or just white space ' '. But when I create myself a message from "A B", and then validate using "gpg2" it succeeds saying "Good signature". There is a number of tests I've done so far like this: assert("Hola\r\n", "Hola"); The first argument is a text as I want it to be written into cleatext section (notice, that I explicitly specify last CRLF before "BEGIN PGP SIGNATURE"). The second argument specifies the the data *as is* to compute signature from them. I.e. there is no normalization done for this argument. I exactly specify what to be used for signature generation. The "assert" function takes that arguments, generates cleartext signed message (with help of the BouncyCastle), and then asks "gpg2" to verify signature. Here are my results: assert("A\r\n", "A"); // OK assert("A\nB\r\n", "A\r\nB"); // OK assert("A\r\r\r\r\n", "A"); // OK assert("A\r\r\r\nB\r\n", "A\r\nB"); // OK assertClearSign(null, "A\tB\r\n", "A\tB"); // OK assert("A\rB\r\n", "A\rB"); // BAD assert("A\rB\r\n", "A\r\nB"); // BAD assert("A\rB\r\n", "A\nB"); // BAD assert("A\rB\r\n", "AB"); // BAD assert("A\rB\r\n", "A B"); // BAD So I've done a bunch of test trying to figure out how to compute signature from "A\rB" but no luck... Can you explain, how does GnuPGP works with "\r" chars in text. BTW, my version is: gpg (GnuPG) 2.0.20 (Gpg4win 2.1.1) libgcrypt 1.5.2 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: C:/Users/Sasha/AppData/Roaming/gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 - Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From dshaw at jabberwocky.com Wed Feb 5 07:02:34 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Wed, 5 Feb 2014 01:02:34 -0500 Subject: Cleartext signing with CR character. In-Reply-To: References: Message-ID: <50CE0045-D5F6-4FFA-9F73-BF3A2331D4A2@jabberwocky.com> On Feb 4, 2014, at 5:57 PM, alex wrote: > Hello. > > I am trying to generate a cleartext signed message using BouncyCastle. And I validate results using GnuPGP. I have a problem with CR (\r) characters. > > The data on input > "A\rB" > > I write such text into cleartext section > "-----BEGIN PGP SIGNED MESSAGE-----\r\n" > "Hash: SHA1\r\n" > "A\rB\r\n" > "-----BEGIN PGP SIGNATURE-----\r\n" > > Then I compute signature from string > "A\rB" > > and write the remaining of the "PGP SIGNATURE" section... > > Then I try to validate result message using > "gpg2 --verify 01.asc" > > but I get this error: > "BAD signature" > > > The main question that I have is: "If I ask GnuPGP to sign/verify "A\rB" text, what bytes will it send to signature generator?" Have you tried "A\r\nB" ? This is the standard canonicalization of text in OpenPGP where line endings are converted to CRLF. Signatures for clearsigned documents are sigclass 0x01, so are canonicalized. David From abc3def at gmail.com Wed Feb 5 18:57:20 2014 From: abc3def at gmail.com (alex) Date: Wed, 5 Feb 2014 21:57:20 +0400 Subject: Cleartext signing with CR character. In-Reply-To: <50CE0045-D5F6-4FFA-9F73-BF3A2331D4A2@jabberwocky.com> References: <50CE0045-D5F6-4FFA-9F73-BF3A2331D4A2@jabberwocky.com> Message-ID: This is what I get: assert("A\r\nB\r\n", "A\r\nB"); // OK assert("A\nB\r\n", "A\r\nB"); // OK assert("A\n\nB\r\n", "A\r\n\r\nB"); // OK But: assert("A\rB\r\n", "A\r\nB"); // BAD assert("A\rB\r\n", "A\rB"); // BAD RFC4880 tells: "The signature is calculated over the text with its line endings converted to ." But they do not clarify what is the "line endings". I would consider any of CR, LF, CRLF as the line ending, but when I read the GnuPGP sources, it looks like they consider LF as the line ending, e.g. iobuf.c, function iobuf_read_line The next thing I read in RFC4880: "Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at the end of any line is removed when the cleartext signature is generated." In implementation I see (textfilter.c, copy_clearsig_text): len_without_trailing_chars (buffer, n, pgp2mode? " \r\n":" \t\r\n")); So how it works... Consider I have such text: "A\r\r\r\nB". - The code will search for '\n' to identify the end of the line. As result on first iteration we'll get "A\r\r\r\n" in buffer. - Then the "len_without_trailing_chars" computed - chars \r and \n will be considered as trailing, so the length will be 1. - Copy 1 byte from buffer to message digest, i.e. copy "A". - On second iteration they copy "\r\n" into the digest (normalized line separator). - The buffer will be filled with "B", no trailing chars, so the bytes copied to message digest "B" as well. We end up with "A\r\nB" used to compute signature... And this is confirmed by my test: assert("A\r\r\r\nB\r\n", "A\r\nB"); // OK I write first argument as "cleartext" part, compute signature (wihtout any normalization) from "A\r\nB", and ask gpg2 to validate the result message - and it tells "Good signature". Now let me analyze what will happen with "A\rB" text.. - The first iteration will be looking for the \n (or end of text). There is no LF in my text, so the buffer will have "A\rB". - Then we try to remove trailing chars, but there are no trailing chars, so the whole string is copied to digest calculator. We end up with signature computed from "A\rB". But my test fails: assert("A\rB\r\n", "A\rB"); // BAD So I wonder, if someone (who can build GnuPGP from sources) can add some diagnostic code, and tell me, why gpg2 fails to validate such messages. It looks like when it see "A\rB" it computes signature NOT from "A\rB". 2014-02-05 David Shaw : > > This is the standard canonicalization of text in OpenPGP where line > endings are converted to CRLF. Signatures for clearsigned documents are > sigclass 0x01, so are canonicalized. > > David > > - Alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.gilg at link-comm.com Fri Feb 7 20:12:23 2014 From: chris.gilg at link-comm.com (Chris) Date: Fri, 7 Feb 2014 19:12:23 +0000 (UTC) Subject: gpgme and libassuan problem. Message-ID: I'm attempting to build this on Blackfin, and I'm running into a few issues. I've successfully built the required libraries. My application should link against the correct libraries with the below command. -L../../../../staging/usr/lib -lgpg-error -lassuan -lgpgme My problem is I get this at link time: ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_new_ext' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_release' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_socket_connect' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_read_line' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_write_line' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_send_data' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_sendfd' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_get_active_fds' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_pending_line' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_ctx_set_system_hooks' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `___assuan_socketpair' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `___assuan_usleep' ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_transact I was unable to find anything about gpgme complaining that it couldn't find undefined references to something that should exist in libassuan. Any help would be greatly appreciated. Thanks. From Q-Q at Safe-mail.net Sun Feb 9 01:49:34 2014 From: Q-Q at Safe-mail.net (Q Q) Date: Sat, 8 Feb 2014 19:49:34 -0500 Subject: hi Message-ID: Hi how can i get crypto stick and how much its cost. From sochotnicky at redhat.com Fri Feb 14 12:58:38 2014 From: sochotnicky at redhat.com (Stanislav Ochotnicky) Date: Fri, 14 Feb 2014 12:58:38 +0100 Subject: [PATCH] Check if we are on tty before initializing curses Message-ID: <1392379118-12353-1-git-send-email-sochotnicky@redhat.com> When we did not have a ttyname we just used stdin/out without checking if it's a proper TTY or a pipe. In some cases this can cause endless loop or escape seqeunces on the terminal. This commit changes behaviour so that if stdin/out is not tty and no ttyname is specified we error-out with errno set to ENOTTY * pinentry/pinentry-curses.c --- pinentry/pinentry-curses.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/pinentry/pinentry-curses.c b/pinentry/pinentry-curses.c index 58da255..4fc8bc4 100644 --- a/pinentry/pinentry-curses.c +++ b/pinentry/pinentry-curses.c @@ -752,6 +752,11 @@ dialog_run (pinentry_t pinentry, const char *tty_name, const char *tty_type) { if (!init_screen) { + if (!(isatty(fileno(stdin)) && isatty(fileno(stdout)))) + { + errno = ENOTTY; + return -1; + } init_screen = 1; initscr (); } -- 1.8.3.2 From hans at guardianproject.info Thu Feb 20 01:38:15 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 19 Feb 2014 19:38:15 -0500 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <52EE9CFF.9020806@iki.fi> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> <52EAACD4.3090908@guardianproject.info> <52EAAE62.4060005@guardianproject.info> <52EB0868.1090805@guardianproject.info> <87wqhgy4sy.fsf@vigenere.g10code.de> <52EC6705.5010809@guardianproject.info> <52EE9CFF.9020806@iki.fi> Message-ID: <53054E77.8060608@guardianproject.info> On 02/02/2014 02:31 PM, Jussi Kivilinna wrote: > On 01.02.2014 05:16, Hans-Christoph Steiner wrote: >> >> On 01/31/2014 02:43 AM, Werner Koch wrote: >>> On Fri, 31 Jan 2014 03:20, hans at guardianproject.info said: >>> >>>> libgcrypt from master to the 1.6.x branch, which does not include "Parse >>>> /proc/cpuinfo for ARM HW features". So its likely building with NEON >>> >>> I'll have a look at it. >> >> The adventure continues... now that the "Parse /proc/cpuinfo" patch is in >> LIBGCRYPT-1-6-BRANCH and I removed --disable-neon-support to rely on >> auto-detection, it builds for NEON and it now passes all of the libgcrypt >> tests on the emulator. But now gpgme tests fail: >> >> Running gpgme/run-import --verbose pubkey-1.asc >> run-import: file run-support.h line 133: Invalid crypto engine >> Running gpgme/run-import --verbose pubdemo.asc >> run-import: file run-support.h line 133: Invalid crypto engine >> Running gpgme/run-import --verbose pubkey-1.asc >> run-import: file run-support.h line 133: Invalid crypto engine >> Running gpgme/run-keylist --verbose >> run-keylist: file run-support.h line 133: Invalid crypto engine >> >> The complete build and test log is here: >> https://dev.guardianproject.info/attachments/download/1141/gpga-build-and-test-log-neon-build-with-proc-cpuinfo.txt.bz2 >> >> So without the /proc/cpuinfo patch, all the tests pass (expect fdpassing and >> fips random) and it also passes my manual tests on a device. > > Does the attached patch help? > > For me, the tests succeed with 'release' CFLAGS + -mno-unaligned-access and removed --disable-neon-support when using this patch to fix 'ARMv6 or newer' detection for libgcrypt configure. Hey Jussi, Your patch fixed the issue for me, but I don't see any new commits in libgcrypt 1.6 branch related to this. Are there any open questions I can help with? .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 969 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Thu Feb 20 02:57:15 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 19 Feb 2014 20:57:15 -0500 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android Message-ID: <530560FB.60303@guardianproject.info> "Locate engine names only at runtime and prefer GnuPG-2" 02ba35c1b6a2cbb3361b2f2ad507c53564b2be0b breaks gpgme for Android: Running gpgme/run-import --verbose pubkey-1.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-import --verbose pubdemo.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-import --verbose pubkey-1.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-keylist --verbose run-keylist: file run-support.h line 133: Invalid crypto engine Running gpgme/run-import --verbose seckey-1.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-import --verbose secdemo.asc run-import: file run-support.h line 133: Invalid crypto engine Running gpgme/run-keylist --verbose run-keylist: file run-support.h line 133: Invalid crypto engine Using env vars is not a feasible solution on Android. The hard-coded option that existed worked well. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Thu Feb 20 13:44:40 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Feb 2014 13:44:40 +0100 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <530560FB.60303@guardianproject.info> (Hans-Christoph Steiner's message of "Wed, 19 Feb 2014 20:57:15 -0500") References: <530560FB.60303@guardianproject.info> Message-ID: <87iosa2bt3.fsf@vigenere.g10code.de> On Thu, 20 Feb 2014 02:57, hans at guardianproject.info said: > Using env vars is not a feasible solution on Android. The hard-coded option > that existed worked well. The envvar is just PATH if it is missing the standard directories are searched: orig_path = getenv ("PATH"); if (!orig_path) orig_path = "/bin:/usr/bin:."; Do we need to add other directories as default for Android? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Thu Feb 20 15:40:01 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Feb 2014 09:40:01 -0500 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <87iosa2bt3.fsf@vigenere.g10code.de> References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> Message-ID: <530613C1.7070605@fifthhorseman.net> On 02/20/2014 07:44 AM, Werner Koch wrote: > On Thu, 20 Feb 2014 02:57, hans at guardianproject.info said: > >> Using env vars is not a feasible solution on Android. The hard-coded option >> that existed worked well. > > The envvar is just PATH if it is missing the standard directories are > searched: > > orig_path = getenv ("PATH"); > if (!orig_path) > orig_path = "/bin:/usr/bin:."; is including the current directory (.) in this path a good idea? This implies that in the absence of $PATH, the behavior of gpgme will be different depending on the directory from which it is invoked. I could imagine this causing problems or opening vulnerabilities when gpgme is used (for example) to process user-supplied files from a given directory. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From hans at guardianproject.info Thu Feb 20 16:30:47 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 20 Feb 2014 10:30:47 -0500 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <87iosa2bt3.fsf@vigenere.g10code.de> References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> Message-ID: <53061FA7.8020002@guardianproject.info> On 02/20/2014 07:44 AM, Werner Koch wrote: > On Thu, 20 Feb 2014 02:57, hans at guardianproject.info said: > >> Using env vars is not a feasible solution on Android. The hard-coded option >> that existed worked well. > > The envvar is just PATH if it is missing the standard directories are > searched: > > orig_path = getenv ("PATH"); > if (!orig_path) > orig_path = "/bin:/usr/bin:."; > > Do we need to add other directories as default for Android? In this situation, PATH won't do anything useful by default on Android. Android is not UNIX, apps do not install things into the PATH. Also, apps are not supposed to change env vars, that's inherited from Java, which only has getenv(), no setenv(). A hard-coded path to each thing that gpgme calls is the best approach that I can think of for Android. While technically possible to change the PATH, we have wasted sooooo many hours with kludges like that. Its not the right approach for Android. I've been thinking about all of the massive difficulties we have had porting GnuPG to Android. I think really the best approach on Android/Java would be to either implement gpgme in Java, or even better, implement a library that talks directly to gpg-agent via assuan like the gpg command line do. There are far too many layers in the current approach. It not only makes the Java/Android API stilted and weird, but makes things very difficult to debug. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Thu Feb 20 17:12:15 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Feb 2014 17:12:15 +0100 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <530613C1.7070605@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Thu, 20 Feb 2014 09:40:01 -0500") References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> <530613C1.7070605@fifthhorseman.net> Message-ID: <87txbt2274.fsf@vigenere.g10code.de> On Thu, 20 Feb 2014 15:40, dkg at fifthhorseman.net said: > is including the current directory (.) in this path a good idea? This > implies that in the absence of $PATH, the behavior of gpgme will be > different depending on the directory from which it is invoked. Actually I thought about this but finally decided that the default Unix behaviour is the best thing one can do in this case. > I could imagine this causing problems or opening vulnerabilities when > gpgme is used (for example) to process user-supplied files from a given > directory. It is not different than using gpg directly. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Feb 20 17:18:50 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Feb 2014 17:18:50 +0100 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <53061FA7.8020002@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 20 Feb 2014 10:30:47 -0500") References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> <53061FA7.8020002@guardianproject.info> Message-ID: <87ppmh21w5.fsf@vigenere.g10code.de> On Thu, 20 Feb 2014 16:30, hans at guardianproject.info said: > In this situation, PATH won't do anything useful by default on Android. > Android is not UNIX, apps do not install things into the PATH. Also, apps are You mean gpgconf is not installed in a directory listed by PATH? Well, then why not hard code the directory for Android? > not supposed to change env vars, that's inherited from Java, which only has > getenv(), no setenv(). > A hard-coded path to each thing that gpgme calls is the best approach that I > can think of for Android. While technically possible to change the PATH, we Okay - which path? Build time configuration or runtime configuration? A fixed directory for Android seems to be the best appraoch > have wasted sooooo many hours with kludges like that. Its not the right > approach for Android. PATH is a standard Unix and Windows feature to locate executables. > to either implement gpgme in Java, or even better, implement a library that > talks directly to gpg-agent via assuan like the gpg command line do. There Actually gpgme is such a library. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Feb 20 17:43:39 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 20 Feb 2014 11:43:39 -0500 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <87ppmh21w5.fsf@vigenere.g10code.de> References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> <53061FA7.8020002@guardianproject.info> <87ppmh21w5.fsf@vigenere.g10code.de> Message-ID: <530630BB.2030508@guardianproject.info> On 02/20/2014 11:18 AM, Werner Koch wrote: > On Thu, 20 Feb 2014 16:30, hans at guardianproject.info said: > >> In this situation, PATH won't do anything useful by default on Android. >> Android is not UNIX, apps do not install things into the PATH. Also, apps are > > You mean gpgconf is not installed in a directory listed by PATH? Well, > then why not hard code the directory for Android? > >> not supposed to change env vars, that's inherited from Java, which only has >> getenv(), no setenv(). > >> A hard-coded path to each thing that gpgme calls is the best approach that I >> can think of for Android. While technically possible to change the PATH, we > > Okay - which path? Build time configuration or runtime configuration? > A fixed directory for Android seems to be the best appraoch Yes, a build time config is perfect. >> have wasted sooooo many hours with kludges like that. Its not the right >> approach for Android. > > PATH is a standard Unix and Windows feature to locate executables. That much I know... :) >> to either implement gpgme in Java, or even better, implement a library that >> talks directly to gpg-agent via assuan like the gpg command line do. There > > Actually gpgme is such a library. I understand that gpgme is a wrapper. The issue is having an Android wrapper of a Java wrapper of a gpgme wrapper of gpg-agent is very hard to work with. Having an Android wrapper of a Java wrapper would be a lot especially if sometimes the Android native code can skip the Java wrapper and speak directly to gpg-agent. So I would like to discuss what needs to happen in GnuPG itself to enable us to write such a thing. This architecture would also work in other situation, for example a python wrapper of gpg-agent. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From jussi.kivilinna at iki.fi Thu Feb 20 18:12:36 2014 From: jussi.kivilinna at iki.fi (Jussi Kivilinna) Date: Thu, 20 Feb 2014 19:12:36 +0200 Subject: Android gpg-agent crashes in libgcrypt when signing, decrypting, importing secret keys In-Reply-To: <53054E77.8060608@guardianproject.info> References: <52D977BE.5070802@guardianproject.info> <52DA65F8.7060104@iki.fi> <52DB4FAD.3010303@guardianproject.info> <52DB9A0D.4040900@iki.fi> <52DD431C.2010301@guardianproject.info> <52E38F1B.809@iki.fi> <52E807F3.9000706@guardianproject.info> <87sis73eph.fsf@vigenere.g10code.de> <52E987EB.3000305@guardianproject.info> <52EA731D.20109@iki.fi> <52EAACD4.3090908@guardianproject.info> <52EAAE62.4060005@guardianproject.info> <52EB0868.1090805@guardianproject.info> <87wqhgy4sy.fsf@vigenere.g10code.de> <52EC6705.5010809@guardianproject.info> <52EE9CFF.9020806@iki.fi> <53054E77.8060608@guardianproject.info> Message-ID: <53063784.7020602@iki.fi> On 20.02.2014 02:38, Hans-Christoph Steiner wrote: > > On 02/02/2014 02:31 PM, Jussi Kivilinna wrote: >> On 01.02.2014 05:16, Hans-Christoph Steiner wrote: >>> >>> On 01/31/2014 02:43 AM, Werner Koch wrote: >>>> On Fri, 31 Jan 2014 03:20, hans at guardianproject.info said: >>>> >>>>> libgcrypt from master to the 1.6.x branch, which does not include "Parse >>>>> /proc/cpuinfo for ARM HW features". So its likely building with NEON >>>> >>>> I'll have a look at it. >>> >>> The adventure continues... now that the "Parse /proc/cpuinfo" patch is in >>> LIBGCRYPT-1-6-BRANCH and I removed --disable-neon-support to rely on >>> auto-detection, it builds for NEON and it now passes all of the libgcrypt >>> tests on the emulator. But now gpgme tests fail: >>> >>> Running gpgme/run-import --verbose pubkey-1.asc >>> run-import: file run-support.h line 133: Invalid crypto engine >>> Running gpgme/run-import --verbose pubdemo.asc >>> run-import: file run-support.h line 133: Invalid crypto engine >>> Running gpgme/run-import --verbose pubkey-1.asc >>> run-import: file run-support.h line 133: Invalid crypto engine >>> Running gpgme/run-keylist --verbose >>> run-keylist: file run-support.h line 133: Invalid crypto engine >>> >>> The complete build and test log is here: >>> https://dev.guardianproject.info/attachments/download/1141/gpga-build-and-test-log-neon-build-with-proc-cpuinfo.txt.bz2 >>> >>> So without the /proc/cpuinfo patch, all the tests pass (expect fdpassing and >>> fips random) and it also passes my manual tests on a device. >> >> Does the attached patch help? >> >> For me, the tests succeed with 'release' CFLAGS + -mno-unaligned-access and removed --disable-neon-support when using this patch to fix 'ARMv6 or newer' detection for libgcrypt configure. > > Hey Jussi, > > Your patch fixed the issue for me, but I don't see any new commits in > libgcrypt 1.6 branch related to this. Are there any open questions I can help > with? I was waiting for your feedback on the patch and then completely forgot about it :) Patch has now been pushed to libgcrypt 1.6 branch. -Jussi > > .hc > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 730 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Thu Feb 20 20:19:34 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Feb 2014 20:19:34 +0100 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <530630BB.2030508@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 20 Feb 2014 11:43:39 -0500") References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> <53061FA7.8020002@guardianproject.info> <87ppmh21w5.fsf@vigenere.g10code.de> <530630BB.2030508@guardianproject.info> Message-ID: <87d2ih1tix.fsf@vigenere.g10code.de> On Thu, 20 Feb 2014 17:43, hans at guardianproject.info said: > I understand that gpgme is a wrapper. The issue is having an Android wrapper No, GPGME is not a wrapper. GPGME is an API to several crypto protocols. The current implementation makes use of GnuPG. > So I would like to discuss what needs to happen in GnuPG itself to enable us > to write such a thing. This architecture would also work in other situation, For example EasyPG resembles the GPGME API for EMACS but nevertheless has lots of problems incompatibilities with newer GnuPG versions. I consider it better to use GPGME because we can guarantee that the GPGME API stays stable and that new stable feature of GnuPG will soon be reflected by the GPGME API. > for example a python wrapper of gpg-agent. gpg-agent is not enough. It is a useful tool but I guess it does only make sense if you are using gpg or gpgsm anyway. And then you should use GPGME which also provides an easy to use interface to gpg-agent. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Thu Feb 20 21:38:40 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 20 Feb 2014 15:38:40 -0500 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <87d2ih1tix.fsf@vigenere.g10code.de> References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> <53061FA7.8020002@guardianproject.info> <87ppmh21w5.fsf@vigenere.g10code.de> <530630BB.2030508@guardianproject.info> <87d2ih1tix.fsf@vigenere.g10code.de> Message-ID: <530667D0.7050901@guardianproject.info> On 02/20/2014 02:19 PM, Werner Koch wrote: > On Thu, 20 Feb 2014 17:43, hans at guardianproject.info said: > >> I understand that gpgme is a wrapper. The issue is having an Android wrapper > > No, GPGME is not a wrapper. GPGME is an API to several crypto > protocols. The current implementation makes use of GnuPG. > >> So I would like to discuss what needs to happen in GnuPG itself to enable us >> to write such a thing. This architecture would also work in other situation, > > For example EasyPG resembles the GPGME API for EMACS but nevertheless > has lots of problems incompatibilities with newer GnuPG versions. I > consider it better to use GPGME because we can guarantee that the GPGME > API stays stable and that new stable feature of GnuPG will soon be > reflected by the GPGME API. > >> for example a python wrapper of gpg-agent. > > gpg-agent is not enough. It is a useful tool but I guess it does only > make sense if you are using gpg or gpgsm anyway. And then you should > use GPGME which also provides an easy to use interface to gpg-agent. >From what I've seen, gpgme is a wrapper that calls the GnuPG command line tools (gpg2, gpgsm, gpg-agent, etc) to do the actual work. That arrangement will always be fragile on Android. That arrangement will also mean it will be very difficult to make native-feeling APIs in languages like Java and Python. That makes it harder for Java and Python developers to use GnuPG in their apps. It also means it is more likely that the API will be misused, leading to security issues. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From chris.gilg at link-comm.com Thu Feb 20 21:43:57 2014 From: chris.gilg at link-comm.com (Chris) Date: Thu, 20 Feb 2014 20:43:57 +0000 (UTC) Subject: gpgme and libassuan problem. References: Message-ID: Chris link-comm.com> writes: > > I'm attempting to build this on Blackfin, and I'm running into a few issues. > I've successfully built the required libraries. > > My application should link against the correct libraries with the below command. > > -L../../../../staging/usr/lib -lgpg-error -lassuan -lgpgme > > My problem is I get this at link time: > > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_new_ext' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_release' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_socket_connect' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_read_line' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_write_line' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_send_data' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to `_assuan_sendfd' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_get_active_fds' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_pending_line' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_ctx_set_system_hooks' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `___assuan_socketpair' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `___assuan_usleep' > ../../../../staging/usr/lib/libgpgme.so: undefined reference to > `_assuan_transact > > I was unable to find anything about gpgme complaining that it couldn't find > undefined references to something that should exist in libassuan. > > Any help would be greatly appreciated. Thanks. > I'm still stuck on this. I ran the nm command on libgpgme.so and the result I get is: U _assuan_ctx_set_system_hooks U _assuan_get_active_fds U _assuan_new_ext U _assuan_pending_line U _assuan_read_line U _assuan_release U _assuan_send_data U _assuan_sendfd U _assuan_socket_connect U _assuan_transact U _assuan_write_line I also did the same for the libassuan.so and the result I get(minus all the other entries): 0000284c t _assuan_ctx_set_system_hooks 000043c0 t _assuan_get_active_fds 00002368 t _assuan_new_ext 00003a10 t _assuan_pending_line 00004278 t _assuan_read_line 00004278 t _assuan_release 00003f3c t _assuan_send_data 00003d0c t _assuan_sendfd 000070d8 t _assuan_socket_connect 00003788 t _assuan_transact 00003ec8 t _assuan_write_line I've read that " *UND*(U) if the section is referenced in the file being dumped, but not defined there." According to that, it has the right requirements. I'm not sure what else to try. Any tips would be greatly appreciated. Thanks. From chris.gilg at link-comm.com Thu Feb 20 23:26:23 2014 From: chris.gilg at link-comm.com (Chris) Date: Thu, 20 Feb 2014 22:26:23 +0000 (UTC) Subject: gpgme and libassuan problem. References: Message-ID: Chris link-comm.com> writes: > > I'm still stuck on this. > > I ran the nm command on libgpgme.so and the result I get is: > > U _assuan_ctx_set_system_hooks > U _assuan_get_active_fds > U _assuan_new_ext > U _assuan_pending_line > U _assuan_read_line > U _assuan_release > U _assuan_send_data > U _assuan_sendfd > U _assuan_socket_connect > U _assuan_transact > U _assuan_write_line > > I also did the same for the libassuan.so and the result I get(minus all the > other entries): > > 0000284c t _assuan_ctx_set_system_hooks > 000043c0 t _assuan_get_active_fds > 00002368 t _assuan_new_ext > 00003a10 t _assuan_pending_line > 00004278 t _assuan_read_line > 00004278 t _assuan_release > 00003f3c t _assuan_send_data > 00003d0c t _assuan_sendfd > 000070d8 t _assuan_socket_connect > 00003788 t _assuan_transact > 00003ec8 t _assuan_write_line > > I've read that " *UND*(U) if the section is referenced in the file being > dumped, but not defined there." > According to that, it has the right requirements. > > I'm not sure what else to try. Any tips would be greatly appreciated. Thanks. > More information: I added the --cref to the linker so I can see more output. What I get seems to be backwards: assuan_ctx_set_system_hooks ../../../../staging/usr/lib/libgpgme.so assuan_get_active_fds ../../../../staging/usr/lib/libgpgme.so assuan_new_ext ../../../../staging/usr/lib/libgpgme.so assuan_pending_line ../../../../staging/usr/lib/libgpgme.so assuan_read_line ../../../../staging/usr/lib/libgpgme.so assuan_release ../../../../staging/usr/lib/libgpgme.so assuan_send_data ../../../../staging/usr/lib/libgpgme.so assuan_sendfd ../../../../staging/usr/lib/libgpgme.so assuan_socket_connect ../../../../staging/usr/lib/libgpgme.so assuan_transact ../../../../staging/usr/lib/libgpgme.so assuan_write_line ../../../../staging/usr/lib/libgpgme.so That output is saying that the assuan_new_ext function is defined in gpgme and not libassuan. Documentation states that: "If the symbol is defined, the first file listed is the location of the definition. The remaining files contain references to the symbol." What I should be seeing is: assuan_ctx_set_system_hooks ../../../../staging/usr/lib/libassuan.so <-- where the function is defined. ../../../../staging/usr/lib/libgpgme.so <-- where the function is referenced. Am I doing something wrong? From wk at gnupg.org Fri Feb 21 13:26:13 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Feb 2014 13:26:13 +0100 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <530667D0.7050901@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 20 Feb 2014 15:38:40 -0500") References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> <53061FA7.8020002@guardianproject.info> <87ppmh21w5.fsf@vigenere.g10code.de> <530630BB.2030508@guardianproject.info> <87d2ih1tix.fsf@vigenere.g10code.de> <530667D0.7050901@guardianproject.info> Message-ID: <87wqgozm6y.fsf@vigenere.g10code.de> On Thu, 20 Feb 2014 21:38, hans at guardianproject.info said: >>From what I've seen, gpgme is a wrapper that calls the GnuPG command line > tools (gpg2, gpgsm, gpg-agent, etc) to do the actual work. That arrangement > will always be fragile on Android. That arrangement will also mean it will be What you are saying is that Android is more fragile and hardder to work with than the ancient Windows Mobile 6 which works very well using gpgme despit ethat it is really limited in almost all areas. > very difficult to make native-feeling APIs in languages like Java and Python. We have several language bindings both high and low-level. So I don't understand your reasoning. After all GnuPG is not different from GPGME - it uses Unix domain sockets and pipes for IPC as well. Java bindings are available for 10 years of even longer. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Feb 21 13:28:56 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Feb 2014 13:28:56 +0100 Subject: gpgme and libassuan problem. In-Reply-To: (Chris's message of "Thu, 20 Feb 2014 20:43:57 +0000 (UTC)") References: Message-ID: <87sirczm2f.fsf@vigenere.g10code.de> On Thu, 20 Feb 2014 21:43, chris.gilg at link-comm.com said: >> -L../../../../staging/usr/lib -lgpg-error -lassuan -lgpgme Running "gpgme-config --libs" on my Linux box shows -L/usr/local/lib -lgpgme -lassuan -lgpg-error thus I wonder why you reverted the order of the libraries. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Fri Feb 21 15:39:45 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 21 Feb 2014 09:39:45 -0500 Subject: gpgme "Locate engine names only at runtime and prefer GnuPG-2" commit break Android In-Reply-To: <87wqgozm6y.fsf@vigenere.g10code.de> References: <530560FB.60303@guardianproject.info> <87iosa2bt3.fsf@vigenere.g10code.de> <53061FA7.8020002@guardianproject.info> <87ppmh21w5.fsf@vigenere.g10code.de> <530630BB.2030508@guardianproject.info> <87d2ih1tix.fsf@vigenere.g10code.de> <530667D0.7050901@guardianproject.info> <87wqgozm6y.fsf@vigenere.g10code.de> Message-ID: <53076531.9030303@guardianproject.info> On 02/21/2014 07:26 AM, Werner Koch wrote: > On Thu, 20 Feb 2014 21:38, hans at guardianproject.info said: > >> >From what I've seen, gpgme is a wrapper that calls the GnuPG command line >> tools (gpg2, gpgsm, gpg-agent, etc) to do the actual work. That arrangement >> will always be fragile on Android. That arrangement will also mean it will be > > What you are saying is that Android is more fragile and hardder to work > with than the ancient Windows Mobile 6 which works very well using gpgme > despit ethat it is really limited in almost all areas. What I am saying is that Android works quite differently than UNIX, and even Windows Mobile 6 is closer to UNIX than Android. From what I've seen, GnuPG is built very much on UNIX assumptions, and those mostly work on even old Windows. But those don't really work on Android. This is what makes GnuPG fragile on Android. To make matters more confusing, Android does provide a super stripped down, UNIX-ish environment that can do some very basic UNIX things (i.e. `adb shell`). But apps do not run in this UNIX-ish environment. You cannot login to `adb shell` and run an app directly. In order to start an app, you must send a message to the system requesting that app to start (the command line util for sending that message is called `am`). That super stripped down UNIX env is what allows us to run GnuPG and other GNU and UNIX tools at all on Android. But this is not an officially supported way of working Android, and OS updates often break aspects of it. (Android 4.4.2 basically broke all of our apps that use these techniques). Ideally, GnuPG/gpgme would only use function calls, not execs and pipes. Env vars should never be required for operation. >> very difficult to make native-feeling APIs in languages like Java and Python. > > We have several language bindings both high and low-level. So I don't > understand your reasoning. After all GnuPG is not different from GPGME > - it uses Unix domain sockets and pipes for IPC as well. Java bindings > are available for 10 years of even longer. There are many gpgme bindings, that is true. From my experience in C, Java, and Python, those bindings require the Java and Python programmer to work in ways that are quite unfamiliar, things like the data structures used, how to iterate thru collections of data, how streams are represented and passed around, etc. So Java and Python bindings have existed for a long time, but the ones based on GnuPG are barely used (esp. the Java ones). BouncyCastle and pycrypto dominate in their languages, IMHO because it feels the most natural. The GnuPG suite offers all the functionality with a much better track record for security. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From chris.gilg at link-comm.com Fri Feb 21 18:25:26 2014 From: chris.gilg at link-comm.com (Chris) Date: Fri, 21 Feb 2014 17:25:26 +0000 (UTC) Subject: gpgme and libassuan problem. References: <87sirczm2f.fsf@vigenere.g10code.de> Message-ID: Werner Koch gnupg.org> writes: > > On Thu, 20 Feb 2014 21:43, chris.gilg link-comm.com said: > > >> -L../../../../staging/usr/lib -lgpg-error -lassuan -lgpgme > > Running "gpgme-config --libs" on my Linux box shows > > -L/usr/local/lib -lgpgme -lassuan -lgpg-error > > thus I wonder why you reverted the order of the libraries. > > Shalom-Salam, > > Werner > Must have been an oversight on my part. I rearranged the linker flags in order according to the same command. I still get the same undefined references messages. From gniibe at fsij.org Mon Feb 24 05:03:33 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 24 Feb 2014 13:03:33 +0900 Subject: [PATCH] agent: API change of agent_key_from_file Message-ID: <1393214613.6874.1.camel@cfw2.gniibe.org> Hello, I'd like to update the smartcard support of ECC in the master branch. I found that current master doesn't work well for signing with ECC key by smartcard (it worked in 2013, IIRC). Perhaps, it is due to some interface changes of libgcrypt. Specifically, gpg-agent fails in the function agent_public_key_from_file, when it will find required parameters are not found. In the file, it's S-expression and it's like: (shadowed-private-key (ecc (curve "secp256k1") (q ) (shadowed t1-v1 ( "OPENPGP.1")))) and the function function agent_public_key_from_file tries to fill paramerters of "pabgnq" (while only the parameter "q" is available directly). I think that we need some clean up here. Reading the code which calls agent_public_key_from_file (agent_pksign_do), all we need to know is which key type. My proposal fix is to change the semantics of agent_key_from_file a bit. Currently, callers of agent_key_from_file know that private key is on smartcard by examining S_SKEY. I'd like to change this function to return the content of S_SKEY always (even if the private key is on smartcard), so that we can check the key type later. We can examine the SHADOW_INFO to know it's on smartcard or not. Here's the patch. Any comments are appreciated. diff --git a/agent/command.c b/agent/command.c index 4fa40d9..c2f3752 100644 --- a/agent/command.c +++ b/agent/command.c @@ -1667,7 +1667,7 @@ cmd_passwd (assuan_context_t ctx, char *line) &s_skey, &passphrase); if (err) ; - else if (!s_skey) + else if (shadow_info) { log_error ("changing a smartcard PIN is not yet supported\n"); err = gpg_error (GPG_ERR_NOT_IMPLEMENTED); @@ -2126,6 +2126,7 @@ cmd_export_key (assuan_context_t ctx, char *line) int openpgp; char *cache_nonce; char *passphrase = NULL; + unsigned char *shadow_info = NULL; openpgp = has_option (line, "--openpgp"); cache_nonce = option_value (line, "--cache-nonce"); @@ -2163,11 +2164,11 @@ cmd_export_key (assuan_context_t ctx, char *line) /* Get the key from the file. With the openpgp flag we also ask for the passphrase so that we can use it to re-encrypt it. */ err = agent_key_from_file (ctrl, NULL, ctrl->server_local->keydesc, grip, - NULL, CACHE_MODE_IGNORE, NULL, &s_skey, + &shadow_info, CACHE_MODE_IGNORE, NULL, &s_skey, openpgp ? &passphrase : NULL); if (err) goto leave; - if (!s_skey) + if (shadow_info) { /* Key is on a smartcard. Actually we should not see this here because we do not pass a shadow_info variable to the above @@ -2241,6 +2242,7 @@ cmd_export_key (assuan_context_t ctx, char *line) gcry_sexp_release (s_skey); xfree (ctrl->server_local->keydesc); ctrl->server_local->keydesc = NULL; + xfree (shadow_info); return leave_cmd (ctx, err); } @@ -2260,7 +2262,7 @@ cmd_keytocard (assuan_context_t ctx, char *line) unsigned char *keydata; size_t keydatalen, timestamplen; const char *serialno, *timestamp_str, *id; - unsigned char *shadow_info; + unsigned char *shadow_info = NULL; unsigned char *shdkey; time_t timestamp; @@ -2305,12 +2307,20 @@ cmd_keytocard (assuan_context_t ctx, char *line) return gpg_error (GPG_ERR_INV_VALUE); err = agent_key_from_file (ctrl, NULL, ctrl->server_local->keydesc, grip, - NULL, CACHE_MODE_IGNORE, NULL, &s_skey, NULL); + &shadow_info, CACHE_MODE_IGNORE, NULL, + &s_skey, NULL); if (err) - return err; - if (!s_skey) - /* Key is on a smartcard already. */ - return gpg_error (GPG_ERR_UNUSABLE_SECKEY); + { + xfree (shadow_info); + return err; + } + if (shadow_info) + { + /* Key is on a smartcard already. */ + xfree (shadow_info); + shadow_info = NULL; + return gpg_error (GPG_ERR_UNUSABLE_SECKEY); + } keydatalen = gcry_sexp_sprint (s_skey, GCRYSEXP_FMT_CANON, NULL, 0); keydata = xtrymalloc_secure (keydatalen + 30); diff --git a/agent/findkey.c b/agent/findkey.c index 6464b02..7d8c41a 100644 --- a/agent/findkey.c +++ b/agent/findkey.c @@ -562,7 +562,6 @@ agent_key_from_file (ctrl_t ctrl, const char *cache_nonce, unsigned char *buf; size_t len, buflen, erroff; gcry_sexp_t s_skey; - int got_shadow_info = 0; *result = NULL; if (shadow_info) @@ -638,7 +637,6 @@ agent_key_from_file (ctrl_t ctrl, const char *cache_nonce, { memcpy (*shadow_info, s, n); rc = 0; - got_shadow_info = 1; } } if (rc) @@ -654,7 +652,7 @@ agent_key_from_file (ctrl_t ctrl, const char *cache_nonce, } gcry_sexp_release (s_skey); s_skey = NULL; - if (rc || got_shadow_info) + if (rc) { xfree (buf); if (r_passphrase) diff --git a/agent/pkdecrypt.c b/agent/pkdecrypt.c index 9924d6d..14aa78f 100644 --- a/agent/pkdecrypt.c +++ b/agent/pkdecrypt.c @@ -79,7 +79,7 @@ agent_pkdecrypt (ctrl_t ctrl, const char *desc_text, goto leave; } - if (!s_skey) + if (shadow_info) { /* divert operation to the smartcard */ if (!gcry_sexp_canon_len (ciphertext, ciphertextlen, NULL, NULL)) diff --git a/agent/pksign.c b/agent/pksign.c index 4d0a240..0886150 100644 --- a/agent/pksign.c +++ b/agent/pksign.c @@ -299,31 +299,20 @@ agent_pksign_do (ctrl_t ctrl, const char *cache_nonce, goto leave; } - if (!s_skey) + if (shadow_info) { /* Divert operation to the smartcard */ - gcry_sexp_t s_pkey, l; - const char *name; size_t len; unsigned char *buf = NULL; + int key_type; int is_RSA = 0; int is_ECDSA = 0; - /* Check keytype by public key */ - rc = agent_public_key_from_file (ctrl, ctrl->keygrip, &s_pkey); - if (rc) - { - log_error ("failed to read the public key\n"); - goto leave; - } - l = gcry_sexp_cadr (s_pkey); - name = gcry_sexp_nth_data (l, 0, &len); - if (len == 3 && !memcmp (name, "rsa", 3)) + key_type = agent_is_dsa_key (s_skey); + if (key_type == 0) is_RSA = 1; - else if (len == 5 && !memcmp (name, "ecdsa", 5)) + else if (key_type == GCRY_PK_ECDSA) is_ECDSA = 1; - gcry_sexp_release (l); - gcry_sexp_release (s_pkey); rc = divert_pksign (ctrl, ctrl->digest.value, -- From gniibe at fsij.org Mon Feb 24 05:21:00 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 24 Feb 2014 13:21:00 +0900 Subject: [PATCH] scd: writekey support of ECC Message-ID: <1393215660.6874.3.camel@cfw2.gniibe.org> Hello, Last year, I lost the opportunity to merge my work of ECC smartcard support (specifically, ECDSA). IIRC, we didn't have any agreements on ECDH. I implemented ECDSA (with NIST P-256) on Gnuk around March 2013, and submitted partial change of GnuPG. Perhaps, it was just the code enough to use with OpenSSH, and I forgot to send writekey change. Here are changes. It will by by two commits. (1) Support of secp256k1 curve. (2) Enhance do_writekey to support ECC keys. Now, we have two routines: rsa_writekey and ecdsa_writekey. ecdh_writekey is not yet supported. Built successfully and tested with development version of Gnuk. diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c index 3d7136f..23947fc 100644 --- a/scd/app-openpgp.c +++ b/scd/app-openpgp.c @@ -45,6 +45,7 @@ #include #include #include +#include #include #include #include @@ -143,7 +144,9 @@ enum { CURVE_NIST_P256, CURVE_NIST_P384, - CURVE_NIST_P521 + CURVE_NIST_P521, + CURVE_SEC_P256K1, + CURVE_UNKOWN, }; @@ -735,24 +738,56 @@ parse_login_data (app_t app) xfree (relptr); } + +static unsigned char +get_algo_byte (key_type_t key_type) +{ + if (key_type == KEY_TYPE_ECDSA) + return 19; + else if (key_type == KEY_TYPE_ECDH) + return 18; + else + return 1; /* RSA */ +} + /* Note, that FPR must be at least 20 bytes. */ static gpg_error_t store_fpr (app_t app, int keynumber, u32 timestamp, - const unsigned char *m, size_t mlen, - const unsigned char *e, size_t elen, - unsigned char *fpr, unsigned int card_version) + unsigned char *fpr, unsigned int card_version, + key_type_t key_type, + ...) { unsigned int n, nbits; unsigned char *buffer, *p; int tag, tag2; int rc; + const unsigned char *m; + size_t mlen; + va_list ap; + int argc; + int i; - for (; mlen && !*m; mlen--, m++) /* strip leading zeroes */ - ; - for (; elen && !*e; elen--, e++) /* strip leading zeroes */ - ; + n = 6; /* key packet version, 4-byte timestamps, and algorithm */ + if (key_type == KEY_TYPE_RSA || key_type == KEY_TYPE_ECDSA) + argc = 2; + else if (key_type == KEY_TYPE_ECDH) + argc = 3; + else + return gpg_error (GPG_ERR_NOT_IMPLEMENTED); + + va_start (ap, key_type); + for (i = 0; i < argc; i++) + { + m = va_arg (ap, const unsigned char *); + mlen = va_arg (ap, size_t); + for (; mlen && !*m; mlen--, m++) /* strip leading zeroes */ + ; + if (key_type == KEY_TYPE_RSA || i == 1) + n += 2; + n += mlen; + } + va_end (ap); - n = 6 + 2 + mlen + 2 + elen; p = buffer = xtrymalloc (3 + n); if (!buffer) return gpg_error_from_syserror (); @@ -765,15 +800,24 @@ store_fpr (app_t app, int keynumber, u32 timestamp, *p++ = timestamp >> 16; *p++ = timestamp >> 8; *p++ = timestamp; - *p++ = 1; /* RSA */ - nbits = count_bits (m, mlen); - *p++ = nbits >> 8; - *p++ = nbits; - memcpy (p, m, mlen); p += mlen; - nbits = count_bits (e, elen); - *p++ = nbits >> 8; - *p++ = nbits; - memcpy (p, e, elen); p += elen; + *p++ = get_algo_byte (key_type); + + va_start (ap, key_type); + for (i = 0; i < argc; i++) + { + m = va_arg (ap, const unsigned char *); + mlen = va_arg (ap, size_t); + for (; mlen && !*m; mlen--, m++) /* strip leading zeroes */ + ; + if (key_type == KEY_TYPE_RSA || i == 1) + { + nbits = count_bits (m, mlen); + *p++ = nbits >> 8; + *p++ = nbits; + } + memcpy (p, m, mlen); p += mlen; + } + va_end (ap); gcry_md_hash_buffer (GCRY_MD_SHA1, fpr, buffer, n+3); @@ -889,11 +933,16 @@ get_ecc_key_parameters (int curve, int *r_n_bits, const char **r_curve_oid) *r_n_bits = 384; *r_curve_oid = "1.3.132.0.34"; } - else + else if (curve == CURVE_NIST_P521) { *r_n_bits = 521; *r_curve_oid = "1.3.132.0.35"; } + else + { + *r_n_bits = 256; + *r_curve_oid = "1.3.132.0.10"; + } } static void @@ -1234,8 +1283,10 @@ get_curve_name (int curve) return "NIST P-256"; else if (curve == CURVE_NIST_P384) return "NIST P-384"; - else + else if (curve == CURVE_NIST_P521) return "NIST P-521"; + else + return "secp256k1"; } @@ -1456,7 +1507,7 @@ get_public_key (app_t app, int keyno) = get_curve_name (app->app_local->keyattr[keyno].ecdsa.curve); err = gcry_sexp_build (&s_pkey, NULL, - "(public-key(ecdsa(curve%s)(q%b)))", + "(public-key(ecc(curve%s)(q%b)))", curve_name, mlen, mbuf); if (err) goto leave; @@ -2500,8 +2551,6 @@ add_tlv (unsigned char *buffer, unsigned int tag, size_t length) } -/* Build the private key template as specified in the OpenPGP specs - v2.0 section 4.3.3.7. */ static gpg_error_t build_privkey_template (app_t app, int keyno, const unsigned char *rsa_n, size_t rsa_n_len, @@ -2648,6 +2697,74 @@ build_privkey_template (app_t app, int keyno, return 0; } +static gpg_error_t +build_ecdsa_privkey_template (app_t app, int keyno, + const unsigned char *ecc_d, size_t ecc_d_len, + unsigned char **result, size_t *resultlen) +{ + unsigned char privkey[2]; + size_t privkey_len; + unsigned char exthdr[2+2+1]; + size_t exthdr_len; + unsigned char suffix[2+1]; + size_t suffix_len; + unsigned char *tp; + size_t datalen; + unsigned char *template; + size_t template_size; + + *result = NULL; + *resultlen = 0; + + /* Build the 7f48 cardholder private key template. */ + datalen = 0; + tp = privkey; + + tp += add_tlv (tp, 0x91, ecc_d_len); + datalen += ecc_d_len; + + privkey_len = tp - privkey; + + /* Build the extended header list without the private key template. */ + tp = exthdr; + *tp++ = keyno ==0 ? 0xb6 : keyno == 1? 0xb8 : 0xa4; + *tp++ = 0; + tp += add_tlv (tp, 0x7f48, privkey_len); + exthdr_len = tp - exthdr; + + /* Build the 5f48 suffix of the data. */ + tp = suffix; + tp += add_tlv (tp, 0x5f48, datalen); + suffix_len = tp - suffix; + + /* Now concatenate everything. */ + template_size = (1 + 1 /* 0x4d and len. */ + + exthdr_len + + privkey_len + + suffix_len + + datalen); + tp = template = xtrymalloc_secure (template_size); + if (!template) + return gpg_error_from_syserror (); + + tp += add_tlv (tp, 0x4d, exthdr_len + privkey_len + suffix_len + datalen); + memcpy (tp, exthdr, exthdr_len); + tp += exthdr_len; + memcpy (tp, privkey, privkey_len); + tp += privkey_len; + memcpy (tp, suffix, suffix_len); + tp += suffix_len; + + memcpy (tp, ecc_d, ecc_d_len); + tp += ecc_d_len; + + assert (tp - template == template_size); + + *result = template; + *resultlen = tp - template; + return 0; +} + /* Helper for do_writekley to change the size of a key. Not ethat this deletes the entire key without asking. */ @@ -2749,26 +2866,15 @@ change_keyattr_from_string (app_t app, } -/* Handle the WRITEKEY command for OpenPGP. This function expects a - canonical encoded S-expression with the secret key in KEYDATA and - its length (for assertions) in KEYDATALEN. KEYID needs to be the - usual keyid which for OpenPGP is the string "OPENPGP.n" with - n=1,2,3. Bit 0 of FLAGS indicates whether an existing key shall - get overwritten. PINCB and PINCB_ARG are the usual arguments for - the pinentry callback. */ static gpg_error_t -do_writekey (app_t app, ctrl_t ctrl, - const char *keyid, unsigned int flags, - gpg_error_t (*pincb)(void*, const char *, char **), - void *pincb_arg, - const unsigned char *keydata, size_t keydatalen) +rsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), + void *pincb_arg, int keyno, + const unsigned char *buf, size_t buflen, int depth) { gpg_error_t err; - int force = (flags & 1); - int keyno; - const unsigned char *buf, *tok; - size_t buflen, toklen; - int depth, last_depth1, last_depth2; + const unsigned char *tok; + size_t toklen; + int last_depth1, last_depth2; const unsigned char *rsa_n = NULL; const unsigned char *rsa_e = NULL; const unsigned char *rsa_p = NULL; @@ -2782,52 +2888,6 @@ do_writekey (app_t app, ctrl_t ctrl, unsigned char fprbuf[20]; u32 created_at = 0; - (void)ctrl; - - if (!strcmp (keyid, "OPENPGP.1")) - keyno = 0; - else if (!strcmp (keyid, "OPENPGP.2")) - keyno = 1; - else if (!strcmp (keyid, "OPENPGP.3")) - keyno = 2; - else - return gpg_error (GPG_ERR_INV_ID); - - err = does_key_exist (app, keyno, 0, force); - if (err) - return err; - - - /* - Parse the S-expression - */ - buf = keydata; - buflen = keydatalen; - depth = 0; - if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) - goto leave; - if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) - goto leave; - if (!tok || toklen != 11 || memcmp ("private-key", tok, toklen)) - { - if (!tok) - ; - else if (toklen == 21 && !memcmp ("protected-private-key", tok, toklen)) - log_info ("protected-private-key passed to writekey\n"); - else if (toklen == 20 && !memcmp ("shadowed-private-key", tok, toklen)) - log_info ("shadowed-private-key passed to writekey\n"); - err = gpg_error (GPG_ERR_BAD_SECKEY); - goto leave; - } - if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) - goto leave; - if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) - goto leave; - if (!tok || toklen != 3 || memcmp ("rsa", tok, toklen)) - { - err = gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); - goto leave; - } last_depth1 = depth; while (!(err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)) && depth && depth >= last_depth1) @@ -3100,9 +3160,198 @@ do_writekey (app_t app, ctrl_t ctrl, goto leave; } - err = store_fpr (app, keyno, created_at, - rsa_n, rsa_n_len, rsa_e, rsa_e_len, - fprbuf, app->card_version); + err = store_fpr (app, keyno, created_at, fprbuf, app->card_version, + KEY_TYPE_RSA, rsa_n, rsa_n_len, rsa_e, rsa_e_len); + if (err) + goto leave; + + + leave: + xfree (template); + return err; +} + + +static gpg_error_t +ecdh_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), + void *pincb_arg, int keyno, + const unsigned char *buf, size_t buflen, int depth) +{ + return GPG_ERR_NOT_IMPLEMENTED; +} + + +static gpg_error_t +ecdsa_writekey (app_t app, gpg_error_t (*pincb)(void*, const char *, char **), + void *pincb_arg, int keyno, + const unsigned char *buf, size_t buflen, int depth) +{ + gpg_error_t err; + const unsigned char *tok; + size_t toklen; + int last_depth1, last_depth2; + 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_UNKOWN; + + /* (private-key(ecdsa(curve%s)(q%m)(d%m))): curve = "1.2.840.10045.3.1.7" */ + /* (private-key(ecc(curve%s)(q%m)(d%m))): curve = "secp256k1" */ + last_depth1 = depth; + while (!(err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)) + && depth && depth >= last_depth1) + { + if (tok) + { + err = gpg_error (GPG_ERR_UNKNOWN_SEXP); + goto leave; + } + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + + if (tok && toklen == 5 && !memcmp (tok, "curve", 5)) + { + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + + if (tok && toklen == 19 && !memcmp (tok, "1.2.840.10045.3.1.7", 19)) + curve = CURVE_NIST_P256; + else if (tok && toklen == 9 && !memcmp (tok, "secp256k1", 9)) + curve = CURVE_SEC_P256K1; + } + else if (tok && toklen == 1) + { + const unsigned char **mpi; + size_t *mpi_len; + + switch (*tok) + { + case 'q': mpi = &ecc_q; mpi_len = &ecc_q_len; break; + case 'd': mpi = &ecc_d; mpi_len = &ecc_d_len; break; + default: mpi = NULL; mpi_len = NULL; break; + } + if (mpi && *mpi) + { + err = gpg_error (GPG_ERR_DUP_VALUE); + goto leave; + } + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + if (tok && mpi) + { + /* Strip off leading zero bytes and save. */ + for (;toklen && !*tok; toklen--, tok++) + ; + *mpi = tok; + *mpi_len = toklen; + } + } + /* Skip until end of list. */ + last_depth2 = depth; + while (!(err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)) + && depth && depth >= last_depth2) + ; + if (err) + goto leave; + } + /* Parse other attributes. */ + last_depth1 = depth; + while (!(err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)) + && depth && depth >= last_depth1) + { + if (tok) + { + err = gpg_error (GPG_ERR_UNKNOWN_SEXP); + goto leave; + } + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + if (tok && toklen == 10 && !memcmp ("created-at", tok, toklen)) + { + if ((err = parse_sexp (&buf,&buflen,&depth,&tok,&toklen))) + goto leave; + if (tok) + { + for (created_at=0; toklen && *tok && *tok >= '0' && *tok <= '9'; + tok++, toklen--) + created_at = created_at*10 + (*tok - '0'); + } + } + /* Skip until end of list. */ + last_depth2 = depth; + while (!(err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen)) + && depth && depth >= last_depth2) + ; + if (err) + goto leave; + } + + + /* Check that we have all parameters and that they match the card + description. */ + if (!created_at) + { + log_error (_("creation timestamp missing\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); + + /* We need to remove the cached public key. */ + xfree (app->app_local->pk[keyno].key); + app->app_local->pk[keyno].key = NULL; + app->app_local->pk[keyno].keylen = 0; + app->app_local->pk[keyno].read_done = 0; + + if (app->app_local->extcap.is_v2) + { + /* Build the private key template as described in section 4.3.3.7 of + the OpenPGP card specs version 2.0. */ + int exmode; + + err = build_ecdsa_privkey_template (app, keyno, + ecc_d, ecc_d_len, + &template, &template_len); + if (err) + goto leave; + + /* Prepare for storing the key. */ + err = verify_chv3 (app, pincb, pincb_arg); + if (err) + goto leave; + + /* Store the key. */ + if (app->app_local->cardcap.ext_lc_le && template_len > 254) + exmode = 1; /* Use extended length w/o a limit. */ + else if (app->app_local->cardcap.cmd_chaining && template_len > 254) + exmode = -254; + else + exmode = 0; + err = iso7816_put_data_odd (app->slot, exmode, 0x3fff, + template, template_len); + } + else + return gpg_error (GPG_ERR_NOT_SUPPORTED); + + if (err) + { + log_error (_("failed to store the key: %s\n"), gpg_strerror (err)); + goto leave; + } + + err = store_fpr (app, keyno, created_at, fprbuf, app->card_version, + KEY_TYPE_ECDSA, + curve == CURVE_NIST_P256? + "\x08\x2a\x86\x48\xce\x3d\x03\x01\x07" + : "\05\x2b\x81\x04\x00\x0a", + curve == CURVE_NIST_P256? 9 : 6, + ecc_q, ecc_q_len); if (err) goto leave; @@ -3112,6 +3361,89 @@ do_writekey (app_t app, ctrl_t ctrl, return err; } +/* Handle the WRITEKEY command for OpenPGP. This function expects a + canonical encoded S-expression with the secret key in KEYDATA and + its length (for assertions) in KEYDATALEN. KEYID needs to be the + usual keyid which for OpenPGP is the string "OPENPGP.n" with + n=1,2,3. Bit 0 of FLAGS indicates whether an existing key shall + get overwritten. PINCB and PINCB_ARG are the usual arguments for + the pinentry callback. */ +static gpg_error_t +do_writekey (app_t app, ctrl_t ctrl, + const char *keyid, unsigned int flags, + gpg_error_t (*pincb)(void*, const char *, char **), + void *pincb_arg, + const unsigned char *keydata, size_t keydatalen) +{ + gpg_error_t err; + int force = (flags & 1); + int keyno; + const unsigned char *buf, *tok; + size_t buflen, toklen; + int depth; + + (void)ctrl; + + if (!strcmp (keyid, "OPENPGP.1")) + keyno = 0; + else if (!strcmp (keyid, "OPENPGP.2")) + keyno = 1; + else if (!strcmp (keyid, "OPENPGP.3")) + keyno = 2; + else + return gpg_error (GPG_ERR_INV_ID); + + err = does_key_exist (app, keyno, 0, force); + if (err) + return err; + + + /* + Parse the S-expression + */ + buf = keydata; + buflen = keydatalen; + depth = 0; + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + if (!tok || toklen != 11 || memcmp ("private-key", tok, toklen)) + { + if (!tok) + ; + else if (toklen == 21 && !memcmp ("protected-private-key", tok, toklen)) + log_info ("protected-private-key passed to writekey\n"); + else if (toklen == 20 && !memcmp ("shadowed-private-key", tok, toklen)) + log_info ("shadowed-private-key passed to writekey\n"); + err = gpg_error (GPG_ERR_BAD_SECKEY); + goto leave; + } + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + if ((err = parse_sexp (&buf, &buflen, &depth, &tok, &toklen))) + goto leave; + if (tok && toklen == 3 && memcmp ("rsa", tok, toklen) == 0) + rsa_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); + else if ((tok && toklen == 3 && memcmp ("ecc", tok, toklen) == 0 + && (keyno == 0 || keyno == 2)) + || (tok && toklen == 5 && memcmp ("ecdsa", tok, toklen) == 0)) + ecdsa_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); + else if ((tok && toklen == 3 && memcmp ("ecc", tok, toklen) == 0 + && keyno == 1) + || (tok && toklen == 4 && memcmp ("ecdh", tok, toklen) == 0)) + ecdh_writekey (app, pincb, pincb_arg, keyno, buf, buflen, depth); + else + { + err = gpg_error (GPG_ERR_WRONG_PUBKEY_ALGO); + goto leave; + } + + leave: + return err; +} + + /* Handle the GENKEY command. */ static gpg_error_t @@ -3234,8 +3566,8 @@ 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, - m, mlen, e, elen, fprbuf, app->card_version); + rc = store_fpr (app, keyno, (u32)created_at, fprbuf, app->card_version, + KEY_TYPE_RSA, m, mlen, e, elen); if (rc) goto leave; send_fpr_if_not_null (ctrl, "KEY-FPR", -1, fprbuf); @@ -3973,8 +4305,10 @@ parse_ecc_curve (const unsigned char *buffer, size_t buflen) curve = CURVE_NIST_P384; else if (buflen == 6 && buffer[5] == 0x23) curve = CURVE_NIST_P521; - else + else if (buflen == 9) curve = CURVE_NIST_P256; + else + curve = CURVE_SEC_P256K1; return curve; } -- From gniibe at fsij.org Mon Feb 24 09:42:07 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 24 Feb 2014 17:42:07 +0900 Subject: [PATCH] scd: writekey support of ECC In-Reply-To: <1393215660.6874.3.camel@cfw2.gniibe.org> References: <1393215660.6874.3.camel@cfw2.gniibe.org> Message-ID: <1393231327.6874.9.camel@cfw2.gniibe.org> On 2014-02-24 at 13:21 +0900, NIIBE Yutaka wrote: > Last year, I lost the opportunity to merge my work of ECC smartcard > support (specifically, ECDSA). IIRC, we didn't have any agreements on > ECDH. I implemented ECDSA (with NIST P-256) on Gnuk around March > 2013, and submitted partial change of GnuPG. Perhaps, it was just the > code enough to use with OpenSSH, and I forgot to send writekey change. Reading the archive of gnupg-devel, it reminds me. I stopped because of lack of information for the tag value of ECDSA in the private key template. I posted to the list: OpenPGP card specification enhancement for ECDSA support: key import http://lists.gnupg.org/pipermail/gnupg-devel/2013-March/027487.html Last year, I read JIS X 6320-8:2006 (Japanese one of ISO/IEC 7816-8:2004), which was reaffirmed in 2010-10-01. There, we have RSA example (not as standard) for private key template 7f48, but that's all. New revision of ISO/IEC 7816-8 is currently under development, and perhaps, it will include ECDSA tag. -- From hans at guardianproject.info Mon Feb 24 19:40:33 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 24 Feb 2014 13:40:33 -0500 Subject: how to install the po translations on Android Message-ID: <530B9221.6050409@guardianproject.info> I see that the translation files are spread across 'gnupg' and 'libgpg-error', but the files generated from .po (.mo and .gmo?) don't seem to be installed anywhere. How should I be installing the translation files? "make install" does not seem to include them. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Mon Feb 24 20:41:07 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 24 Feb 2014 20:41:07 +0100 Subject: how to install the po translations on Android In-Reply-To: <530B9221.6050409@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 24 Feb 2014 13:40:33 -0500") References: <530B9221.6050409@guardianproject.info> Message-ID: <878ut0xprg.fsf@vigenere.g10code.de> On Mon, 24 Feb 2014 19:40, hans at guardianproject.info said: > I see that the translation files are spread across 'gnupg' and 'libgpg-error', > but the files generated from .po (.mo and .gmo?) don't seem to be installed > anywhere. You might have missed them because they are renamed during instalaltion. For example the de.po files from all packages will be installed below /usr/local/share/locale/de/LC_MESSAGES/ Thus after installing gnupg and libgpg-error you should have at least theses file: /usr/local/share/locale/de/LC_MESSAGES/libgpg-error.mo /usr/local/share/locale/de/LC_MESSAGES/gnupg2.mo "gnupg2" is used to avoid conflicts with transations from GnuPG-1. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Mon Feb 24 21:07:25 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 24 Feb 2014 15:07:25 -0500 Subject: how to install the po translations on Android In-Reply-To: <878ut0xprg.fsf@vigenere.g10code.de> References: <530B9221.6050409@guardianproject.info> <878ut0xprg.fsf@vigenere.g10code.de> Message-ID: <530BA67D.9010606@guardianproject.info> On 02/24/2014 02:41 PM, Werner Koch wrote: > On Mon, 24 Feb 2014 19:40, hans at guardianproject.info said: >> I see that the translation files are spread across 'gnupg' and 'libgpg-error', >> but the files generated from .po (.mo and .gmo?) don't seem to be installed >> anywhere. > > You might have missed them because they are renamed during instalaltion. > For example the de.po files from all packages will be installed below > > /usr/local/share/locale/de/LC_MESSAGES/ > > Thus after installing gnupg and libgpg-error you should have at least > theses file: > > /usr/local/share/locale/de/LC_MESSAGES/libgpg-error.mo > /usr/local/share/locale/de/LC_MESSAGES/gnupg2.mo > > "gnupg2" is used to avoid conflicts with transations from GnuPG-1. Is this new in 2.1? I'm looking at the Ubuntu package gnupg2 2.0.17 and it doesn't include any of those files. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From hans at guardianproject.info Mon Feb 24 23:37:54 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 24 Feb 2014 17:37:54 -0500 Subject: how to install the po translations on Android In-Reply-To: <530BA67D.9010606@guardianproject.info> References: <530B9221.6050409@guardianproject.info> <878ut0xprg.fsf@vigenere.g10code.de> <530BA67D.9010606@guardianproject.info> Message-ID: <530BC9C2.7040405@guardianproject.info> On 02/24/2014 03:07 PM, Hans-Christoph Steiner wrote: > > > On 02/24/2014 02:41 PM, Werner Koch wrote: >> On Mon, 24 Feb 2014 19:40, hans at guardianproject.info said: >>> I see that the translation files are spread across 'gnupg' and 'libgpg-error', >>> but the files generated from .po (.mo and .gmo?) don't seem to be installed >>> anywhere. >> >> You might have missed them because they are renamed during instalaltion. >> For example the de.po files from all packages will be installed below >> >> /usr/local/share/locale/de/LC_MESSAGES/ >> >> Thus after installing gnupg and libgpg-error you should have at least >> theses file: >> >> /usr/local/share/locale/de/LC_MESSAGES/libgpg-error.mo >> /usr/local/share/locale/de/LC_MESSAGES/gnupg2.mo >> >> "gnupg2" is used to avoid conflicts with transations from GnuPG-1. > > Is this new in 2.1? I'm looking at the Ubuntu package gnupg2 2.0.17 and it > doesn't include any of those files. It doesn't seem to be doing anything in the po dir. This is basically how its configured (minus cross-compiler stuff): ./configure --enable-static --host=arm-linux-androideabi Then: Making all in po make[3]: Entering directory `/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/libgpg-error/po' make[3]: Leaving directory `/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/libgpg-error/po' Making install in po make[2]: Entering directory `/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/libgpg-error/po' if test "libgpg-error" = "gettext-tools"; then \ /bin/mkdir -p /var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/share/gettext/po; \ for file in Makefile.in.in remove-potcdate.sin quot.sed boldquot.sed en at quot.header en at boldquot.header insert-header.sin Rules-quot Makevars.template; do \ /usr/bin/install -c -m 644 ./$file \ /var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/share/gettext/po/$file; \ done; \ for file in Makevars; do \ rm -f /var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/data/data/info.guardianproject.gpg/app_opt/share/gettext/po/$file; \ done; \ else \ : ; \ fi make[2]: Leaving directory `/var/lib/jenkins/workspace/gnupg-for-android-eighthave/external/libgpg-error/po' That test there is pretty strange. Why would libgpg-error only install its translations if the PACKAGE is called "gettext-tools"? .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From wk at gnupg.org Tue Feb 25 10:08:31 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 25 Feb 2014 10:08:31 +0100 Subject: how to install the po translations on Android In-Reply-To: <530BC9C2.7040405@guardianproject.info> (Hans-Christoph Steiner's message of "Mon, 24 Feb 2014 17:37:54 -0500") References: <530B9221.6050409@guardianproject.info> <878ut0xprg.fsf@vigenere.g10code.de> <530BA67D.9010606@guardianproject.info> <530BC9C2.7040405@guardianproject.info> Message-ID: <87vbw3wods.fsf@vigenere.g10code.de> On Mon, 24 Feb 2014 23:37, hans at guardianproject.info said: > That test there is pretty strange. Why would libgpg-error only install its > translations if the PACKAGE is called "gettext-tools"? That rule is only for the gettext package itself - not needed here and thus the dummy command. However, the install-data target depends on install-data- at USE_NLS@ and thus either the install-data-no or install-data-yes rules are run - depending on whether NLS has been enabled. Use grep USE_NLS config.status To see whether it has been enabled. If you don't know why it has been disabled, you need to check the config.log file. I guess that you have a config.site file somewhere or the envvar CONFIG_SITE pointing to such a file. This is commonly used to convey options used by all packages. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From hans at guardianproject.info Tue Feb 25 16:35:41 2014 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 25 Feb 2014 10:35:41 -0500 Subject: how to install the po translations on Android In-Reply-To: <87vbw3wods.fsf@vigenere.g10code.de> References: <530B9221.6050409@guardianproject.info> <878ut0xprg.fsf@vigenere.g10code.de> <530BA67D.9010606@guardianproject.info> <530BC9C2.7040405@guardianproject.info> <87vbw3wods.fsf@vigenere.g10code.de> Message-ID: <530CB84D.8080308@guardianproject.info> On 02/25/2014 04:08 AM, Werner Koch wrote: > On Mon, 24 Feb 2014 23:37, hans at guardianproject.info said: >> That test there is pretty strange. Why would libgpg-error only install its >> translations if the PACKAGE is called "gettext-tools"? > > That rule is only for the gettext package itself - not needed here and > thus the dummy command. However, the install-data target depends on > install-data- at USE_NLS@ and thus either the install-data-no or > install-data-yes rules are run - depending on whether NLS has been > enabled. Use > > grep USE_NLS config.status > > To see whether it has been enabled. If you don't know why it has been > disabled, you need to check the config.log file. I guess that you have > a config.site file somewhere or the envvar CONFIG_SITE pointing to such > a file. This is commonly used to convey options used by all packages. So it seems to be an issue related to cross-compiling, or maybe the Android NDK is missing some core functionality: checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge [snip] checking for GNU gettext in libc... no checking for iconv... no, consider installing GNU libiconv checking for GNU gettext in libintl... no checking whether to use NLS... no The gettext it is looking for is the C functions for loading the translations? That's my guess. libintl is not provided by Android. It might be possible to build the full GNU gettext for Android, but it might also be quite painful. Another option I'm considering is using libintl-lite or related fork: http://sourceforge.net/projects/libintl-lite/ https://github.com/j-jorge/libintl-lite .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 From chris.gilg at link-comm.com Tue Feb 25 23:14:45 2014 From: chris.gilg at link-comm.com (Chris) Date: Tue, 25 Feb 2014 22:14:45 +0000 (UTC) Subject: gpgme and libassuan problem. References: <87sirczm2f.fsf@vigenere.g10code.de> Message-ID: Chris link-comm.com> writes: > > > Must have been an oversight on my part. I rearranged the linker flags in > order according to the same command. I still get the same undefined > references messages. > I figured out the issue. There seems to be a problem with an older version of the Blackfin tool-chain that is causing me these issues. If I update to a newer version of the Blackfin tool-chain, everything builds and links correctly. From wk at gnupg.org Wed Feb 26 08:53:46 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 26 Feb 2014 08:53:46 +0100 Subject: how to install the po translations on Android In-Reply-To: <530CB84D.8080308@guardianproject.info> (Hans-Christoph Steiner's message of "Tue, 25 Feb 2014 10:35:41 -0500") References: <530B9221.6050409@guardianproject.info> <878ut0xprg.fsf@vigenere.g10code.de> <530BA67D.9010606@guardianproject.info> <530BC9C2.7040405@guardianproject.info> <87vbw3wods.fsf@vigenere.g10code.de> <530CB84D.8080308@guardianproject.info> Message-ID: <871tyqwbqt.fsf@vigenere.g10code.de> On Tue, 25 Feb 2014 16:35, hans at guardianproject.info said: > The gettext it is looking for is the C functions for loading the translations? yes. > That's my guess. libintl is not provided by Android. It might be possible to > build the full GNU gettext for Android, but it might also be quite painful. I am pretty sure that this is possible. Bruno's code is highly portable. > Another option I'm considering is using libintl-lite or related fork: I don't known. But there is another option. For historicial reasons GnuPG for Windows uses its own gettext implementaion. It is part of libgpg-error but only build and used under Windows - should be easy to modify it to work on all OSes. There are some limitations in the code; for example the mo files must be utf-8 encoded (which is easy to achieve) and only the additional Germanic plural is supported. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.