Re: GnuPG public key vulnerability?

[David Shaw]

On Oct 31, 2017, at 8:10 PM, murphy  wrote:
> 
> I got a signed notification from facebook (good signature, enigmail)
> that claims my GnuPG generated public key has a "recently disclosed
> vulnerability".  This is the full text:
> 
> We have detected that the OpenPGP key on your Facebook profile may be
> susceptible to attacks due to a recently disclosed vulnerability.  We
> recommend that you revoke and replace your public key immediately to
> minimize the risk to your encrypted communications.  You can update your
> public key by visiting your Security and Login settings.  To help reduce
> the risk of your key being attacked, we have set the privacy of your
> potentially vulnerable public key on your profile to "Only Me" to limit
> further distribution.  We will continue to encrypt your notification
> emails using this OpenPGP public key.
> 
> This is doubly weird since the private/public key was generated on a
> Yubikey-4 nano and it is safe at home.  Does anyone know what this may
> be about?

Yes.

Recently, a flaw in the firmware for some Infineon hardware crypto was found.  
RSA keys that were generated with this faulty firmware are not nearly as strong 
as their key length would imply.

You mention a Yubikey 4 nano, and unfortunately, that is one of the devices 
that used Infineon components.  In the case of a Yubikey and OpenPGP, if you 
generate the key *on* a vulnerable Yubikey, you may have a problem.  If you 
generate the OpenPGP key elsewhere and *import* the key to your Yubikey, you 
are not affected.

The Yubico people have a site up to check your device serial number to see if 
it is vulnerable and are offering a replacement program.  See 
https://www.yubico.com/keycheck/

There has been some discussion of the implications of this vulnerability on 
this list.  Search the list archives for "ROCA" to see more.

The original paper is at https://crocs.fi.muni.cz/public/papers/rsa_ccs17

David


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

devuan jessie gpg 2.2.x thunderbird/apparmor/enigmail rules

[Fulano Diego Perez]

any suggestions to complete apparmor rules to enable all functionality
for a /usr/local gpg install with thunderbird/gpg/enigmail ?

currently appended rules below to the default thunderbird profile allow
mostly all functionality except i cannot enable the commented out rules
otherwise enigmail does not detect gnupg and fails to start

as soon i comment out, enigmail fails...

i think my previous email with problems with dirmngr could be related
and if those are debugged, could help here

below allows most thunderbird/enigmail functionality except importing
keyserver keys

/etc/apparmor.d/local/usr.bin.thunderbird:

/usr/local/bin/gpg   Cx -> gpg,
/usr/local/bin/gpg-error Cx -> gpg,
#/usr/local/bin/dirmngr   Cx -> gpg,
/usr/local/bin/gpg-agent Cx -> gpg,
/usr/local/bin/gpgconf   Cx -> gpg,
/usr/local/bin/gpg-connect-agent Cx -> gpg,

#/proc/**/fd/ r,
owner @{HOME}/.gnupg/tofu.db rwk,
#owner @{HOME}/.gnupg/tofu.db-journal rwk,
/usr/local/bin/gpg mr,
/usr/local/bin/gpg-error mr,
#/usr/local/bin/dirmngr mr,
/usr/local/bin/gpg-agent mr,
/usr/local/bin/gpgconf mr,
/usr/local/bin/gpg-connect-agent mr,
/usr/lib/gnupg/gpgkeys_* ix,

/usr/local/lib/** mr,

this profile still logs below possible problems:

[51155.130813] audit: type=1400 audit(1509507779.968:128572837):
apparmor="DENIED" operation="mknod" profile="thunderbird//gpg"
name="/home/user/.gnupg/tofu.db-journal" pid=20072 comm="gpg"
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
[51155.139191] audit: type=1400 audit(1509507779.976:128572838):
apparmor="DENIED" operation="mknod" profile="thunderbird//gpg"
name="/home/user/.gnupg/tofu.db-journal" pid=20072 comm="gpg"
requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
[51161.198110] audit: type=1400 audit(1509507786.040:128572839):
apparmor="DENIED" operation="open" profile="thunderbird//gpg"
name="/proc/20077/fd/" pid=20077 comm="gpg" requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[51161.198390] audit: type=1400 audit(1509507786.040:128572840):
apparmor="DENIED" operation="exec" profile="thunderbird//gpg"
name="/usr/local/bin/dirmngr" pid=20077 comm="gpg" requested_mask="x"
denied_mask="x" fsuid=1000 ouid=0
[51177.540706] audit: type=1400 audit(1509507802.392:128572841):
apparmor="DENIED" operation="open" profile="thunderbird//gpg"
name="/proc/20080/fd/" pid=20080 comm="gpg" requested_mask="r"
denied_mask="r" fsuid=1000 ouid=1000
[51177.541002] audit: type=1400 audit(1509507802.392:128572842):
apparmor="DENIED" operation="exec" profile="thunderbird//gpg"
name="/usr/local/bin/dirmngr" pid=20080 comm="gpg" requested_mask="x"
denied_mask="x" fsuid=1000 ouid=0






___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG public key vulnerability?

[Jonathan Millican]

Hi Murphy,

This email refers to the ROCA vulnerability (https://crocs.fi.muni.cz/
public/papers/rsa_ccs17), which affects a number of hardware devices
including some versions of the Yubikey 4-nano (https://www.yubico.com/
keycheck/). I believe Yubico are offering to replace affected Yubikeys.

One aspect of this vulnerability is that RSA public keys can be very easily
checked to determine if they are vulnerable - so at Facebook, we checked
the public keys that have been uploaded to people's profiles, and notified
people whose keys are affected. Unfortunately it seems like you were one of
the unlucky ones! Details here: https://www.facebook.com/
protectthegraph/posts/1954548564785285.

Hope that helps,
Jon

On 1 November 2017 at 00:10, murphy  wrote:

> I got a signed notification from facebook (good signature, enigmail)
> that claims my GnuPG generated public key has a "recently disclosed
> vulnerability".  This is the full text:
>
> We have detected that the OpenPGP key on your Facebook profile may be
> susceptible to attacks due to a recently disclosed vulnerability.  We
> recommend that you revoke and replace your public key immediately to
> minimize the risk to your encrypted communications.  You can update your
> public key by visiting your Security and Login settings.  To help reduce
> the risk of your key being attacked, we have set the privacy of your
> potentially vulnerable public key on your profile to "Only Me" to limit
> further distribution.  We will continue to encrypt your notification
> emails using this OpenPGP public key.
>
> This is doubly weird since the private/public key was generated on a
> Yubikey-4 nano and it is safe at home.  Does anyone know what this may
> be about?
>
> Facebook public key (it is valid, see:
> https://www.facebook.com/notes/protect-the-graph/
> securing-email-communications-from-facebook/1611941762379302/):
>
> pub   rsa4096 2015-05-17 [SC] [expires: 2018-05-17]
>  31A70953D8D590BA1FAB37762F3898CEDEE958CF
> uid   [  full  ] Facebook, Inc.
> sub   rsa4096 2017-07-24 [S] [expires: 2018-02-19]
>
> My public key is uploaded to keyservers and is:
>
> pub   rsa4096 2016-10-17 [SC] [expires: 2018-10-17]
>  D89A29A3E1DA59DFBF516EA73E450D1BCF78C26B
> uid   [ultimate] orange
> uid   [ultimate] Murphy Chesney (facebook communication)
> 
> sub   rsa4096 2016-10-17 [A] [expires: 2018-10-17]
> sub   rsa2048 2016-10-17 [E] [expires: 2018-10-17]
>
> Murphy
>
>
>
> ___
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users
>
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: permission denied searching keys WAS: [gpg 2.2.x devuan jessie no TOFU TLS]

[Fulano Diego Perez]

later:

im not sure what to do now

most functionality seems ok except for searching/importing keys from
keyservers

i can see my local pub/pri keyrings

Fulano Diego Perez:
> 
> 
> Werner Koch:
>> On Thu, 26 Oct 2017 16:00, fulanope...@cryptolab.net said:
>>
>>> checking for LIBGNUTLS... no
>>
>> The minimal requirement is GNUTLS 3.0 - please check that you have the
>> 3.x -dev package installed.  You should also consult config.log to check
>> why GNUTLS was not found.
>>
>>
>> Salam-Shalom,
>>
>>Werner
> 
> installing pkg-config found them !

$ gpg -vvv --keyserver jirk5u4osbsr34t5.onion --search-keys sexypgp
gpg: using character set 'utf-8'
gpg: error searching keyserver: Operation not permitted
gpg: keyserver search failed: Operation not permitted

$ gpgconf --check-programs
gpg:OpenPGP:/usr/local/bin/gpg:1:1:
gpg-agent:Private Keys:/usr/local/bin/gpg-agent:1:1:
scdaemon:Smartcards:/usr/local/libexec/scdaemon:1:1:
gpgsm:S/MIME:/usr/local/bin/gpgsm:1:1:
dirmngr:Network:/usr/local/bin/dirmngr:1:1:
pinentry:Passphrase Entry:/usr/local/bin/pinentry:1:1:

$ ls -la /usr/local/bin/
drwxrwsr-x  2 root staff4096 Oct 30 17:39 .
drwxrwsr-x 11 root staff4096 Oct 28 02:12 ..
lrwxrwxrwx  1 root staff   3 Oct 26 00:02 captoinfo -> tic
-rwxr-xr-x  1 root staff   90200 Oct 26 00:02 clear
-rwxr-xr-x  1 root staff 2407640 Oct 30 17:39 dirmngr
-rwxr-xr-x  1 root staff  481760 Oct 30 17:39 dirmngr-client
-rwxr-xr-x  1 root staff   34744 Oct 25 23:45 dumpsexp
-rwxr-xr-x  1 root staff 4216344 Oct 30 17:39 gpg
-rwxr-xr-x  1 root staff 1667432 Oct 30 17:39 gpg-agent
-rwxr-xr-x  1 root staff  591960 Oct 30 17:39 gpgconf
-rwxr-xr-x  1 root staff  674176 Oct 30 17:39 gpg-connect-agent
-rwxr-xr-x  1 root staff   81640 Oct 25 23:11 gpg-error
-rwxr-xr-x  1 root staff2201 Oct 25 23:11 gpg-error-config
-rwxr-xr-x  1 root staff   92800 Oct 30 17:39 gpgparsemail
-rwxr-xr-x  1 root staff  837064 Oct 30 17:39 gpgscm
-rwxr-xr-x  1 root staff 2163056 Oct 30 17:39 gpgsm
-rwxr-xr-x  1 root staff  671016 Oct 30 17:39 gpgtar
-rwxr-xr-x  1 root staff 2053392 Oct 30 17:39 gpgv
-rwxr-xr-x  1 root staff   43720 Oct 25 23:45 hmac256
-rwxr-xr-x  1 root staff  234984 Oct 26 00:02 infocmp
lrwxrwxrwx  1 root staff   3 Oct 26 00:02 infotocap -> tic
-rwxr-xr-x  1 root staff  799952 Oct 30 17:39 kbxutil
-rwxr-xr-x  1 root staff2647 Oct 25 23:47 ksba-config
-rwxr-xr-x  1 root staff2522 Oct 25 23:48 libassuan-config
-rwxr-xr-x  1 root staff4003 Oct 25 23:45 libgcrypt-config
-rwxr-xr-x  1 root staff   51256 Oct 25 23:45 mpicalc
-rwxr-xr-x  1 root staff6016 Oct 26 00:02 ncurses6-config
-rwxr-xr-x  1 root staff3108 Oct 25 22:58 npth-config
lrwxrwxrwx  1 root staff  14 Oct 30 17:32 pinentry -> pinentry-gtk-2
-rwxr-xr-x  1 root staff  466328 Oct 30 17:32 pinentry-curses
-rwxr-xr-x  1 root staff  556120 Oct 30 17:32 pinentry-gtk-2
lrwxrwxrwx  1 root staff   4 Oct 26 00:02 reset -> tset
-rwxr-xr-x  1 root staff  107384 Oct 26 00:02 tabs
-rwxr-xr-x  1 root staff  265896 Oct 26 00:02 tic
-rwxr-xr-x  1 root staff  161352 Oct 26 00:02 toe
-rwxr-xr-x  1 root staff  107872 Oct 26 00:02 tput
-rwxr-xr-x  1 root staff   96184 Oct 26 00:02 tset
-rwxr-xr-x  1 root staff   41248 Oct 30 17:39 watchgnupg

dirmngr.conf:

use-tor
keyserver hkp://jirk5u4osbsr34t5.onion


any advice to proceed ?




___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: GnuPG public key vulnerability?

[Fraser Tweedale]

On Tue, Oct 31, 2017 at 08:10:45PM -0400, murphy wrote:
> I got a signed notification from facebook (good signature, enigmail)
> that claims my GnuPG generated public key has a "recently disclosed
> vulnerability".  This is the full text:
> 
> We have detected that the OpenPGP key on your Facebook profile may be
> susceptible to attacks due to a recently disclosed vulnerability.  We
> recommend that you revoke and replace your public key immediately to
> minimize the risk to your encrypted communications.  You can update your
> public key by visiting your Security and Login settings.  To help reduce
> the risk of your key being attacked, we have set the privacy of your
> potentially vulnerable public key on your profile to "Only Me" to limit
> further distribution.  We will continue to encrypt your notification
> emails using this OpenPGP public key.
> 
> This is doubly weird since the private/public key was generated on a
> Yubikey-4 nano and it is safe at home.  Does anyone know what this may
> be about?
> 
Some versions of the YubiKey 4 were affected by the ROCA
vulnerability, which caused weak keys to be generated.

https://www.yubico.com/support/security-advisories/ysa-2017-01/
https://crocs.fi.muni.cz/public/papers/rsa_ccs17

I would say that is what the email is about.

Cheers,
Fraser


signature.asc
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

GnuPG public key vulnerability?

[murphy]

I got a signed notification from facebook (good signature, enigmail)
that claims my GnuPG generated public key has a "recently disclosed
vulnerability".  This is the full text:

We have detected that the OpenPGP key on your Facebook profile may be
susceptible to attacks due to a recently disclosed vulnerability.  We
recommend that you revoke and replace your public key immediately to
minimize the risk to your encrypted communications.  You can update your
public key by visiting your Security and Login settings.  To help reduce
the risk of your key being attacked, we have set the privacy of your
potentially vulnerable public key on your profile to "Only Me" to limit
further distribution.  We will continue to encrypt your notification
emails using this OpenPGP public key.

This is doubly weird since the private/public key was generated on a
Yubikey-4 nano and it is safe at home.  Does anyone know what this may
be about?

Facebook public key (it is valid, see:
https://www.facebook.com/notes/protect-the-graph/securing-email-communications-from-facebook/1611941762379302/):

pub   rsa4096 2015-05-17 [SC] [expires: 2018-05-17]
 31A70953D8D590BA1FAB37762F3898CEDEE958CF
uid   [  full  ] Facebook, Inc.
sub   rsa4096 2017-07-24 [S] [expires: 2018-02-19]

My public key is uploaded to keyservers and is:

pub   rsa4096 2016-10-17 [SC] [expires: 2018-10-17]
 D89A29A3E1DA59DFBF516EA73E450D1BCF78C26B
uid   [ultimate] orange
uid   [ultimate] Murphy Chesney (facebook communication)

sub   rsa4096 2016-10-17 [A] [expires: 2018-10-17]
sub   rsa2048 2016-10-17 [E] [expires: 2018-10-17]

Murphy




signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hacking off-card backup to be on-disk key (was: Importing an off-card backup of the encryption key of a Nitrokey fails with "no user ID")

[Peter Lebbing]

Hi Ralf,

On 25/10/17 23:29, Ralf wrote:
> I was hoping for something simple and I think eventually this should be
> simple; nevertheless I would make use of such a workaround / would be
> thankful for such an example :)

I fiddled around with a test card. Prepare for a wall of text.

I created a test key on card:

--8<---cut here---start->8---
sec  rsa2048/A7C45205828E4D09
 created: 2017-10-31  expires: 2017-11-07  usage: SC
 card-no: 0005 106E
 trust: never validity: ultimate
ssb  rsa2048/D614DCD256D4028C
 created: 2017-10-31  expires: 2017-11-07  usage: A
 card-no: 0005 106E
ssb  rsa2048/93104C8F5B4A4714
 created: 2017-10-31  expires: 2017-11-07  usage: E
 card-no: 0005 106E
--8<---cut here---end--->8---

We start with damage control. Always backup your .gnupg directory before 
doing risky stuff. I'm assuming the backup dir .gnupg~ does not already 
exist; otherwise, delete it first or choose a different name.

--8<---cut here---start->8---
$ cd
$ cp -a .gnupg/ .gnupg~
--8<---cut here---end--->8---

The following actions: export secret key, delete secret key from 
keyring, import secret key, show an interesting behaviour of my GnuPG 
2.1.18 related to card keys:

--8<---cut here---start->8---
$ gpg -o cardkey.gpg --export-secret-keys 
0976A143384202C99E7C26EFA7C45205828E4D09
$ gpg --delete-secret-and-public-keys-keys 
0976A143384202C99E7C26EFA7C45205828E4D09
[...]
$ gpg --import cardkey.gpg 
gpg: key A7C45205828E4D09: "Test Backup Hack" not changed
gpg: To migrate 'secring.gpg', with each smartcard, run: gpg --card-status
gpg: key A7C45205828E4D09: secret key imported
gpg: Total number processed: 1
gpg:  unchanged: 1
gpg:   secret keys read: 1
--8<---cut here---end--->8---

It will not import the secret key stubs[1]. What it is obliquely saying 
is: don't import key stubs, just insert your smartcard and run --card-
status. Keep this in mind. It will come back in a different form.

Don't run --card-status at this time, by the way.

Now we start with packet surgery. Unlike a surgeon, we start by fully 
taking apart the body ;-).

--8<---cut here---start->8---
$ cd tmp/
$ gpgsplit ../cardkey.gpg 
$ ls
01-005.secret_key  04-007.secret_subkey  07-002.sig
02-013.user_id 05-002.sig
03-002.sig 06-007.secret_subkey
--8<---cut here---end--->8---

I always have a "tmp" dir handy for throwaway stuff. Create an empty dir 
first if necessary.

An OpenPGP file always consists of a stream of packets. gpgslit just 
splits these packets over multiple files without changing anything else. 
We need to figure out which of the "secret_subkey" files is the secret 
key stub for the encryption key. First note that the encryption key is 
the key with ID 93104C8F5B4A4714, as can be told from the off-card 
backup file named sk_93104C8F5B4A4714.gpg.

--8<---cut here---start->8---
$ cat *secret*|gpg --list-packets 
# off=0 ctb=95 tag=5 hlen=3 plen=294
:secret key packet:
version 4, algo 1, created 1509451630, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
serial-number:  d2 76 00 01 24 01 02 00 00 05 00 00 10 6e 00 00
keyid: A7C45205828E4D09
# off=297 ctb=9d tag=7 hlen=3 plen=294
:secret sub key packet:
version 4, algo 1, created 1509451630, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
serial-number:  d2 76 00 01 24 01 02 00 00 05 00 00 10 6e 00 00
keyid: D614DCD256D4028C
# off=594 ctb=9d tag=7 hlen=3 plen=294
:secret sub key packet:
version 4, algo 1, created 1509451630, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
gnu-divert-to-card S2K, algo: 0, simple checksum, hash: 0
serial-number:  d2 76 00 01 24 01 02 00 00 05 00 00 10 6e 00 00
keyid: 93104C8F5B4A4714
--8<---cut here---end--->8---

These are the three packets with "secret" in their name, *in order*. The 
last of the three has the right key ID, so that means 
06-007.secret_subkey contains the stub we want to replace.

Now let's take a look at that pesky sk_93104C8F5B4A4714.gpg that you 
were trying to import, with the off-card backup of the encryption key:

--8<---cut here---start->8---
$ gpg --list-packets ~/.gnupg/sk_93104C8F5B4A4714.gpg 
# off=0 ctb=95 tag=5 hlen=3 plen=966
:secret key packet:
version 4, algo 1, created 1509451630, expires 0
pkey[0]: [2048 bits]
pkey[1]: [17 bits]
  

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Lachlan Gunn]

Le 2017-10-31 à 13:01, Peter Lebbing a écrit :
> Revocations are done by the primary key. If the user has lost the secret
> primary, they should fetch their revocation certificate, not fool around with
> the subkeys ;-). (Incidentally, this is why you don't need revocation
> certificates for individual subkeys.)

True, though this applies to the primary key too---I was thinking of all
signatures, really.  But if you consider that correct then it is only
accidentally so :)

> [1] Lachlan indicates "lost" is also treated as "signatures before revocation
> date remain valid", but I haven't checked myself.

I would recommend checking this yourself, as a quick google didn't find
it, and I haven't had a chance to do more thorough research.

Thanks,
Lachlan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Peter Lebbing]

On 31/10/17 11:56, Lachlan Gunn wrote:
> The only difficulty is when the owner doesn't have the secret key
> anymore, and so can't re-revoke it.  Then you might want to keep it from
> being disseminated further.

Revocations are done by the primary key. If the user has lost the secret
primary, they should fetch their revocation certificate, not fool around with
the subkeys ;-). (Incidentally, this is why you don't need revocation
certificates for individual subkeys.)

I'm glad we agree, because I didn't sleep so well and I see I'm making mistakes
:-D. The [1] in:

I suppose a system checking for ROCA might rightfully take offense at a subkey
revoked as "superseded" or "lost"[1], because with ROCA it is actually
"compromised".

should have been a footnote:

[1] Lachlan indicates "lost" is also treated as "signatures before revocation
date remain valid", but I haven't checked myself.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Lachlan Gunn]

Le 2017-10-31 à 12:48, Peter Lebbing a écrit :
> Having read my follow-up, do you now agree? If the subkey is revoked as
> "compromised", all is well and good?

I can't see any reason why this should be problematic.  And for
signatures that you know for sure are pre-ROCA, it makes sense to keep
the subkey around.

The only difficulty is when the owner doesn't have the secret key
anymore, and so can't re-revoke it.  Then you might want to keep it from
being disseminated further.

Thanks,
Lachlan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Peter Lebbing]

On 31/10/17 11:45, Lachlan Gunn wrote:
> No, I don't think so

I was already writing a follow-up but was momentarily blocked on the right way
to phrase some of it :-). Our mails crossed.

Having read my follow-up, do you now agree? If the subkey is revoked as
"compromised", all is well and good?

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Peter Lebbing]

On 31/10/17 11:39, Peter Lebbing wrote:
> And yes, the subkey should also be revoked with reason "compromised", for the
> reason you state.

And only now the penny drops.

I suppose a system checking for ROCA might rightfully take offense at a subkey
revoked as "superseded" or "lost"[1], because with ROCA it is actually
"compromised". I never checked what GnuPG does with two revocations on a key,
the earlier a "superseded" and the later a "compromised". The only correct thing
would be to treat it as "compromised", especially because the attacker could
generate a "superseded" with an earlier timestamp after the compromise and
create the same situation. So it ought to work.

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Lachlan Gunn]

Le 2017-10-31 à 12:39, Peter Lebbing a écrit :
> To clarify, do you agree if I reword the paragraph you contest as:
> 
> But, I agree that the reverse is not true: a compromised subkey does not
> compromise the primary key in any way I can think of. And systems
> checking for ROCA should not reject a certificate because there is
> something wrong with an already revoked subkey.
> 
> The only change is in the last word :-).

No, I don't think so---even if the subkey is revoked, there is nothing
stopping me from factoring its public key and then signing all kinds of
documents with a backdated timestamp.  I guess if I'm running the test
myself then I can go ahead and ignore signatures from that subkey, but
ideally the key would actually be marked as compromised.

Thanks,
Lachlan

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Impact of ROCA (CVE-2017-15361) in subkey vs. private key?

[Peter Lebbing]

On 31/10/17 01:08, Lachlan Gunn wrote:
> I'm not sure that this is 100% correct.  The first part is true, but 
> signatures
> of a key that has been revoked because it was superseded or lost are valid up 
> to
> the revocation date, whereas ROCA-affected keys are compromised to some degree
> and so all signatures are suspect; the revocation status should, ideally,
> reflect this.

Oh, I was talking about a ROCA-affected *subkey* but a clean primary key, where
the subkey was already revoked by the primary key. I think you are talking about
a ROCA-affected primary key.

A ROCA-affected primary key should be revoked as *compromised*, replaced and not
used in any capacity.

And yes, the subkey should also be revoked with reason "compromised", for the
reason you state.

To clarify, do you agree if I reword the paragraph you contest as:

But, I agree that the reverse is not true: a compromised subkey does not
compromise the primary key in any way I can think of. And systems
checking for ROCA should not reject a certificate because there is
something wrong with an already revoked subkey.

The only change is in the last word :-).

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 



signature.asc
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users