Subject: New results against SHA-1

From: David Shaw <[email-masked]>
Date: Thu, 30 Apr 2009 18:39:32 -0400

http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

There is not much hard information yet, but the two big quotes are  
"SHA-1 collisions now 2^52" and "Practical collisions are within  
resources of a well funded organisation."

David

From: David Shaw <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: New results against SHA-1
Date: Thu, 30 Apr 2009 18:39:32 -0400
Sender: [email-masked]

http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf

There is not much hard information yet, but the two big quotes are  
"SHA-1 collisions now 2^52" and "Practical collisions are within  
resources of a well funded organisation."

David

Date: Tue, 28 Apr 2009 12:30:02 -0400
From: Daniel Kahn Gillmor <[email-masked]>
Reply-To: IETF OpenPGP Working Group <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Re: Preferred Key Server subpacket in non-self-signature?
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE21A46F83D26E51F0ECFE6A0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 04/28/2009 11:50 AM, David Shaw wrote:
> I would say it means "Here is how the person who issued that
> certification wants you to get his key".  The same thing applies if the=

> preferred keyserver packet was included on a regular data signature
> (which GPG supports, by the way).

Ah, ok.  I was thinking it would refer to where to fetch updates for
that particular signature, not for the key.  The section reads:

   This is a URI of a key server that the key holder prefers be used for
   updates.  Note that keys with multiple User IDs can have a preferred
   key server for each User ID.  Note also that since this is a URI, the
   key server can actually be a copy of the key retrieved by ftp, http,
   finger, etc.

"used for updates" was unclear to me because i was thinking that it
meant "to get updates about this signature" rather than "to get updates
about the signer's key".

Is there a way for the issuer of a signature to provide a place where
updates to the signature itself (e.g. revocations, or re-certifications)
would be published?

I understand that the global keyserver network is normally what you'd
use.  But i'm trying to work through the context of an organization who
wants to also publish all their signature revocations in a known,
canonical location (including the revocations of certifications of
third-party keys).  Maybe this use case is misguided or irrelevant,
though.  Is it?

> Unless
> Carol is doing some sort of trust calculation, and her trust path to
> Alice runs through Bob, Bob's signature is not really relevant here.
>  [...]
> If there is a preferred keyserver subpacket on Alice's self-sig, then i=
t
> was issued by Alice, and the recipient can either follow it or not, as
> they like.  I'm not sure I follow where Bob's subpacket comes in here.

OK, my scenario implicitly presumed that Carol trusts Bob to make good
certifications, but doesn't know Alice.  I should have spelled that out
in the first place.

While Alice's key/userID has been certified by Bob, Carol wants to make
sure that Bob hasn't revoked his certification on Alice's key (and maybe
she's concerned that her keyserver is somehow compromised and not
producing the correct revocation certificates, or Bob doesn't want to or
can't publish his revocation to the public keyservers).

The more i think about this, the more the answer seems to be that Bob
should run his own keyserver and publish everything there first.  But i
don't see a way that Bob can indicate "check for revocations and
re-certifications at hkp://foo.example.net".  This seems like another
opportunity for "web bugs"-style shenanigans, though.

	--dkg

--------------enigE21A46F83D26E51F0ECFE6A0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigE21A46F83D26E51F0ECFE6A0--

Cc: IETF OpenPGP Working Group <[email-masked]>
From: David Shaw <[email-masked]>
To: Daniel Kahn Gillmor <[email-masked]>
Subject: Re: Preferred Key Server subpacket in non-self-signature?
Date: Tue, 28 Apr 2009 11:50:48 -0400
Sender: [email-masked]

On Apr 28, 2009, at 10:31 AM, Daniel Kahn Gillmor wrote:

> I'm trying to understand the preferred key server subpacket [0] and  
> how
> one might reasonably respect it in an implementation without causing
> potential for things that are the OpenPGP equivalent of "web bugs",  
> but
> while still keeping it useful.
>
> While looking into this, it occured to me that the RFC doesn't
> explicitly say that the Preferred Key Server subpacket must only  
> reside
> on a self-signature.  So, what would it mean if the Preferred Key  
> Server
> subpacket was included in a third-party certification?

I would say it means "Here is how the person who issued that  
certification wants you to get his key".  The same thing applies if  
the preferred keyserver packet was included on a regular data  
signature (which GPG supports, by the way).

> For example, Alice has an OpenPGP with her User ID "Alice".  Bob meets
> Alice, checks fingerprints, and certifies her User ID with a signature
> type 0x10.  But his signature contains a Preferred Key Server sub- 
> packet
> that points back to http://bob.example.org/alice
>
> Carol imports Alice's key, but wants to be sure that she has the  
> latest
> updates, revocations, and so forth, so she asks her OpenPGP client
> (which defaults to using pool.sks-keyservers.net) to refresh from the
> keyservers.  What should Carol's OpenPGP client do in this case?

Her choice, really.  Bob has made a statement that he provides his key  
at a particular address.  It's up to Carol (or Carol's client) to  
decide if she wants to respect that.  She may have reasons (web bug  
behavior) not to follow Bob's statement.  If Bob doesn't put his key  
on keyservers (good luck to Bob, there), then there may be no other  
way to get the key other than following Bob's statement.  Depending on  
how Carol is calculating the validity of Alice's key, Carol may not  
need Bob's key at all - after all Bob is just another signature on  
Alice's key.  Unless Carol is doing some sort of trust calculation,  
and her trust path to Alice runs through Bob, Bob's signature is not  
really relevant here.

> What about in the case where the Preferred Key Server subpacket is on
> Alice's self-sig?  What about two different Preferred Key Server
> subpackets (one from Alice, one from Bob)?

If there is a preferred keyserver subpacket on Alice's self-sig, then  
it was issued by Alice, and the recipient can either follow it or not,  
as they like.  I'm not sure I follow where Bob's subpacket comes in  
here.

David

Date: Tue, 28 Apr 2009 10:31:57 -0400
From: Daniel Kahn Gillmor <[email-masked]>
To: IETF OpenPGP Working Group <[email-masked]>
Subject: Preferred Key Server subpacket in non-self-signature?
OpenPGP: id=D21739E9
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE4726979739119440AB6057F
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm trying to understand the preferred key server subpacket [0] and how
one might reasonably respect it in an implementation without causing
potential for things that are the OpenPGP equivalent of "web bugs", but
while still keeping it useful.

While looking into this, it occured to me that the RFC doesn't
explicitly say that the Preferred Key Server subpacket must only reside
on a self-signature.  So, what would it mean if the Preferred Key Server
subpacket was included in a third-party certification?

For example, Alice has an OpenPGP with her User ID "Alice".  Bob meets
Alice, checks fingerprints, and certifies her User ID with a signature
type 0x10.  But his signature contains a Preferred Key Server sub-packet
that points back to http://bob.example.org/alice

Carol imports Alice's key, but wants to be sure that she has the latest
updates, revocations, and so forth, so she asks her OpenPGP client
(which defaults to using pool.sks-keyservers.net) to refresh from the
keyservers.  What should Carol's OpenPGP client do in this case?

What about in the case where the Preferred Key Server subpacket is on
Alice's self-sig?  What about two different Preferred Key Server
subpackets (one from Alice, one from Bob)?

	--dkg

http://tools.ietf.org/html/rfc4880#section-5.2.3.18

--------------enigE4726979739119440AB6057F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigE4726979739119440AB6057F--

Date: Mon, 06 Apr 2009 16:31:29 -0300
From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Organization: GNU/Buanzo
To: =?UTF-8?B?SsSBbmlzIFJvxI3EgW5z?= <[email-masked]>
CC: Wim Lewis <[email-masked]>, [email-masked]
Subject: Re: openpgp signing encrypting to understand by PGP Desktop.
OpenPGP: id=6857704D
Sender: [email-masked]

Sorry to hijack the thread... but if there's someone from PGP Inc here, I'd really like to see if
it'd be possible to obtain a license for development purposes... I'd like to integrate commercial
PGP into my Enigform firefox extension (Secure session management, http request/response signing,
etc)....

- --
Arturo "Buanzo" Busleiman / Arturo Busleiman @ 4:900/107
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net

Date: Mon, 06 Apr 2009 22:18:01 +0300
From: =?UTF-8?B?SsSBbmlzIFJvxI3EgW5z?= <[email-masked]>
To: Wim Lewis <[email-masked]>
CC: [email-masked]
Subject: Re: openpgp signing encrypting to understand by PGP Desktop.
Sender: [email-masked]

Thanks,
This helped me! I just removed literal data generation from my source 
and PGP desktop understood it correctly!
Wim Lewis wrote:
>
> On Apr 3, 2009, at 2:52 PM, Jānis Ročāns wrote:
>> Last few days I was trying to understand data encryption and signing. 
>> I am using JAVA to collect data into String from database, and need 
>> to sent them automatically by e-mail in attachment encrypted and 
>> signed. I got them first signed, then encrypted, but the PGP Desktop 
>> finds it only encrypted. To verify, I need to decrypt, the result is 
>> a pgp file again, that now I can verify. But I believe, that this all 
>> i did is wrong, so can you tell me, how to make the signed and 
>> encrypted file fully recognized by PGP desktop?
>
> I might not correctly understand the problem, but no one else has 
> spoken up, so I will jump in. I think what is happening is that, by 
> signing and then encrypting, you are not generating exactly the same 
> message format that PGP will when told to sign and encrypt at the same 
> time.
>
> What you want is a message with the following structure:
>
>  [Public-key-encrypted session key]
>  [Session-key-encrypted data:
>     [Literal packet: "Blah blah blah..."]
>     [Signature packet] ]
>
> But what you are probably producing is:
>
>  [Public-key-encrypted session key]
>  [Session-key-encrypted data:
>     [Literal packet: "[Literal packet: "Blah blah blah..."]
>                       [Signature packet]" ] ]
>
> When PGP unwraps the message, it stops when it encounters the 
> "Literal" packet, and considers that packet's contents to be the body 
> of the message.
>
> If for some reason you can't sign and encrypt in the same step, I 
> think you can use gnupg's --no-literal option to tell it not to wrap 
> the contents in a "Literal" packet. Of course this will result in an 
> invalid message unless you are giving it data which is already a 
> properly formed sequence of PGP packets, so it's not the best way to 
> use gnupg in general.
>
> You can use gnupg's --list-packets option to list the sequence of 
> packets in a message. (If you do, you will notice some additional 
> packet types in a normal message, which I ignored for simplicity's 
> sake...)
>
>
>
>

Cc: [email-masked]
From: Wim Lewis <[email-masked]>
Subject: Re: openpgp signing encrypting to understand by PGP Desktop.
Date: Sun, 5 Apr 2009 15:18:27 -0700
To: =?UTF-8?Q?J=C4=81nis_Ro=C4=8D=C4=81ns?= <[email-masked]>
Sender: [email-masked]

On Apr 3, 2009, at 2:52 PM, J=C4=81nis Ro=C4=8D=C4=81ns wrote:
> Last few days I was trying to understand data encryption and =20
> signing. I am using JAVA to collect data into String from database, =20=

> and need to sent them automatically by e-mail in attachment =20
> encrypted and signed. I got them first signed, then encrypted, but =20
> the PGP Desktop finds it only encrypted. To verify, I need to =20
> decrypt, the result is a pgp file again, that now I can verify. But =20=

> I believe, that this all i did is wrong, so can you tell me, how to =20=

> make the signed and encrypted file fully recognized by PGP desktop?

I might not correctly understand the problem, but no one else has =20
spoken up, so I will jump in. I think what is happening is that, by =20
signing and then encrypting, you are not generating exactly the same =20
message format that PGP will when told to sign and encrypt at the =20
same time.

What you want is a message with the following structure:

  [Public-key-encrypted session key]
  [Session-key-encrypted data:
     [Literal packet: "Blah blah blah..."]
     [Signature packet] ]

But what you are probably producing is:

  [Public-key-encrypted session key]
  [Session-key-encrypted data:
     [Literal packet: "[Literal packet: "Blah blah blah..."]
                       [Signature packet]" ] ]

When PGP unwraps the message, it stops when it encounters the =20
"Literal" packet, and considers that packet's contents to be the body =20=

of the message.

If for some reason you can't sign and encrypt in the same step, I =20
think you can use gnupg's --no-literal option to tell it not to wrap =20
the contents in a "Literal" packet. Of course this will result in an =20
invalid message unless you are giving it data which is already a =20
properly formed sequence of PGP packets, so it's not the best way to =20
use gnupg in general.

You can use gnupg's --list-packets option to list the sequence of =20
packets in a message. (If you do, you will notice some additional =20
packet types in a normal message, which I ignored for simplicity's =20
sake...)

Date: Sat, 04 Apr 2009 00:52:58 +0300
From: =?UTF-8?B?SsSBbmlzIFJvxI3EgW5z?= <[email-masked]>
To: [email-masked]
Subject: openpgp signing encrypting to understand by PGP Desktop.
Sender: [email-masked]

Good morning!
Last few days I was trying to understand data encryption and signing. I 
am using JAVA to collect data into String from database, and need to 
sent them automatically by e-mail in attachment encrypted and signed. I 
got them first signed, then encrypted, but the PGP Desktop finds it only 
encrypted. To verify, I need to decrypt, the result is a pgp file again, 
that now I can verify. But I believe, that this all i did is wrong, so 
can you tell me, how to make the signed and encrypted file fully 
recognized by PGP desktop? For newbie it is hard to understand all the 
things happening in these processes.
Thanks a lot,
Jānis Ročāns.