Subject: Re: Secret key signature packet

From: [email-masked] ("Hal Finney")
Date: Tue, 23 Aug 2005 09:06:32 -0700 (PDT)

From: <[email-masked]>
> What is the content of the secret key signature packet? I know that open
> pgp doesn`t support secret key signing so hash left 2 bytes, DSA r and DSA
> s are not included in the signature packet. I assume that the content is:
>
> -Version number (1 octet)
> -Signature type (1 octet)
> -Public key algorithm (1 octet)
> -Hash algorithm (1 octet)
> -Hashed subpackets (n octets)
> -Sub packet (issuer key id 8 octets)

I'm sorry, I don't know what you mean by a secret key signature packet.
As I noted earlier, we don't sign secret keys.  There would be no point
in creating a "signature" packet that was missing the signature fields,
r and s.

Maybe this will help.  OpenPGP implementations usually store the public
keys separately from the secret keys.  Traditionally these stores are
called "key rings".  The public key ring contains public keys (your
own public key and also those belonging to other people), user ids, and
signatures.  The secret key ring contains your own secret keys and their
user ids.  There is no need for signature packets on the secret key ring.
If there are any signature packets there, they will be signatures over
just the public key portion of the secret key packets.  They are not
secret key signatures, there is no such thing.

Hal Finney

---

From: Adam Back <[email-masked]>
Date: Tue, 23 Aug 2005 13:51:49 -0400

I might be misunderstanding but I read the original poster to be maybe
hinting at modification detection of the private key ring somehow.

I am not sure of any attack based on modifying the private key in an
undetectable way... that would generally seem to make invalid
signatures, and inability to decrypt.  

On the other hand changing the trust markers, or changing public
encryption keys of other parties -- that would seem dangerous.

So there would be value in that, tho AFAIK this info is on the public
key ring.

(Also with some implementations I've noticed they can operate just with
the private keyring as the private key is a superset of the public
key.)

Also the threat model is a bit arguable; if an attacker can modify the
keyrings, he could likely also insert a keyboard logger; maybe there
is some difference tho if for example the software is kept separate,
and there is some risk of attacker modifying the just the data on the
keyring storage device.

Adam

---

From: David Shaw <[email-masked]>
Date: Tue, 23 Aug 2005 14:37:49 -0400

> signatures, and inability to decrypt.  

Could the original poster be thinking of the Klima-Rosa attack and the
secret key "s2k 254" SHA-1 protection?

David

---

From: Adam Back <[email-masked]>
Date: Wed, 24 Aug 2005 01:01:36 -0400

> signatures, and inability to decrypt.  

Actually, let me revise that: I think one could likely mount an attack
based on ability to modify _parts of_ the private key.  eg with RSA
the relation e.d = 1 mod phi(n) would no longer hold and so forth
likely leaking parts of the private key.  And there was a long time
ago some discussion and examples of how one could modify the CFB mode
protection that is used for unsigned bulk encryption in PGP (in modes
that do not have a MDC).

Well lets see if the original poster can explain his use-case.

But I think for the above reason it might be interesting in lets say
an example where you were to keep your private keyring on a network
drive (feeling secure in knowledge you have a good passphrase, or even
perhaps a computer generated password that you have written down); the
attack then would be that someone could modify the private keyring
perhaps adaptively and thereby compute the private key.

(Or similar attack private key ring on USB key; but USB key not
physically secured, left where attacker can selectively change bits).

btw for this use-case I think using the MDC mode for encrytping the
private part would be a good step.  Might be interesting also to MAC
(with key derived from passphrase) any non-encrypted parts of the
private (and public) keyrings.

Adam