From delroth at gmail.com Sat Apr 6 16:33:26 2019 From: delroth at gmail.com (Pierre Bourdon) Date: Sat, 6 Apr 2019 16:33:26 +0200 Subject: [pinentry PATCH] configure: use AM_PROG_AR to find a lib archiver Message-ID: In some environments, the default "ar" might not be present in $PATH. For example, when cross-compiling, it is common to only have the target toolchain visible, with names prefixed by the target triple. Signed-off-by: Pierre Bourdon --- configure.ac | 1 + 1 file changed, 1 insertion(+) diff --git a/configure.ac b/configure.ac index a4d54da..a2845dd 100644 --- a/configure.ac +++ b/configure.ac @@ -77,6 +77,7 @@ AM_MISSING_PROG(AUTOCONF, autoconf, $missing_dir) AM_MISSING_PROG(AUTOMAKE, automake, $missing_dir) AM_MISSING_PROG(AUTOHEADER, autoheader, $missing_dir) AM_MISSING_PROG(MAKEINFO, makeinfo, $missing_dir) +AM_PROG_AR AC_PROG_CC AC_PROG_CPP AC_PROG_INSTALL -- 2.19.2 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-configure-use-AM_PROG_AR-to-find-a-lib-archiver.patch Type: text/x-patch Size: 936 bytes Desc: not available URL: From frederick888 at tsundere.moe Tue Apr 9 19:00:01 2019 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Wed, 10 Apr 2019 03:00:01 +1000 Subject: Suggestion needed: fix T3416 gpg should select available signing key on card (even with -u option) Message-ID: Hi guys, I encountered the issue of T3416 gpg should select available signing key on card (even with -u option) recently and I've been working on a fix for it. But since I've got little knowledge about GPG internals, it'd be nice if I can have some feedback and suggestions from you and maybe get the changes merged if they do make sense :) Basically what I did was simply copying the code about smart card from build_sk_list in skclist.c to finish_lookup in getkey.c so that cards are always checked unless a user specifies a subkey suffixed with an exclamation mark (patch based on v2.2.15): diff --git a/g10/getkey.c b/g10/getkey.c index c4afe4510..0f9839f73 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -3443,8 +3443,28 @@ finish_lookup (kbnode_t keyblock, unsigned int req_usage, int want_exact, { kbnode_t nextk; int n_subkeys = 0; int n_revoked_or_expired = 0; + struct agent_card_info_s card_info; + gpg_error_t card_err = 0; + int pk_card = 0; + int latest_key_card = 0; + char fpr[MAX_FINGERPRINT_LEN]; + if (!foundk) + { + /* Check if a card is available. If any, use the key as a hint. */ + char *serialno; + memset (&card_info, 0, sizeof(card_info)); + card_err = agent_scd_serialno (&serialno, NULL); + if (!card_err) + { + xfree (serialno); + card_err = agent_scd_getattr ("KEY-FPR", &card_info); + if (card_err) + log_error ("error retrieving key fingerprint from card: %s\n", + gpg_strerror (card_err)); + } + } /* Either start a loop or check just this one subkey. */ for (k = foundk ? foundk : keyblock; k; k = nextk) { @@ -3513,12 +3533,19 @@ finish_lookup (kbnode_t keyblock, unsigned int req_usage, int want_exact, /* In case a key has a timestamp of 0 set, we make sure that it is used. A better change would be to compare ">=" but that might also change the selected keys and is as such a more intrusive change. */ - if (pk->timestamp > latest_date || (!pk->timestamp && !latest_date)) + fingerprint_from_pk(pk, fpr, NULL); + if (!(foundk || card_err)) + pk_card = (card_info.fpr1valid && !strncmp(card_info.fpr1, fpr, MAX_FINGERPRINT_LEN)) + || (card_info.fpr2valid && !strncmp(card_info.fpr2, fpr, MAX_FINGERPRINT_LEN)) + || (card_info.fpr3valid && !strncmp(card_info.fpr3, fpr, MAX_FINGERPRINT_LEN)); + if ((pk->timestamp > latest_date || (!pk->timestamp && !latest_date)) + && (pk_card || !latest_key_card)) { latest_date = pk->timestamp; latest_key = k; + latest_key_card = pk_card; } } if (n_subkeys == n_revoked_or_expired && r_flags) *r_flags |= LOOKUP_ALL_SUBKEYS_EXPIRED; diff --git a/g10/gpgv.c b/g10/gpgv.c index c142cef86..c01d66425 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -620,8 +620,16 @@ agent_scd_getattr (const char *name, struct agent_card_info_s *info) (void)name; (void)info; return 0; } + +int +agent_scd_serialno (char **r_serialno, const char *demand) +{ + (void)r_serialno; + (void)demand; + return 0; +} #endif /* ENABLE_CARD_SUPPORT */ /* We do not do any locking, so use these stubs here */ void diff --git a/g10/test-stubs.c b/g10/test-stubs.c index 1e1363266..e53e49a78 100644 --- a/g10/test-stubs.c +++ b/g10/test-stubs.c @@ -383,8 +383,16 @@ agent_scd_getattr (const char *name, struct agent_card_info_s *info) (void)name; (void)info; return 0; } + +int +agent_scd_serialno (char **r_serialno, const char *demand) +{ + (void)r_serialno; + (void)demand; + return 0; +} #endif /* ENABLE_CARD_SUPPORT */ /* We do not do any locking, so use these stubs here */ void Then it seems that there's actually no need to check smart cards in build_sk_list as the program goes through finish_lookup anyway, so to remove those codes: diff --git a/g10/skclist.c b/g10/skclist.c index 78890dc42..8bc1300b6 100644 --- a/g10/skclist.c +++ b/g10/skclist.c @@ -128,29 +128,14 @@ build_sk_list (ctrl_t ctrl, are in batch mode, die. */ if (!locusr) /* No user ids given - use the card key or the default key. */ { - struct agent_card_info_s info; PKT_public_key *pk; - char *serialno; - memset (&info, 0, sizeof(info)); pk = xmalloc_clear (sizeof *pk); pk->req_usage = use; - /* Check if a card is available. If any, use the key as a hint. */ - err = agent_scd_serialno (&serialno, NULL); - if (!err) - { - xfree (serialno); - err = agent_scd_getattr ("KEY-FPR", &info); - if (err) - log_error ("error retrieving key fingerprint from card: %s\n", - gpg_strerror (err)); - } - - err = get_seckey_default_or_card (ctrl, pk, - info.fpr1valid? info.fpr1 : NULL, 20); + err = get_seckey_default (ctrl, pk); if (err) { free_public_key (pk); pk = NULL; I tested these patches locally and everything seemed to work fine. But please do let me know if there are any problems and it'd be great if you can help me improve them. Thanks. PS: Sorry I turned on HTML by mistake in my last email. -- Best Regards, Frederick Zhang Email: frederick888 at tsundere.moe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From frederick888 at tsundere.moe Tue Apr 9 17:22:14 2019 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Wed, 10 Apr 2019 01:22:14 +1000 Subject: Suggestion needed: fix T3416 gpg should select available signing key on card (even with -u option) Message-ID: Hi guys, I encountered the issue of T3416 gpg should select available signing key on card (even with -u option) recently and I've been working on a fix for it. But since I've got little knowledge about GPG internals, it'd be nice if I can have some feedback and suggestions from you and maybe get the changes merged if they do make sense :) Basically what I did was simply copying the code about smart card from build_sk_list in skclist.c to finish_lookup in getkey.c so that cards are always checked unless a user specifies a subkey suffixed with an exclamation mark (patch based on v2.2.15): diff --git a/g10/getkey.c b/g10/getkey.c index c4afe4510..0f9839f73 100644 --- a/g10/getkey.c +++ b/g10/getkey.c @@ -3443,8 +3443,28 @@ finish_lookup (kbnode_t keyblock, unsigned int req_usage, int want_exact, ???? { ?????? kbnode_t nextk; ?????? int n_subkeys = 0; ?????? int n_revoked_or_expired = 0; +????? struct agent_card_info_s card_info; +????? gpg_error_t card_err = 0; +????? int pk_card = 0; +????? int latest_key_card = 0; +????? char fpr[MAX_FINGERPRINT_LEN]; +????? if (!foundk) +????????? { +????????????? /* Check if a card is available.? If any, use the key as a hint.? */ +????????????? char *serialno; +????????????? memset (&card_info, 0, sizeof(card_info)); +????????????? card_err = agent_scd_serialno (&serialno, NULL); +????????????? if (!card_err) +??????????????? { +????????????????? xfree (serialno); +????????????????? card_err = agent_scd_getattr ("KEY-FPR", &card_info); +????????????????? if (card_err) +??????????????????? log_error ("error retrieving key fingerprint from card: %s\n", +??????????????????????????? gpg_strerror (card_err)); +??????????????? } +????????? } ? ?????? /* Either start a loop or check just this one subkey.? */ ?????? for (k = foundk ? foundk : keyblock; k; k = nextk) ???? { @@ -3513,12 +3533,19 @@ finish_lookup (kbnode_t keyblock, unsigned int req_usage, int want_exact, ???? ? /* In case a key has a timestamp of 0 set, we make sure ???? ???? that it is used.? A better change would be to compare ???? ???? ">=" but that might also change the selected keys and ???? ???? is as such a more intrusive change.? */ -??? ? if (pk->timestamp > latest_date || (!pk->timestamp && !latest_date)) +????????? fingerprint_from_pk(pk, fpr, NULL); +????????? if (!(foundk || card_err)) +????????????? pk_card = (card_info.fpr1valid && !strncmp(card_info.fpr1, fpr, MAX_FINGERPRINT_LEN)) +????????????????? || (card_info.fpr2valid && !strncmp(card_info.fpr2, fpr, MAX_FINGERPRINT_LEN)) +????????????????? || (card_info.fpr3valid && !strncmp(card_info.fpr3, fpr, MAX_FINGERPRINT_LEN)); +????????? if ((pk->timestamp > latest_date || (!pk->timestamp && !latest_date)) +????????????????? && (pk_card || !latest_key_card)) ???? ??? { ???? ????? latest_date = pk->timestamp; ???? ????? latest_key = k; +??? ????? latest_key_card = pk_card; ???? ??? } ???? } ?????? if (n_subkeys == n_revoked_or_expired && r_flags) ???????? *r_flags |= LOOKUP_ALL_SUBKEYS_EXPIRED; diff --git a/g10/gpgv.c b/g10/gpgv.c index c142cef86..c01d66425 100644 --- a/g10/gpgv.c +++ b/g10/gpgv.c @@ -620,8 +620,16 @@ agent_scd_getattr (const char *name, struct agent_card_info_s *info) ?? (void)name; ?? (void)info; ?? return 0; ?} + +int +agent_scd_serialno (char **r_serialno, const char *demand) +{ +? (void)r_serialno; +? (void)demand; +? return 0; +} ?#endif /* ENABLE_CARD_SUPPORT */ ? ?/* We do not do any locking, so use these stubs here */ ?void diff --git a/g10/test-stubs.c b/g10/test-stubs.c index 1e1363266..e53e49a78 100644 --- a/g10/test-stubs.c +++ b/g10/test-stubs.c @@ -383,8 +383,16 @@ agent_scd_getattr (const char *name, struct agent_card_info_s *info) ?? (void)name; ?? (void)info; ?? return 0; ?} + +int +agent_scd_serialno (char **r_serialno, const char *demand) +{ +? (void)r_serialno; +? (void)demand; +? return 0; +} ?#endif /* ENABLE_CARD_SUPPORT */ ? ?/* We do not do any locking, so use these stubs here */ ?void Then it seems that there's actually no need to check smart cards in build_sk_list as the program goes through finish_lookup anyway, so to remove those codes: diff --git a/g10/skclist.c b/g10/skclist.c index 78890dc42..8bc1300b6 100644 --- a/g10/skclist.c +++ b/g10/skclist.c @@ -128,29 +128,14 @@ build_sk_list (ctrl_t ctrl, ????? are in batch mode, die.? */ ? ?? if (!locusr) /* No user ids given - use the card key or the default key.? */ ???? { -????? struct agent_card_info_s info; ?????? PKT_public_key *pk; -????? char *serialno; ? -????? memset (&info, 0, sizeof(info)); ?????? pk = xmalloc_clear (sizeof *pk); ?????? pk->req_usage = use; ? -????? /* Check if a card is available.? If any, use the key as a hint.? */ -????? err = agent_scd_serialno (&serialno, NULL); -????? if (!err) -??????? { -????????? xfree (serialno); -????????? err = agent_scd_getattr ("KEY-FPR", &info); -????????? if (err) -??????????? log_error ("error retrieving key fingerprint from card: %s\n", -?????????????????????? gpg_strerror (err)); -??????? } - -????? err = get_seckey_default_or_card (ctrl, pk, -??????????????????????????????????????? info.fpr1valid? info.fpr1 : NULL, 20); +????? err = get_seckey_default (ctrl, pk); ?????? if (err) ???? { ???? ? free_public_key (pk); ???? ? pk = NULL; I tested these patches locally and everything seemed to work fine. But please do let me know if there are any problems and it'd be great if you can help me improve them. Thanks. -- Best Regards, Frederick Zhang Email: frederick888 at tsundere.moe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From robbat2 at gentoo.org Tue Apr 9 19:48:16 2019 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Tue, 9 Apr 2019 10:48:16 -0700 Subject: [PATCH] g10: support --quiet for --send-key Message-ID: <20190409174816.18330-1-robbat2@gentoo.org> The --recv-key command supports --quiet, but --send-key does not. Add support for it for parity and better scripting. Signed-off-by: Robin H. Johnson --- g10/keyserver.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/g10/keyserver.c b/g10/keyserver.c index 66900f7a9..e5fc011c0 100644 --- a/g10/keyserver.c +++ b/g10/keyserver.c @@ -1814,9 +1814,10 @@ keyserver_put (ctrl_t ctrl, strlist_t keyspecs) log_error (_("skipped \"%s\": %s\n"), kspec->d, gpg_strerror (err)); else { - log_info (_("sending key %s to %s\n"), - keystr (keyblock->pkt->pkt.public_key->keyid), - ksurl?ksurl:"[?]"); + if (!opt.quiet) + log_info (_("sending key %s to %s\n"), + keystr (keyblock->pkt->pkt.public_key->keyid), + ksurl?ksurl:"[?]"); err = gpg_dirmngr_ks_put (ctrl, data, datalen, keyblock); release_kbnode (keyblock); -- 2.21.0 From gniibe at fsij.org Wed Apr 10 01:58:39 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 10 Apr 2019 08:58:39 +0900 Subject: Suggestion needed: fix T3416 gpg should select available signing key on card (even with -u option) In-Reply-To: References: Message-ID: <87tvf6loi8.fsf@iwagami.gniibe.org> Frederick Zhang via Gnupg-devel wrote: > I encountered the issue of T3416 gpg should select available signing key > on card (even with -u option) recently and > I've been working on a fix for it. But since I've got little knowledge > about GPG internals, it'd be nice if I can have some feedback and > suggestions from you and maybe get the changes merged if they do make > sense :) Please describe your problem, what you need/want, what to be achieved, etc., at first. It is more helpful than a patch. In my opinion, your approach of changing key search algorithm (finish_lookup) looks not good, because the impact is larger. -- From frederick888 at tsundere.moe Wed Apr 10 09:38:46 2019 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Wed, 10 Apr 2019 17:38:46 +1000 Subject: Suggestion needed: fix T3416 gpg should select available signing key on card (even with -u option) In-Reply-To: <87tvf6loi8.fsf@iwagami.gniibe.org> References: <87tvf6loi8.fsf@iwagami.gniibe.org> Message-ID: <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> The problem I had was rather similar as T3416. I've got 2 YubiKeys loaded with two sets of signing/authentication subkeys. One of them is supposed to be a backup key and they should be able to be used interchangeably without any hiccup. For example, here I've listed the subkeys I have, and the two YubiKeys, i.e. #1 and #2, store different keys respectively: sec# rsa4096/0x0D8BC11D 2019-01-23 [SC] [expires: 2020-01-23] ssb> rsa4096/0x716B1FC5 2019-01-23 [E] [expires: 2020-01-23] Card serial no. = 0006 00000001 ssb> rsa4096/0x361BE1AE 2019-01-23 [S] [expires: 2020-01-23] Card serial no. = 0006 00000001 ssb> rsa4096/0x964E63BD 2019-03-26 [A] [expires: 2020-01-23] Card serial no. = 0006 00000001 ssb> rsa4096/0x5FF72AA3 2019-03-27 [S] [expires: 2020-01-23] Card serial no. = 0006 00000002 ssb> rsa4096/0x16A376D9 2019-03-27 [A] [expires: 2020-01-23] Card serial no. = 0006 00000002 Now the problem is, when I'm using #1 and trying to sign something, e.g. git commit, because git specifies `-u` and the signing key 0x5FF72AA3 in #2 is newer, GPG asks me to plug in #2 although it should be able to sign the commit using 0x361BE1AE in #1 just fine. So basically I'd expect the same behaviour as what GPG currently does when no `-u` option is specified, where it prefers the key that's currently available either locally on disk or from a smart card (oops, just realised that I didn't take the on-disk keys into account in my patch). And only when none of those private keys are available, it asks the user to plug in the smart card which holds the latest subkey. But even with this logic implemented, it still does not fully resolve my problem, because I don't want to have different encryption subkeys on my YubiKeys, which would confuse others and require me to always have both cards to decrypt my files. Currently "keytocard" replaces the keygrip with a shadow key (which I don't think works pretty intuitively in case of multiple smart cards, as it requires users to manually back up the subkey beforehand to transfer the same key to multiple cards) that associates the subkey with a smart card, e.g. #1 above. So now every time I plug in #2 I have to manually delete the shadow key and somehow trigger "agent_card_learn" to use the same encryption subkey on #2, otherwise GPG would ask me to plug in #1, and vice versa. I can somewhat live with this problem as I've got only 2 cards. But consider the scenario that vsrinu26f mentioned in T3416 where an admin distributes a bunch of smart cards with the same subkey to users, things could really get out of hand. A quick solution I've got in mind would be allowing agent_card_learn to overwrite existing shadow keys, but modifying files silently in the background doesn't sound quite safe. Another solution, which I don't know whether is actually feasible or not, is: 1. storing different shadow keys for different smart cards, e.g. using HEX_KEYGRIP-HEX_SMART_CART_SERIALNO.key as the file name 2. leaving the original keygrip untouched after "keytocard" If this is possible, not only it would allow users to track which key is stored in multiple smart cards and use whichever card they want, but also make the process of duplicating smart cards much smoother. On 10/4/19 9:58 am, NIIBE Yutaka wrote: > Frederick Zhang via Gnupg-devel wrote: >> I encountered the issue of T3416 gpg should select available signing key >> on card (even with -u option) recently and >> I've been working on a fix for it. But since I've got little knowledge >> about GPG internals, it'd be nice if I can have some feedback and >> suggestions from you and maybe get the changes merged if they do make >> sense :) > > Please describe your problem, what you need/want, what to be achieved, > etc., at first. It is more helpful than a patch. > > In my opinion, your approach of changing key search algorithm > (finish_lookup) looks not good, because the impact is larger. > -- Best Regards, Frederick Zhang Email: frederick888 at tsundere.moe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Apr 10 11:55:50 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 10 Apr 2019 11:55:50 +0200 Subject: Storing key on multiple smartcards In-Reply-To: <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> Message-ID: <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> (This went wrong! For some reason, gnupg-devel had dropped from the recipients while I was writing the message. I must have accidentally pressed some key or mouse button. I noticed this and added gnupg-users to the recipients instead of the intended gnupg-devel. Here is the message again on the right list) I agree that GnuPG would benefit from preferring keys that are available, both in the sense of different subkeys and different smartcards with copies of the same subkey, in the sense you describe. But let me pick out one detail you mentioned that is a different issue. On 10/04/2019 09:38, Frederick Zhang via Gnupg-devel wrote: > Currently "keytocard" replaces the keygrip with a shadow key (which I > don't think works pretty intuitively in case of multiple smart cards, > as it requires users to manually back up the subkey beforehand to > transfer the same key to multiple cards) It's less difficult than that. After a "keytocard", simply exit the --edit-key interaction without saving, and the key will still be on disk as well. So use "quit" or Ctrl-D rather than "save", and confirm that you wish to exit without saving changes. Not really intuitive, but less bothersome than backups and restores. I think maybe "keytocard" should have an option to just leave it on disk as well. And then you can just insert all your smartcards you want the key on and "keytocard" them one after the other without exiting the --edit-key menu. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From frederick888 at tsundere.moe Wed Apr 10 16:22:28 2019 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Thu, 11 Apr 2019 00:22:28 +1000 Subject: Storing key on multiple smartcards In-Reply-To: <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> Message-ID: Well, while it's good to know that keytocard does not update the file immediately, I genuinely didn't expect that keytocard would replace the keygrip in the first place (although it's clearly stated in man page, yeah, lazy me :P). No idea whether I'm the one who's got a weird mindset, I believed it meant "copying the key to a smart card and store some metadata about the card somewhere else" without the slightest doubt. I actually kinda want to blame the setup instruction from Yubico . They suggest having a backup card but mentioned absolutely nothing about the behaviour of keytocard, and it clearly says "enter y (yes)" to save the changes after "quit"... Only when I was to copy the same keys to the backup card after done configuring the primary one, I realised I may have screwed up. Thank goodness I backed up the keys when I started using GPG, but the authentication keys I generated during the setup are never gonna settle themselves in a different nest :'( So I strongly agree keytocard should, even by default, leave the originals untouched, and perhaps instruct users to move the keygrip to a safe place afterwards. On 10/4/19 7:55 pm, Peter Lebbing wrote: > (This went wrong! For some reason, gnupg-devel had dropped from the > recipients while I was writing the message. I must have accidentally > pressed some key or mouse button. I noticed this and added > gnupg-users to the recipients instead of the intended gnupg-devel. Here > is the message again on the right list) > > I agree that GnuPG would benefit from preferring keys that are > available, both in the sense of different subkeys and different > smartcards with copies of the same subkey, in the sense you describe. > But let me pick out one detail you mentioned that is a different issue. > > On 10/04/2019 09:38, Frederick Zhang via Gnupg-devel wrote: >> Currently "keytocard" replaces the keygrip with a shadow key (which I >> don't think works pretty intuitively in case of multiple smart cards, >> as it requires users to manually back up the subkey beforehand to >> transfer the same key to multiple cards) > > It's less difficult than that. After a "keytocard", simply exit the > --edit-key interaction without saving, and the key will still be > on disk as well. So use "quit" or Ctrl-D rather than "save", and > confirm that you wish to exit without saving changes. > > Not really intuitive, but less bothersome than backups and restores. I > think maybe "keytocard" should have an option to just leave it on disk > as well. And then you can just insert all your smartcards you want the > key on and "keytocard" them one after the other without exiting the > --edit-key menu. > > HTH, > > Peter. > -- Best Regards, Frederick Zhang Email: frederick888 at tsundere.moe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From peter at digitalbrains.com Wed Apr 10 16:42:39 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 10 Apr 2019 16:42:39 +0200 Subject: Storing key on multiple smartcards In-Reply-To: References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> Message-ID: <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> On 10/04/2019 16:22, Frederick Zhang wrote: > So I strongly agree keytocard should, even by default, leave the > originals untouched, and perhaps instruct users to move the keygrip to a > safe place afterwards. People move their keys to a card because they do not want the key to be on disk for whatever reason. Leaving them on the disk by default might be surprising to them and potentially harmful. I'd rather propose that the default is that "keytocard" shows a warning message: | Warning: moving the key to card will remove it from disk. It is not | possible to get the private key out of the card again. If this is not | what is intended, supply the '--keep' option to 'keytocard' to keep the | key stored on disk as well. Continue? (y/N) And obviously that option needs to be implemented as well. This is just a first setup for the precise message to convey my intention. Everybody should have a backup of their encryption key, but still, throwing it away when the user might not expect it on 'keytocard' might be a bad idea (this is what we do now!). Primary keys are not quite as bad as that, but still. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From manowar at altlinux.org Wed Apr 10 19:56:48 2019 From: manowar at altlinux.org (Paul Wolneykien) Date: Wed, 10 Apr 2019 20:56:48 +0300 Subject: GOST support in GnuPG In-Reply-To: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org> References: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org> Message-ID: 19.03.2019 12:40, Paul Wolneykien ?????: > > Hi! > > I'm working on adding the GOST (Russian EC crypto) support to GnuPG. > Currently I have a version where sign/verify and encrypt/decrypt > operations function properly (with some restrictions) in both PGP and > S/MIME modes. I want to know what is the official procedure to include > such a new functionality in GnuPG? Hi again. My question is still unanswered. Are there some guidelines about adding new key types, curves, ciphers, etc. to GnuPG I should keep to when making such changes? > My current set of patches are as follows: > > * GOST cases in g10, sm, common and the agent: > https://packages.altlinux.org/en/sisyphus/srpms/gnupg2/patches/gnupg2-2.2.10-gost-1.0.0.patch > * workaround for multi-URL CRLs in dirmngr: > https://packages.altlinux.org/en/sisyphus/srpms/gnupg2/patches/gnupg2-2.2.10-issuers-1.0.0.patch > * GOST VKO algorithm in Libgcrypt: > https://packages.altlinux.org/en/sisyphus/srpms/libgcrypt/patches/libgcrypt-1.8.3-vko-1.0.0.patch > * GOST ASN.1 in Libksba: > https://packages.altlinux.org/en/sisyphus/srpms/libksba/patches/libksba-1.3.6-gost-1.0.0.patch From peter at digitalbrains.com Wed Apr 10 20:28:03 2019 From: peter at digitalbrains.com (Peter Lebbing) Date: Wed, 10 Apr 2019 20:28:03 +0200 Subject: GOST support in GnuPG In-Reply-To: References: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org> Message-ID: <080252dd-765a-bbe1-e7ed-87b6ffeaa10b@digitalbrains.com> On 10/04/2019 19:56, Paul Wolneykien wrote: > Hi again. My question is still unanswered. Are there some guidelines > about adding new key types, curves, ciphers, etc. to GnuPG I should keep > to when making such changes? Well, all I can do is point you to this year-old message on gnupg-users: I think the guideline is that it should be in a proposed new OpenPGP standard first, but I'm not a developer. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Apr 10 20:42:09 2019 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Apr 2019 20:42:09 +0200 Subject: GOST support in GnuPG In-Reply-To: (Paul Wolneykien's message of "Wed, 10 Apr 2019 20:56:48 +0300") References: <707d2dbe-ddc7-b553-c960-a2ede333697e@altlinux.org> Message-ID: <87mukx1z3y.fsf@wheatstone.g10code.de> Hi! On Wed, 10 Apr 2019 20:56, manowar at altlinux.org said: > Hi again. My question is still unanswered. Are there some guidelines > about adding new key types, curves, ciphers, etc. to GnuPG I should keep > to when making such changes? Aside from doc/HACKING there are no fixed rules. However adding new algorithms etc requires that they are part of the implemented standard and further we need to see whether it makese sense to implement and _maintain_ them. >> My current set of patches are as follows: I briefly looked at your patches but concluded that this is a log of new code for just another algorithm. Thus your patches requires a closer look. Right now I do not have the time for this and unless there is a reason to tag it at high priority, I doubt that I can look at it in the next weeks. A reason for this might be that we can foster deployment of OpenPGP in certain domains. However, if it turns out that GOST as been weakened on purpose, there is no chance that it can part of _gpg_ (ie. to OpenPGP). Shalom-Salam, Werner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ilf at zeromail.org Thu Apr 18 09:21:48 2019 From: ilf at zeromail.org (ilf) Date: Thu, 18 Apr 2019 09:21:48 +0200 Subject: increase the default RSA key size to 3072 bits Message-ID: <20190418072148.GN1226@zeromail.org> OpenSSH 8.0 was released yesterday, one change being: > * ssh-keygen(1): Increase the default RSA key size to 3072 bits, > following NIST Special Publication 800-57's guidance for a > 128-bit equivalent symmetric security level. This points to https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf#page=66 GnuPG 2.2.15 still has RSA 2048 as default, although Debian (and Debian-based distros) ship with 3072 as default. I would be in favor of following OpenSSH and increasing the default RSA key size to 3072 bits. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From smueller at chronox.de Thu Apr 18 09:29:48 2019 From: smueller at chronox.de (Stephan Mueller) Date: Thu, 18 Apr 2019 09:29:48 +0200 Subject: increase the default RSA key size to 3072 bits In-Reply-To: <20190418072148.GN1226@zeromail.org> References: <20190418072148.GN1226@zeromail.org> Message-ID: <3328077.qL0Gj5JxOq@tauon.chronox.de> Am Donnerstag, 18. April 2019, 09:21:48 CEST schrieb ilf: Hi, > > This points to > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pd > f#page=66 > > GnuPG 2.2.15 still has RSA 2048 as default, although Debian (and > Debian-based distros) ship with 3072 as default. > > I would be in favor of following OpenSSH and increasing the default RSA > key size to 3072 bits. Just FYI: 4096 will be allowed very soon. Ciao Stephan From frederick888 at tsundere.moe Thu Apr 18 09:47:04 2019 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Thu, 18 Apr 2019 17:47:04 +1000 Subject: Storing key on multiple smartcards In-Reply-To: <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> Message-ID: Hi NIIBE, May I know what your thoughts are on this issue? I understand my changes to finish_lookup seem to have some unnecessary impacts on other logic, e.g. public key query, so maybe we should tweak the current build_sk_list to detect smart cards regardless of locusr? And what did you think of my "different keygrips for different cards" solution for the "same subkey on multiple cards" problem? Did it sound good to you? By the way, I reckon Peter has made some solid points about the warning message and the additional option for keytocard command. Do you think we should get this implemented first? On 11/4/19 12:42 am, Peter Lebbing wrote: > On 10/04/2019 16:22, Frederick Zhang wrote: >> So I strongly agree keytocard should, even by default, leave the >> originals untouched, and perhaps instruct users to move the keygrip to a >> safe place afterwards. > > People move their keys to a card because they do not want the key to be > on disk for whatever reason. Leaving them on the disk by default might > be surprising to them and potentially harmful. > > I'd rather propose that the default is that "keytocard" shows a warning > message: > > | Warning: moving the key to card will remove it from disk. It is not > | possible to get the private key out of the card again. If this is not > | what is intended, supply the '--keep' option to 'keytocard' to keep the > | key stored on disk as well. Continue? (y/N) > > And obviously that option needs to be implemented as well. This is just > a first setup for the precise message to convey my intention. > > Everybody should have a backup of their encryption key, but still, > throwing it away when the user might not expect it on 'keytocard' might > be a bad idea (this is what we do now!). Primary keys are not quite as > bad as that, but still. > > HTH, > > Peter. > -- Best Regards, Frederick Zhang Email: frederick888 at tsundere.moe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ilf at zeromail.org Thu Apr 18 10:12:44 2019 From: ilf at zeromail.org (ilf) Date: Thu, 18 Apr 2019 10:12:44 +0200 Subject: increase the default RSA key size to 3072 bits In-Reply-To: <3328077.qL0Gj5JxOq@tauon.chronox.de> References: <20190418072148.GN1226@zeromail.org> <3328077.qL0Gj5JxOq@tauon.chronox.de> Message-ID: <20190418081243.GO1226@zeromail.org> Stephan Mueller: > Just FYI: 4096 will be allowed very soon. What do you mean? Who will "allow" 4096? Both OpenSSH and GnuPG already allow creating 4096 RSA keys. The question is about the default value. -- ilf If you upload your address book to "the cloud", I don't want to be in it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From smueller at chronox.de Thu Apr 18 10:24:37 2019 From: smueller at chronox.de (Stephan Mueller) Date: Thu, 18 Apr 2019 10:24:37 +0200 Subject: increase the default RSA key size to 3072 bits In-Reply-To: <20190418081243.GO1226@zeromail.org> References: <20190418072148.GN1226@zeromail.org> <3328077.qL0Gj5JxOq@tauon.chronox.de> <20190418081243.GO1226@zeromail.org> Message-ID: <4192947.2oQnfk5Hvs@tauon.chronox.de> Am Donnerstag, 18. April 2019, 10:12:44 CEST schrieb ilf: > Stephan Mueller: > > Just FYI: 4096 will be allowed very soon. > > What do you mean? Who will "allow" 4096? NIST plans to allow it with a new FIPS 140-2 IG > Both OpenSSH and GnuPG already allow creating 4096 RSA keys. The > question is about the default value. I am just airing that for consideration what the default may be. Ciao Stephan From gniibe at fsij.org Fri Apr 19 03:44:49 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 19 Apr 2019 10:44:49 +0900 Subject: Storing key on multiple smartcards In-Reply-To: References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> Message-ID: <87zhomg44u.fsf@iwagami.gniibe.org> Hello, I was not able to catch up, because I didn't receive Peter's two messages on April 10th, for some reason. I am reading those messages in the archive. Frederick Zhang wrote: > May I know what your thoughts are on this issue? I understand my changes > to finish_lookup seem to have some unnecessary impacts on other logic, > e.g. public key query, so maybe we should tweak the current > build_sk_list to detect smart cards regardless of locusr? > > And what did you think of my "different keygrips for different cards" > solution for the "same subkey on multiple cards" problem? Did it sound > good to you? > > By the way, I reckon Peter has made some solid points about the warning > message and the additional option for keytocard command. Do you think we > should get this implemented first? Sorry, I can't understand how your patch solves your particular problem. Let me focus on "same subkey on multiple cards" problem. IIUC, it is related to how we can consider an identity of a card and how we manage its raw key materials inside. (I think that it is more than "UI improvement" issue.) There is an assumption in the current implementation of gpg-agent, a key material can be on disk or in a single card. Our discussion is how we can relax this assumption. Once, I had a practice to have multiple cards with same serial number, so that I worked around the situation like you. Obviously, this violates an assumption (perhaps, very important one), of smartcard administration. At least, it can't be recommended. Perhaps, better approach would be using a serial number only as a hint, extending keygrip-centric approach of gpg-agent. It would be good to administrate the hint information editable by user. Showing the serial number to ask insertion of a card... is not helpful so much to a user. It is more helpful when a user can name the card by some nickname. For warning message at keytocard command, I think that Peter's suggestion makes sense, but please don't mix separate things. It is related somehow, but I think it is better to be handled seperately. -- From dkg at fifthhorseman.net Fri Apr 19 15:50:13 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Apr 2019 09:50:13 -0400 Subject: increase the default RSA key size to 3072 bits In-Reply-To: <20190418072148.GN1226@zeromail.org> References: <20190418072148.GN1226@zeromail.org> Message-ID: <87o952xfxm.fsf@fifthhorseman.net> On Thu 2019-04-18 09:21:48 +0200, ilf wrote: > OpenSSH 8.0 was released yesterday, one change being: > >> * ssh-keygen(1): Increase the default RSA key size to 3072 bits, >> following NIST Special Publication 800-57's guidance for a >> 128-bit equivalent symmetric security level. > > This points to > https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf#page=66 > > GnuPG 2.2.15 still has RSA 2048 as default, although Debian (and > Debian-based distros) ship with 3072 as default. > > I would be in favor of following OpenSSH and increasing the default RSA > key size to 3072 bits. GnuPG master already defaults RSA keys to 3072 bits, and debian has been shipping this as the default in unstable since September 2017 (version 2.2.0-2), and in stable itself since October 2018 (version 2.1.18-8~deb9u3). I've heard no complaints about it. the modern version of gpgsm has shipped upstream with 3072-bit RSA defaults since 2.2.14 (2019-03-19). So the only holdout and 2048-bit RSA is the modern version of gpg upstream. I agree that it makes sense to do this on the 2.2 branch. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Apr 19 16:21:49 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Apr 2019 10:21:49 -0400 Subject: [PATCH] doc: clarify dirmngr use-tor documentation Message-ID: <20190419142149.8679-1-dkg@fifthhorseman.net> * doc/dirmngr.texi: Correct the documentation, since use-tor should not have anything to do with gpg-agent. -- I'm reluctant to push this documentation fix directly because i confess i still don't have a good mental model of how dirmngr is supposed to interact automatically with tor, so maybe the original documentation is right and i'm still just misunderstanding it. Even if this doc fix is correct, as a user i'm baffled by why reloading dirmngr wouldn't allow me to clear --use-tor. Does that mean i just need to restart dirmngr to clear --use-tor, instead of reloading? Is that a deliberate design decision, or an accident of implementation? If it's deliberate, what do i (as a user) gain from that design? --- doc/dirmngr.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/dirmngr.texi b/doc/dirmngr.texi index f5910a884..a1873b501 100644 --- a/doc/dirmngr.texi +++ b/doc/dirmngr.texi @@ -251,7 +251,7 @@ The option @option{--use-tor} switches Dirmngr and thus GnuPG into ``Tor mode'' to route all network access via Tor (an anonymity network). Certain other features are disabled in this mode. The effect of @option{--use-tor} cannot be overridden by any other command -or even be reloading gpg-agent. The use of @option{--no-use-tor} +or even by reloading dirmngr. The use of @option{--no-use-tor} disables the use of Tor. The default is to use Tor if it is available on startup or after reloading dirmngr. -- 2.20.1 From frederick888 at tsundere.moe Fri Apr 19 18:34:28 2019 From: frederick888 at tsundere.moe (Frederick Zhang) Date: Sat, 20 Apr 2019 02:34:28 +1000 Subject: Storing key on multiple smartcards In-Reply-To: <87zhomg44u.fsf@iwagami.gniibe.org> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> Message-ID: <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> > Sorry, I can't understand how your patch solves your particular > problem. There are 2 issues in my case: 1. When `-u` is given, GPG selects the latest secret subkey from those which have the desired capability, but keys that can be found on disk or in a currently accessible smart card should actually be preferred. 2. The current shadow key mechanism does not allow the same subkey to be stored on disk and/or one or more smart cards at the same time. My patch fixes only the first one (partially). It prioritises the secret subkey which is stored in the smart card that's being used right now among all those that can reach . > Perhaps, better approach would be using a serial number only as a > hint, extending keygrip-centric approach of gpg-agent. That sounds great! I was thinking that working around the current shadow key logic might require fewer changes but removing serial numbers from shadow keys is indeed better. If the serial numbers can be saved in plain text files, not only the duplicate data across shadow keys in my proposal can be avoided, it will also allow users to easily manage the info and store additional metadata like nicknames as you mentioned. > For warning message at keytocard command, I think that Peter's > suggestion makes sense, but please don't mix separate things. It is > related somehow, but I think it is better to be handled seperately. Sure. This is something that we can get out of the door quickly and it's not influenced by the other 2 problems. Do you want me to start another thread to nail down the wording? Peter also mentioned a new option for the keytocard command which allows users to keep the keygrip untouched after transferring the secret key to a smart card. Shall we move the discussion about this to the new thread as well? -- Best Regards, Frederick Zhang Email: frederick888 at tsundere.moe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Mon Apr 22 06:43:10 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 22 Apr 2019 13:43:10 +0900 Subject: Storing key on multiple smartcards In-Reply-To: <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> Message-ID: <87pnpeodk1.fsf@iwagami.gniibe.org> Frederick Zhang wrote: > That sounds great! I was thinking that working around the current shadow > key logic might require fewer changes but removing serial numbers from > shadow keys is indeed better. Let me share some technical detail of GnuPG internal. My plan (in master, towards 2.3) is: (1) gpg-agent shadow key protocol fix/modification Now, gpg-agent assumes one private key material resides in a single smartcard. This restriction should be relaxed. While current flow from gpg-agent to scdaemon is: gpg-agent | keygrip -> private key file -> shadow-info -> serial number + id_string | V scdaemon It should be possible, directly using keygrip to scdaemon: gpg-agent | keygrip | V scdaemon Then, we don't need the serial number as shadow-info in private key file. I think that this direct use of keygrip will simplify things in GnuPG. Besides, current protocol in use is named "t1-v1", which is typo. (2) scdaemon modification Now, the way to specify a key is: serial number + id_string or serial number + "/" + fingerprint where id_string is "OpenPGP.1", "OpenPGP.2", and "OpenPGP.3". I'd like to extend it using a keygrip to specify a key. Once, those modifications will be done, it's more straightforward to support different use cases with smartcard. (Or, those modifications themselves will solve some existing issues automatically.) Some use cases will still remain. Some day, I'd like to support a use case where signing+encryption is done naturally. That is, signing with a signing key on inserted smartcard and encryption for a encryption key on that card. -- From gniibe at fsij.org Tue Apr 23 23:17:05 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 24 Apr 2019 06:17:05 +0900 Subject: Storing key on multiple smartcards In-Reply-To: <87pnpeodk1.fsf@iwagami.gniibe.org> References: <87tvf6loi8.fsf@iwagami.gniibe.org> <6c6e635d-d52c-e8d1-bf2f-0083e4cfe147@tsundere.moe> <4c8966cd-f6c5-0f63-d2e6-031e6f9e0e9e@digitalbrains.com> <0d36523e-f2cd-e92d-4716-d6dce13a9ce1@digitalbrains.com> <87zhomg44u.fsf@iwagami.gniibe.org> <7b36dcc1-6c8e-a83d-8dc2-a26c4cb9e65e@tsundere.moe> <87pnpeodk1.fsf@iwagami.gniibe.org> Message-ID: <87h8aopgku.fsf@c720> NIIBE Yutaka wrote: > (2) scdaemon modification I have started this part in master. > Now, the way to specify a key is: > > serial number + id_string > > or > > serial number + "/" + fingerprint > > where id_string is "OpenPGP.1", "OpenPGP.2", and "OpenPGP.3". Sorry, the description above is not correct. It is either: id_string serial number serial number + "/" + fingerprint I pushed the change supporting keygrip here. Matching card with the serial number should be selected beforehand, when the PKSIGN, PKDECRYPT or PKAUTH commands are used. Note that scdaemon has support of having multiple cards (by internal CCID driver), a card is selected by the SERIALNO command. gpg-agent uses the sequence of SERIALNO and then PKSIGN/PKDECRYPT/PKAUTH with the context of serial number. We need a way to ask crypto operations with no-context-of-serial-number (the specific card) but with the keygrip. For crypto operations with the keygrip, I'm going to add new commands to scdaemon: KEYINFO [--list] PKSIGN_DIRECT PKDECRYPT_DIRECT PKAUTH_DIRECT (Perhaps, there are better names for PKSIGN_DIRECT, PKDECRYPT_DIRECT, and PKAUTH_DIRECT. Please let me know your comments.) The KEYINFO command is just like the one of gpg-agent. It gives us key information with keygrips. gpg-agent/gpg will use scdaemon's KEYINFO command to get the information of available keys by scdaemon. Then, do *_DIRECT. The *_DIRECT commands are not with a specific card context, scdaemon internally selects a card context automatically. It is scdaemon which determines card context by keygrip, This is the thing I call keygrip-centric. I'm going add KEYINFO to master this week. Since I'm not that confident yet, for *_DIRECT, I will have a topic branch, in next month. Then, merge into master. -- From bernhard at intevation.de Thu Apr 25 08:42:13 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 25 Apr 2019 08:42:13 +0200 Subject: Is ECC ready and increase the default RSA key size to 3072 bits? In-Reply-To: <87o952xfxm.fsf@fifthhorseman.net> References: <20190418072148.GN1226@zeromail.org> <87o952xfxm.fsf@fifthhorseman.net> Message-ID: <201904250842.18173.bernhard@intevation.de> Am Freitag 19 April 2019 15:50:13 schrieb Daniel Kahn Gillmor: > GnuPG master already defaults RSA keys to 3072 bits, > I agree that it makes sense to do this on the 2.2 branch. FWIW I also agree to switch the default. It matches modern recommendations for mid/long term security, e.g. from https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.1.pdf This is even when considering the FAQ linked from https://wiki.gnupg.org/LargeKeys | Will GnuPG ever support RSA-3072 or RSA-4096 by default? |Probably not. |Every minute we spend arguing about whether we should change the defaults |to RSA-3072 or more is one minute the shift to ECC is delayed. Is ECC ready to be the default? My estimation is: It is not, and then we should switch the default to RSA3072 until it is. My estimation is based on: * There are some GNU/Linux LTS distros in use that still have GnuPG 2.0 (E.g. Jessie, but probably others. Could be examined) * Ed25519 and Curve25519 are not in an agreed standard (as 4880bis is not ready and probably won't be for a while) While I blieve it is okay to move forward, other implementations may not be because of the missing standard. Example: OpenPGPjs just has a young implementation (Dec 2018 saw a major security release version 4.3.0) Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From wiktor at metacode.biz Thu Apr 25 13:48:18 2019 From: wiktor at metacode.biz (Wiktor Kwapisiewicz) Date: Thu, 25 Apr 2019 13:48:18 +0200 Subject: Trust model tofu+pgp and User ID in Signer's UID packet Message-ID: <684177cc-36b5-7d6c-8ff1-4f37dbeb765d@metacode.biz> Hello, I think I found an issue with how GnuPG handles signatures with Signer's UID field and trust model tofu+pgp. There was an issue reported to OpenKeychain [0] that messages generated by it are not trusted by GnuPG. The problem was that messages produced by K-9 mail and OpenKeychain are decrypted by GnuPG with the following warning: gpg: WARNING: We do NOT trust this key! gpg: The signature is probably a FORGERY. Even though the key is marked with "tofu-policy good" and looks fine in "gpg --edit-key". I did run the decryption with "--debug-level guru" and spotted the following message: gpg: DBG: TOFU: only considering user id: 'John Doe ' gpg: DBG: TOFU: skipping user id 'john at example.com', which does not match the signer's email ('John Doe ') gpg: DBG: no (of 0) valid bindings. Can't get TOFU validity for this set of user ids. As I've seen previously OpenKeychain embeds full User ID as Signer's UID (that is "John Doe ") but GnuPG users only e-mail ("john at example.com"). It seems when GnuPG encounters Signer's UID in full form it cannot get TOFU validity. "Signer's UID" looks like it could contain full UID so maybe GnuPG should support full User IDs there and just extract the e-mail address? I don't know if I got the issue right that's why I didn't create a ticket but if this sounds OK I can do so. Kind regards, Wiktor [0]: https://github.com/open-keychain/open-keychain/issues/2333 -- https://metacode.biz/@wiktor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 919 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Thu Apr 25 14:09:57 2019 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 25 Apr 2019 14:09:57 +0200 Subject: ECC Ed25519/Curve25519 ready as default? In-Reply-To: <9244024c35cd29c5b49d6dd54b749026d23cfe6a.camel@googlemail.com> References: <20190418072148.GN1226@zeromail.org> <201904250842.18173.bernhard@intevation.de> <9244024c35cd29c5b49d6dd54b749026d23cfe6a.camel@googlemail.com> Message-ID: <201904251410.02453.bernhard@intevation.de> Am Donnerstag 25 April 2019 13:50:34 schrieb Dirk Gottschalk: > Am Donnerstag, den 25.04.2019, 08:42 +0200 schrieb Bernhard Reiter: > > Is ECC ready to be the default? Which probably means Encryption ECDH RFC7748: Curve25519 and Signature EdDSA RFC8032: Ed25519, see https://wiki.gnupg.org/ECC. > I am concerned that such a default switch would break the compatiblity > to many running foreign implementations of OpenPGP. Best would be to compile a list (e.g. in the wiki) as documented basis for a decision. > Openkeychain, for example, does not support ECC, or it did not. Its docs say it does since v2.8 (2014-08) and more specifically Curve25519 since v4.9 (2018-02) https://github.com/open-keychain/open-keychain/blob/HEAD/OpenKeychain/src/main/res/raw/help_changelog.md https://github.com/open-keychain/open-keychain/releases > I think we should establish the standard for ECC in OpenPGP first and > then wait a while before switching to ECC as default. Personally I've heard that progress on RFC4880bis is difficult, so if it does not go forward, there still should be a point to switch the default. Best Regards, Bernhard -- www.intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From dirk.gottschalk1980 at googlemail.com Thu Apr 25 13:50:34 2019 From: dirk.gottschalk1980 at googlemail.com (Dirk Gottschalk) Date: Thu, 25 Apr 2019 13:50:34 +0200 Subject: Is ECC ready and increase the default RSA key size to 3072 bits? In-Reply-To: <201904250842.18173.bernhard@intevation.de> References: <20190418072148.GN1226@zeromail.org> <87o952xfxm.fsf@fifthhorseman.net> <201904250842.18173.bernhard@intevation.de> Message-ID: <9244024c35cd29c5b49d6dd54b749026d23cfe6a.camel@googlemail.com> Hi. Am Donnerstag, den 25.04.2019, 08:42 +0200 schrieb Bernhard Reiter: > Am Freitag 19 April 2019 15:50:13 schrieb Daniel Kahn Gillmor: > > GnuPG master already defaults RSA keys to 3072 bits, > > I agree that it makes sense to do this on the 2.2 branch. > FWIW I also agree to switch the default. > It matches modern recommendations for mid/long term security, > e.g. from > https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.1.pdf > This is even when considering the FAQ linked > from https://wiki.gnupg.org/LargeKeys Yes, we should switch for sure. I am using Keys with 4096 bit keys for a longer while, now. AFAIR since GPG supports it. I even would prefer this to be the default. > > Will GnuPG ever support RSA-3072 or RSA-4096 by default? > > Probably not. > > Every minute we spend arguing about whether we should change the > > defaults to RSA-3072 or more is one minute the shift to ECC is > > delayed. > Is ECC ready to be the default? > My estimation is: It is not, and then we should switch the default to > RSA3072 until it is. I am concerned that such a default switch would break the compatiblity to many running foreign implementations of OpenPGP. On my side I am not using ECC for two reasons. The first is, the card does noit support the curve I would prefer. The second an more important one is that some of my communicationd partners use another implementations, or use Apps on their mobiles for email which don't support ECC. Openkeychain, for example, does not support ECC, or it did not. I didn't test it for a while and did not look into it's documentation while writing this email. > My estimation is based on: > * There are some GNU/Linux LTS distros in use that still have GnuPG > 2.0 (E.g. Jessie, but probably others. Could be examined) > * Ed25519 and Curve25519 are not in an agreed standard (as 4880bis is > not ready and probably won't be for a while) While I blieve it is > okay to move forward, other implementations may not be because of the > missing standard. Example: OpenPGPjs just has a young implementation > (Dec 2018 saw a major security release version 4.3.0) A default switch would not be a problem if it would not break the compatiblity itself as the other key types are still there. But users who did not dig deeper into this topic often use the defaults. I think we should establish the standard for ECC in OpenPGP first and then wait a while before switching to ECC as default. Regards, Dirk -- Dirk Gottschalk Ardennenstrasse 25 52076 Aachen, Germany GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380 Keybase.io: https://keybase.io/dgottschalk GitHub: https://github.com/Dirk1980ac -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From aheinlein at gmx.com Fri Apr 26 10:14:51 2019 From: aheinlein at gmx.com (Andreas Heinlein) Date: Fri, 26 Apr 2019 10:14:51 +0200 Subject: ECC Ed25519/Curve25519 ready as default? In-Reply-To: <201904251410.02453.bernhard@intevation.de> References: <20190418072148.GN1226@zeromail.org> <201904250842.18173.bernhard@intevation.de> <9244024c35cd29c5b49d6dd54b749026d23cfe6a.camel@googlemail.com> <201904251410.02453.bernhard@intevation.de> Message-ID: <44517174-d09d-a742-3ab4-80f1091ef7a5@gmx.com> Am 25.04.19 um 14:09 schrieb Bernhard Reiter: > Best would be to compile a list (e.g. in the wiki) > as documented basis for a decision. Such a list should probably include frontend support as well, at least for the major frontends. AFAIK, GNOME seahorse does not, at least it does not offer creating ECC keys. Andreas From dkg at fifthhorseman.net Fri Apr 26 16:31:28 2019 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 26 Apr 2019 10:31:28 -0400 Subject: ECC Ed25519/Curve25519 ready as default? In-Reply-To: <44517174-d09d-a742-3ab4-80f1091ef7a5@gmx.com> References: <20190418072148.GN1226@zeromail.org> <201904250842.18173.bernhard@intevation.de> <9244024c35cd29c5b49d6dd54b749026d23cfe6a.camel@googlemail.com> <201904251410.02453.bernhard@intevation.de> <44517174-d09d-a742-3ab4-80f1091ef7a5@gmx.com> Message-ID: <87ef5org73.fsf@fifthhorseman.net> On Fri 2019-04-26 10:14:51 +0200, Andreas Heinlein wrote: > Am 25.04.19 um 14:09 schrieb Bernhard Reiter: >> Best would be to compile a list (e.g. in the wiki) >> as documented basis for a decision. > > Such a list should probably include frontend support as well, at least > for the major frontends. AFAIK, GNOME seahorse does not, at least it > does not offer creating ECC keys. creating ECC keys isn't the issue here -- the issue at hand is interoperability: if an implementation like GnuPG *does* default to creating an Ed25519 key, how much of the deployed OpenPGP ecosystem will fail to interoperate with such a key? fwiw, i think GnuPG has been so entrenched that one of the main factors for delay here will be with previous versions of GnuPG itself (someone has already mentioned Debian Jessie on this thread). But i agree that a list of commonly-used OpenPGP implementations, and the versions at which they gained the ability to handle the different ECC algorithms would be a useful thing to have. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: