Subject: 论文征稿：

From: "jrhlj" <[email-masked]>
Date: Sun, 31 Jul 2005 00:25:19 +0800

论文征稿：
《黑龙江科技信息》杂志是经国家科技部和国家新闻出版总署批准在国内外公开发行的大型综合性科技经济类学术期刊。由黑龙江省科学技术协会主办，国内外公开发行，为半月刊。国内统一刊号：CN23-1400/G3；国外发行代号：ISSN  1673-1328。国际标准大16开本。本刊向广大科研工作者、文教工作者、工程技术人员、农业技术人员等等征求科技、文教、企业、事业等各个方面的稿件和学术论文，文字要求在3000左右为宜。
另外，我社与很多国家一级杂志社有业务往来，有的甚至已在我社建了工作站，如您的论文需在国家一级杂志上发表，我们可在24小时内帮你通过发刊审核。并预定刊发日期。
来稿免收审稿费，投稿24小时回复。投稿须注明作者姓名、单位、邮编和地址，电话、E-mail:，以便投寄书面通知和邮寄样刊。稿件发到  [email-masked] 或 [email-masked] （欢迎网上投稿请两个邮箱同时发信，以免收不到）。
联系人：王  兰
电话：0451-82614164（办）  82620426（办）  手机：13946004090
地址：哈尔滨市南岗区宣信街15号  黑龙江省政府综合办公楼528/529室  

Date: Thu, 28 Jul 2005 16:45:35 +0100
From: Ian Brown <[email-masked]>
To: Derek Atkins <[email-masked]>
CC: [email-masked]
Subject: Re: Draft Agenda for OpenPGP Meeting
Sender: [email-masked]

Derek Atkins wrote:
> Here's the draft agenda for the OpenPGP meeting.  Please let
> me know if you have any additions/subtractions.  This agenda
> assumes that one of the PFS guys can make a presentation.

Unfortunately Ben Laurie will be in Baltimore and I can't be at the IETF 
meeting until Tuesday evening. Don't think Adam Back can attend either :(

To: [email-masked]
Subject: Re: self-sign v3
Cc: [email-masked]
Date: Wed, 27 Jul 2005 13:45:46 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

welintin son writes:
> I'm trying to export a key in PGP v3, but unfortunaly i'm having
> problems with the
> self-signature type 0x10. I can export the PubKey but the hash doesn't
> match, i did like is
> explained in the RFC 2440 as follows :
> ...
> I did like this : 
>
> MD5(0x99(pkt type), 0x00  0x80(key size - big endian), 128bytes(key data), 
> 26bytes(user name - just the "name <email>"), 0x10(sig class), 0x42
> 0xe7 0xc9 0x18(creation time timestamp - big endian));

I think probably what you did wrong is that your 128 bytes of key data is
not the entire pubkey packet, but rather just the key modulus.  You need
to hash the structure described in section 5.5.2: the version number,
key creation time, etc.  This will typically be more than 128 bytes, for
a 1024 bit key.  The two length bytes should reflect the size of the key
data packet, and then the key data packet body should be hashed.  The rest
of it - the user name and the 5 bytes from the signature packet - looks OK.

Hope this helps -

Hal "Finney

Date: Wed, 27 Jul 2005 14:56:39 -0300
From: welintin son <[email-masked]>
Reply-To: welintin son <[email-masked]>
To: [email-masked]
Subject: Re: self-sign v3
Sender: [email-masked]

Hi,

I'm trying to export a key in PGP v3, but unfortunaly i'm having
problems with the
self-signature type 0x10. I can export the PubKey but the hash doesn't
match, i did like is
explained in the RFC 2440 as follows :

5.2.4. Computing Signatures

..."When a signature is made over a key, the hash data starts with the
octet 0x99, followed by a two-octet length of the key, and then body
of the key packet."...

..."A certification signature (type 0x10 through 0x13) hashes the user id
   being bound to the key into the hash context after the above data. A
   V3 certification hashes the contents of the name packet, without any
   header."...

..."Once the data body is hashed, then a trailer is hashed. A V3
   signature hashes five octets of the packet body, starting from the
   signature type field. This data is the signature type, followed by
   the four-octet signature time."...

I did like this : 

MD5(0x99(pkt type), 0x00  0x80(key size - big endian), 128bytes(key data), 
26bytes(user name - just the "name <email>"), 0x10(sig class), 0x42
0xe7 0xc9 0x18(creation time timestamp - big endian));

i'm encripting with the private key that is correlated with the public
key that i'm
exporting.

Can anyone help me?

Thanks in advance,

2005/7/26, welintin son <[email-masked]>:
> Hi i'm having troubles trying to make a self-sign to use in a public key packet.
> I'm using this way :
> 
> MD5(0x99(1byte), KEYLEN(2bytes - big endian), KEYDATA, USERID,
> SIGNATURE TYPE(0x10 - 1byte),
 CREATION TIME(4bytes - big endian))
> 
> this hash is encrypted using the pubkey i'm exporting and the pkcs1 padding.
> 
> 
> 
> Thanks in advance,
>

From: Derek Atkins <[email-masked]>
To: [email-masked]
Subject: Draft Agenda for OpenPGP Meeting
Date: Wed, 27 Jul 2005 11:24:48 -0400
Sender: [email-masked]

Here's the draft agenda for the OpenPGP meeting.  Please let
me know if you have any additions/subtractions.  This agenda
assumes that one of the PFS guys can make a presentation.

TUESDAY, August 2, 2005
0900-1000 Morning Session I
SEC   openpgp   An Open Specification for Pretty Good Privacy WG

0900-0905: Introductions and Agenda Bashing
0905-0925: OpenPGP Draft Status (draft-ietf-openpgp-rfc2440bis)
0925-0930: Next Steps
0930-0940: OpenPGP Mail Header
0940-0950: PFS in OpenPGP
0950-1000: Open Discussion

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Tue, 26 Jul 2005 16:09:11 -0300
From: welintin son <[email-masked]>
Reply-To: welintin son <[email-masked]>
To: [email-masked]
Subject: self-sign v3
Sender: [email-masked]

Hi i'm having troubles trying to make a self-sign to use in a public key packet.
I'm using this way :

MD5(0x99(1byte), KEYLEN(2bytes - big endian), KEYDATA, USERID,
SIGNATURE TYPE(0x10 - 1byte), CREATION TIME(4bytes - big endian))

this hash is encrypted using the pubkey i'm exporting and the pkcs1 padding.

Thanks in advance,

From: Simon Josefsson <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Subject: Re: Meet in Paris?
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 26 Jul 2005 10:01:54 +0200
Sender: [email-masked]

Sure!  I can raise the open issues and invite more feedback.

Thanks,
Simon

Derek Atkins <[email-masked]> writes:

> I'd be happy to put you on for 5-10 minutes?  I really don't
> think it will slow down 2440bis.
>
> -derek
>
> Simon Josefsson <[email-masked]> writes:
>
>> Derek Atkins <[email-masked]> writes:
>>
>>> Hi,
>>>
>>> Do the members of this working group feel we need a meeting
>>> in Paris?  I think we might want to meet in order to consider
>>> work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
>>> that's been proposed).
>>
>> I would likely be around to talk about the OpenPGP mail header [1], if
>> there is interest.  Feedback from OpenPGP experts on the usefulness of
>> adding a "supports" token to the header is one open issue that may be
>> useful to discuss.
>>
>> I'd hate to see anything slow down 2440bis further though.
>>
>> [1] http://josefsson.org/openpgp-header/
>>
>>
>
> -- 
>        Derek Atkins                 617-623-3745
>        [email-masked]             www.ihtfp.com
>        Computer and Internet Security Consultant

From: Derek Atkins <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: Meet in Paris?
Date: Mon, 25 Jul 2005 20:47:10 -0400
Sender: [email-masked]

Ben,

Any chance you could send a surrogate to present?  I think it
would be very useful if someone could stand up for 5-10 minutes
and describe your PFS proposal.

-derek

Ben Laurie <[email-masked]> writes:

> Unfortunately, IETF decided to schedule up against USENIX Security, so 
> I'll be in Baltimore, not Paris.
>
> Cheers,
>
> Ben.
>
> -- 
>>>>ApacheCon Europe<<<                   http://www.apachecon.com/
>
> http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
>
> "There is no limit to what a man can do or how far he can go if he
> doesn't mind who gets the credit." - Robert Woodruff
>
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

From: Derek Atkins <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: Meet in Paris?
Date: Mon, 25 Jul 2005 20:47:57 -0400
Sender: [email-masked]

I'd be happy to put you on for 5-10 minutes?  I really don't
think it will slow down 2440bis.

-derek

Simon Josefsson <[email-masked]> writes:

> Derek Atkins <[email-masked]> writes:
>
>> Hi,
>>
>> Do the members of this working group feel we need a meeting
>> in Paris?  I think we might want to meet in order to consider
>> work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
>> that's been proposed).
>
> I would likely be around to talk about the OpenPGP mail header [1], if
> there is interest.  Feedback from OpenPGP experts on the usefulness of
> adding a "supports" token to the header is one open issue that may be
> useful to discuss.
>
> I'd hate to see anything slow down 2440bis further though.
>
> [1] http://josefsson.org/openpgp-header/
>
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

Date: Sat, 23 Jul 2005 05:31:15 +0100
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
CC: Hal Finney <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Section 5.2.3 of latest draft: bis14.
Sender: [email-masked]

Jon Callas wrote:
>> I am diffing against bis-12 which is the only old version I have here.
>> Another change I notice is that the preferred algorithm signature
>> subpackets in 5.2.3.7, 5.2.3.8 and 5.2.3.9 have their contents changed
>> from a "sequence" of one-octet values to an "array" of one-octet values.
>> However we do not otherwise define "array".  Is that word really
>> better than "sequence" here?  To me, a sequence of values is a plainer
>> description while an array perhaps connotes a somewhat more complex
>> data structure.  Of course in C an array is simply bytes in memory so if
>> that is how it is being read, OK.  I'm just worried that an implementor
>> is going to look for a definition of array.
>>
> 
> I'm worried that an implementor is going to look for a definition of
> definition. This is something I worry about with each "clarification" we
> make, that N people think it's better and M people think it's worse.
> This is why I am resistant to clarifications (even though it seems I
> make a lot of them).
> 
> I agree with you that "sequence" is clearer than "array" and given how
> much of the text is either yours or mine, it's no wonder it used to say
> "sequence." I'm more than happy to change it back.
> 
> Let me meditate upon it for a bit.

Wasn't the point here that some things were called a "sequence" and some
an "array", and they should all be called the same thing?

FWIW, I find sequence less clear than array. My maths background makes
me suspect that there's some extra subtlety that I'm missing when I see
"sequence".

However, I'm more concerned about the inconsistency, which is definitely
confusing.

Date: Thu, 21 Jul 2005 18:03:08 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Literal+Literal
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

A while back (2003), I noticed a inconsistency in the draft.  The
problem was one of those fiddly grammar things: some text in the draft
said that multiple literal packets in a row were legal, and some other
text said that it wasn't.  For example, in that draft,
COMPRESSED(literal+literal) was legal in section 5.6, and illegal in
10.2.

To resolve that, I suggested that we simply change 10.2 (the grammar
section) to allow literal+literal.  That's how the draft reads now.
Several people have commented that this is raising more problems than
it is solving, and they're right.  Literal+literal raises a whole
collection of issues with how to hash the data in a construction like
onepass+literal+literal+sig.  It also requires parsers to be more
complex (though at least the parsers in PGP and GPG always worked this
way).

I'd like to change the text to fix this, and solve this problem a
different way: rather than resolve the inconsistency by making
literal+literal legal everywhere, better to resolve the inconsistency
by making literal+literal illegal everywhere.

The specific changes would be:

Section 5.6 (Compressed Data Packet) - change "literal data packets"
to "a literal data packet".

Section 5.7 (Symmetrically Encrypted Data Packet) - change "literal
data packets" to "a literal data packet".

Section 5.13 (Sym. Encrypted Integrity Protected Data Packet) - change
"literal data packets or compressed data packets" to "a literal data
packet or compressed data packet".

Then in section 10.2, revert from this:

    Literal Message :- Literal Data Packet |
                      Literal Message, Literal Data Packet.

to this:

    Literal Message :- Literal Data Packet

David

Cc: [email-masked], Hal Finney <[email-masked]>, [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Section 5.2.3 of latest draft: bis14.
Date: Thu, 21 Jul 2005 11:03:26 -0700
To: Marko Kreen <[email-masked]>
Sender: [email-masked]

>> Many implementers have taken this advice to heart for any data that is
>> symmetrically encrypted and for which the session key is public-key
>> encrypted. In this case, the quick check is not needed as the public
>> key encryption of the session key should guarantee that it is the 
>> right
>
> Shouldn't this be about decryption with secret key?
>

In the case of what I'll call a "normal" OpenPGP blob, you have data 
encrypted by a session key, and that session key was encrypted to a 
public key. In this case, you get the session key by unwrapping it from 
the public key, not from a passphrase, and consequently, it is 
unnecessary to perform the quick check.

This defeats an attack where someone damages a blob and has you decrypt 
the damaged blob and pries at the encryption by means of the quick 
check.

	Jon

To: [email-masked]
Subject: Re: Section 5.2.3 of latest draft: bis14.
Date: Thu, 21 Jul 2005 09:20:58 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Jon Callas writes:
> On 15 Jul 2005, at 4:47 PM, Hal Finney wrote:
> > This definition could be interpreted to mean that the data set includes
> > the two-octet scalar count.  In fact, in the layout in 5.2.3 the data
> > set does not include the scalar count.  5.2.3.1 could be reworded to 
> > say
> > "A subpacket data set consists of zero or more signature subpackets,
> > AND IS preceded by a two-octet scalar count..."
> >
>
> Personally, I'd just remove the comma. I also removed a semicolon:
>
> A subpacket data set consists of zero or more signature subpackets 
> preceded by a two-octet scalar count of the length in octets of all the 
> subpackets. A pointer incremented by this number will skip over the 
> subpacket data set.

This seems to say that a subpacket data set includes the two-octet
count field.  That is inconsistent with how it is used in 5.2.3.

This got dropped:

> > Section 5.9 on literal packets:
> >
> >       - File name as a string (one-octet length, followed by a file
> >         name). This may be a zero-length string. Commonly, if the source
> >         of the encrypted data is a file, this will be the name of the
> >         encrypted file. An implementation MAY consider the file name in
> >         the literal packet to be a more authoritative name than the
> >         actual file name.
> >
> > I know we discussed this here, but I'm not sure this is right yet.
> > What is the "actual file name"?  And what does it mean for a name to
> > be authoritative?  This is making some assumptions about processing flow
> > which may not be correct.  I think "actual file name" means the name of
> > the file being decrypted, assuming that the encrypted data actually came
> > from a file.  But then, usually the encrypted file name is not used for
> > the decrypted data, rather some modification of that file name is used,
> > so perhaps that is the "actual file name"?
> >
> > Maybe we could change the last sentence to "When decrypting, an
> > implementation MAY use this name as the name of an output file."
> > That would hint what we mean it to be used for.  Or maybe just leave the
> > last sentence off entirely and just say that this is commonly the name
> > of the encrypted file, let the implementor figure out what if anything
> > he wants to do with it.

> > Section 13, Security Considerations:

> Here's the final edit I have:
>
>
> Many implementers have taken this advice to heart for any data that is 
> symmetrically encrypted and for which the session key is public-key 
> encrypted. In this case, the quick check is not needed as the public 
> key encryption of the session key should guarantee that it is the right 
> session key. In other cases, the implementation should use the quick 
> check with care.
>
> On the one hand, there is a danger to using it if there is a random 
> oracle that can leak information to an attacker. In plainer language, 
> there is a danger to using the quick check if timing information about 
> the check can be exposed to an attacker, particularly via an automated 
> service that allows rapidly repeated queries
>
> On the other hand, it is inconvenient to the user to be informed that 
> they typed in the wrong passphrase only after a petabyte of data is 
> decrypted. There are many cases in cryptographic engineering where the 
> implementer must use care and wisdom, and this is one.

Well, I'm still not that comfortable with the wisdom and heart business,
but after recently seen another showing of the Wizard of Oz I'd suggest
throwing in a reference to courage and then we'll be done...

Seriously, it's not that big a deal, it's not how I would write it but
I think the information is fine, if everyone else is comfortable with it.

Hal

From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
Subject: Re: Signer's User ID
Date: Thu, 21 Jul 2005 14:30:08 +0100
Cc: [email-masked]
Sender: [email-masked]

On Thursday 21 July 2005 14:15, Werner Koch wrote:
> On Thu, 21 Jul 2005 13:11:56 +0100, Ian Grigg said:
> 
> > But it recalls to mind what we do in contract issuance.  In
> > our model, we add strings to every keyId in the chain.  These
> > "roles" then inform the software of how to prepare and check
> 
> This works well when using a new key for each role. 
> 
> Assuming you would add the rules as different UID to one key you can't
> see from a signature which role/UID was used to sign the document.
> The Signer's User ID is a solution to this; however it is far easier
> to create separate keys.

I agree entirely, that's in fact what we do, and
the software rejects any additional roles that
might be present.

There's also the issue that generally different
roles have different security models, so for
example ones [certification] key might be better
off locked in the safe.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Signer's User ID
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Thu, 21 Jul 2005 15:15:11 +0200
Sender: [email-masked]

On Thu, 21 Jul 2005 13:11:56 +0100, Ian Grigg said:

> But it recalls to mind what we do in contract issuance.  In
> our model, we add strings to every keyId in the chain.  These
> "roles" then inform the software of how to prepare and check

This works well when using a new key for each role. 

Assuming you would add the rules as different UID to one key you can't
see from a signature which role/UID was used to sign the document.
The Signer's User ID is a solution to this; however it is far easier
to create separate keys.

> to the users.  That's very important in legal work as anything
> that hides intent in special packets leads to questions as to
> whether the software was doing the right thing.

Agreed.

Salam-Shalom,

   Werner

From: Ian Grigg <[email-masked]>
Subject: Re: Freeh testimony mentioning ADK (Re: Signature Subpacket 10?)
Date: Thu, 21 Jul 2005 13:25:46 +0100
Cc: OpenPGP <[email-masked]>
To: "Undisclosed.Recipients": ;
Sender: [email-masked]

The events of 1997-1998 were pretty charged and
created a split in the pgp community.  My intent was
not to re-open that battle, but to point out to Ben
that it is unlikely that the subpacket concerned will
ever be documented.  It's status as "undocumented"
is more than just accidental, and if he or anyone
wants to figure it out he's just going to have to ask
everyone in private email.

So I suggest we leave it there.  Energies spent on
finishing the darn thing would be energies much
better spent.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
Subject: Re: Signer's User ID
Date: Thu, 21 Jul 2005 13:11:56 +0100
Cc: [email-masked]
Sender: [email-masked]

On Thursday 21 July 2005 06:39, Werner Koch wrote:

> I'd like to have a clarification of the signature subpacket
> 
>   5.2.3.22. Signer's User ID
> 
>     (String)
> 
>     This subpacket allows a keyholder to state which User ID is
>     responsible for the signing. Many keyholders use a single key for
>     different purposes, such as business communications as well as
>     personal communications. This subpacket allows such a keyholder to
....
> I don't care much about this but given that such a subpacket has been
> defined but is not widely used - if at all - we might want to define
> it in a stricter way.

Or drop it or mark it deprecated.  If it's been this long and
nobody noticed, then clean it out and make things simpler?

I'm not entirely sure that I understand what the intent is
(which was partly your point!).

But it recalls to mind what we do in contract issuance.  In
our model, we add strings to every keyId in the chain.  These
"roles" then inform the software of how to prepare and check
the signature chain on contracts.  The ones in the chain
should be like this:

    [certification] Iang <iang@...>
    [contract] Iang <iang@...>

That is, a key listing [certification] should sign a key listing
[contract] which signs the contract.  The software checks
all that.

Now, if this is the same sort of thing that the "Signer's User
Id" packet is intended to achieve, I'd suggest that this clear
text method of specifying roles in the keyId may be superior
as it does not require software support to indicate the intent
to the users.  That's very important in legal work as anything
that hides intent in special packets leads to questions as to
whether the software was doing the right thing.

Just some observations - I may be off base here in my
interpretation of what this subpacket does.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

Date: Thu, 21 Jul 2005 07:54:51 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signer's User ID
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Jul 21, 2005 at 10:32:50AM +0200, Jeroen Massar wrote:
> On Thu, 2005-07-21 at 07:39 +0200, Werner Koch wrote:
> > Hello!
> > 
> > I'd like to have a clarification of the signature subpacket
> > 
> >   5.2.3.22. Signer's User ID
> 
> <SNIP>
> 
> > OTOH, for applications it makes more sense to have just the vanilla
> > mail address (mailbox@domain) here.  This would make it easier to
> > compare a mail's From address to the actual signature.
> 
> As I actually never really took time to read the full spec, I didn't
> come across of this before, but this is indeed ideal for making keys
> distributed in nature.
> 
> "Solution" for making it distributed would be:
> http://www.imc.org/ietf-openpgp/mail-archive/msg11035.html

That message suggests adding the signer's name to signatures in some
manner, and then using that to hint to the keyserver which key to
fetch when verifying a signature.  It seems a fairly roundabout way to
get a key.

Why not just do this directly?  We already have a keyserver subpacket
(24), which is an URL, so it can even point to a web page.  If a
signer wants to give "how to get my key" information in their
signature, just point to it directly.

> Question to Werner: does gnupg support the above item, if not can we add
> it, and secondly could we have gnupg then derive the keyserver from it
> as I noted before? (read: want a patch?)

GnuPG already supports what I said above.  And if you set
auto-key-retrieve, it'll even fetch the key for you automatically when
it sees a signature with such information.

David

Date: Thu, 21 Jul 2005 07:47:43 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signer's User ID
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Jul 21, 2005 at 07:39:32AM +0200, Werner Koch wrote:
> 
> Hello!
> 
> I'd like to have a clarification of the signature subpacket
> 
>   5.2.3.22. Signer's User ID
> 
>     (String)
> 
>     This subpacket allows a keyholder to state which User ID is
>     responsible for the signing. Many keyholders use a single key for
>     different purposes, such as business communications as well as
>     personal communications. This subpacket allows such a keyholder to
>     state which of their roles is making a signature.
> 
>     This subpacket is not appropriate to use to refer to a User
>     Attribute packet.
> 
> It is not clear to me whether the string should be a verbatim copy of
> the content of a User ID packet or some other information.  The second
> paragraph could be viewed as a hint for a verbatim copy.

I suggested that second paragraph when I was documenting the user
attribute / photo ID stuff.  There are some problems using a Signer's
User ID with attribute IDs, both in size and in knowing how to parse
the thing.

A while back, I posted a proposal to fix this:

  http://www.imc.org/ietf-openpgp/mail-archive/msg04775.html

David

Date: Thu, 21 Jul 2005 07:08:42 -0400
From: Adam Back <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>, Adam Back <[email-masked]>, Ian Grigg <[email-masked]>
Subject: Freeh testimony mentioning ADK (Re: Signature Subpacket 10?)
Sender: [email-masked]

On Wed, Jul 20, 2005 at 05:21:55PM -0700, Jon Callas wrote:
> >The notion was that it should go
> >in the standard, but that was politically charged
> >at the time - indeed Loius Freeh stood up in
> >front of Congress and used this very feature as
> >proof that it was possible to force all crypto
> >programs to escrow messages for the FBI...
> >
> 
> No. That's completely false. I have no idea where you heard that, but 
> that's not at all true.
>
> This is so false that the opposite is true. The FBI hated it because it 
> was a completely voluntary system with easy workarounds. The FBI hated 
> it, which is one of the amusing ironies about the thing.

Ian's right, you're wrong, it is true.  

I definitely recall this event in testimony from Freeh being in the
news, using PGP's ADK/ARR/???  (several renames I forget all the
names) feature as an example of how key recovery was possible.

Probably you can dig it up with google and the right search terms.

Adam

Subject: Re: Signer's User ID
From: Jeroen Massar <[email-masked]>
To: Werner Koch <[email-masked]>
Cc: [email-masked]
Organization: Unfix
Date: Thu, 21 Jul 2005 10:32:50 +0200
Sender: [email-masked]

--=-mRzW3/KepzPdoLk5Rrpe
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-07-21 at 07:39 +0200, Werner Koch wrote:
> Hello!
>=20
> I'd like to have a clarification of the signature subpacket
>=20
>   5.2.3.22. Signer's User ID

<SNIP>

> OTOH, for applications it makes more sense to have just the vanilla
> mail address (mailbox@domain) here.  This would make it easier to
> compare a mail's From address to the actual signature.

As I actually never really took time to read the full spec, I didn't
come across of this before, but this is indeed ideal for making keys
distributed in nature.

"Solution" for making it distributed would be:
http://www.imc.org/ietf-openpgp/mail-archive/msg11035.html

I haven't seen the agenda yet and it is not online, but it might be
interresting to have a chat about this. The slot is monday morning from
09:00 - 10:00...

Question to Werner: does gnupg support the above item, if not can we add
it, and secondly could we have gnupg then derive the keyserver from it
as I noted before? (read: want a patch?)

Greets,
 Jeroen

--=-mRzW3/KepzPdoLk5Rrpe
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-mRzW3/KepzPdoLk5Rrpe--

To: [email-masked]
Subject: Signer's User ID
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Thu, 21 Jul 2005 07:39:32 +0200
Sender: [email-masked]

Hello!

I'd like to have a clarification of the signature subpacket

  5.2.3.22. Signer's User ID

    (String)

    This subpacket allows a keyholder to state which User ID is
    responsible for the signing. Many keyholders use a single key for
    different purposes, such as business communications as well as
    personal communications. This subpacket allows such a keyholder to
    state which of their roles is making a signature.

    This subpacket is not appropriate to use to refer to a User
    Attribute packet.

It is not clear to me whether the string should be a verbatim copy of
the content of a User ID packet or some other information.  The second
paragraph could be viewed as a hint for a verbatim copy.

OTOH, for applications it makes more sense to have just the vanilla
mail address (mailbox@domain) here.  This would make it easier to
compare a mail's From address to the actual signature.

I don't care much about this but given that such a subpacket has been
defined but is not widely used - if at all - we might want to define
it in a stricter way.

Shalom-Salam,

   Werner

From: Jon Callas <[email-masked]>
Subject: Re: Signature Subpacket 10?
Date: Wed, 20 Jul 2005 17:21:55 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 30 Jun 2005, at 4:16 AM, Ian Grigg wrote:

> A little background.  This was added by the old
> PGP Inc company for commercial users so as to
> escrow email.  If a key had this subpacket, you
> would encrypt to that additional key as well.
>

Not precisely true. It's a way to have data access to any encrypted 
data.

> The notion was that it should go
> in the standard, but that was politically charged
> at the time - indeed Loius Freeh stood up in
> front of Congress and used this very feature as
> proof that it was possible to force all crypto
> programs to escrow messages for the FBI...
>

No. That's completely false. I have no idea where you heard that, but 
that's not at all true.

This is so false that the opposite is true. The FBI hated it because it 
was a completely voluntary system with easy workarounds. The FBI hated 
it, which is one of the amusing ironies about the thing.

> The compromise that was reached was that it
> not be documented in the standard.  I don't
> know if GPG implements it, or even if it the PGP
> line still includes it.  I think architecturally speaking,
> such a feature is better off in the proxy products,
> and layered over the top at the admin level
> rather than put in the tech.  I think it is relatively
> safe to ignore it.
>

It's part of PGP. It's also patented. US patent 6,314,190.

	Jon

Date: Thu, 21 Jul 2005 01:22:39 +0300
From: Marko Kreen <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Hal Finney <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Section 5.2.3 of latest draft: bis14.
Sender: [email-masked]

On Wed, Jul 20, 2005 at 02:51:48PM -0700, Jon Callas wrote:
> Here's the final edit I have:
> 
> 
> Many implementers have taken this advice to heart for any data that is 
> symmetrically encrypted and for which the session key is public-key 
> encrypted. In this case, the quick check is not needed as the public 
> key encryption of the session key should guarantee that it is the right 

Shouldn't this be about decryption with secret key?

> session key. In other cases, the implementation should use the quick 
> check with care.

-- 
marko

Cc: [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Section 5.2.3 of latest draft: bis14.
Date: Wed, 20 Jul 2005 14:51:48 -0700
To: [email-masked] ("Hal Finney")
Sender: [email-masked]

On 15 Jul 2005, at 4:47 PM, Hal Finney wrote:

>
> This is definitely an error and needs to be fixed.
>

Fixed.

> A couple of other relatively minor points relating to this section.
>
> We now use the term "data set" for the hashed and unhashed subpackets:
>
>       - Hashed subpacket data set. (zero or more subpackets)
>
>       - Two-octet scalar octet count for the following unhashed
>         subpacket data. Note that this is the length in octets of all 
> of
>         the unhashed subpackets; a pointer incremented by this number
>         will skip over the unhashed subpackets.
>
>       - Unhashed subpacket data set. (zero or more subpackets)
>
> "Data set" is defined in the next section, 5.2.3.1:
>
>     A subpacket data set consists of zero or more signature subpackets,
>     preceded by a two-octet scalar count of the length in octets of all
>     the subpackets; a pointer incremented by this number will skip over
>     the subpacket data set.
>
> This definition could be interpreted to mean that the data set includes
> the two-octet scalar count.  In fact, in the layout in 5.2.3 the data
> set does not include the scalar count.  5.2.3.1 could be reworded to 
> say
> "A subpacket data set consists of zero or more signature subpackets,
> AND IS preceded by a two-octet scalar count..."
>

Personally, I'd just remove the comma. I also removed a semicolon:

A subpacket data set consists of zero or more signature subpackets 
preceded by a two-octet scalar count of the length in octets of all the 
subpackets. A pointer incremented by this number will skip over the 
subpacket data set.

> Another slight wording inconsistency is in 5.2.3:
>
>     The data being signed is hashed, and then the signature data from
>     the version number through the hashed subpacket data (inclusive) is
>     hashed. The resulting hash value is what is signed.
>
> This "x is hashed, and then y is hashed" business has caused confusion
> for implementors.  5.2.2 fixed the wording for V3 packets:
>
>     The concatenation of the data to be signed, the signature type and
>     creation time from the signature packet (5 additional octets) is
>     hashed. The resulting hash value is used in the signature 
> algorithm.
>
> We should make the same change for V4 packets in 5.2.3.  I don't know
> if there are any other places where we talk about hashing X and then
> Y and then Z instead of, as we should, hashing the contatenation of
> X and Y and Z.
>

How about:

The concatenation of the data being signed and the signature data from 
the version number through the hashed subpacket data (inclusive) is 
hashed. The resulting hash value is what is signed.  The left 16 bits 
of the hash are included in the signature packet to provide a quick 
test to reject some invalid signatures.

>
> I am diffing against bis-12 which is the only old version I have here.
> Another change I notice is that the preferred algorithm signature
> subpackets in 5.2.3.7, 5.2.3.8 and 5.2.3.9 have their contents changed
> from a "sequence" of one-octet values to an "array" of one-octet 
> values.
> However we do not otherwise define "array".  Is that word really
> better than "sequence" here?  To me, a sequence of values is a plainer
> description while an array perhaps connotes a somewhat more complex
> data structure.  Of course in C an array is simply bytes in memory so 
> if
> that is how it is being read, OK.  I'm just worried that an implementor
> is going to look for a definition of array.
>

I'm worried that an implementor is going to look for a definition of 
definition. This is something I worry about with each "clarification" 
we make, that N people think it's better and M people think it's worse. 
This is why I am resistant to clarifications (even though it seems I 
make a lot of them).

I agree with you that "sequence" is clearer than "array" and given how 
much of the text is either yours or mine, it's no wonder it used to say 
"sequence." I'm more than happy to change it back.

Let me meditate upon it for a bit.

>
> Section 5.5.2:
>
>     V2 keys are identical to V3 keys except for the deprecated V3 keys
>     except for the version number. An implementation MUST NOT generate
>     them and may accept or reject them as it sees fit.
>
> Two "except for"s here, it doesn't look right.
>

It's worse than that.

Here's the correction:

V2 keys are identical to the deprecated V3 keys except for the version 
number. An implementation MUST NOT generate them and may accept or 
reject them as it sees fit.

>
> Section 5.9 on literal packets:
>
>       - File name as a string (one-octet length, followed by a file
>         name). This may be a zero-length string. Commonly, if the 
> source
>         of the encrypted data is a file, this will be the name of the
>         encrypted file. An implementation MAY consider the file name in
>         the literal packet to be a more authoritative name than the
>         actual file name.
>
> I know we discussed this here, but I'm not sure this is right yet.
> What is the "actual file name"?  And what does it mean for a name to
> be authoritative?  This is making some assumptions about processing 
> flow
> which may not be correct.  I think "actual file name" means the name of
> the file being decrypted, assuming that the encrypted data actually 
> came
> from a file.  But then, usually the encrypted file name is not used for
> the decrypted data, rather some modification of that file name is used,
> so perhaps that is the "actual file name"?
>
> Maybe we could change the last sentence to "When decrypting, an
> implementation MAY use this name as the name of an output file."
> That would hint what we mean it to be used for.  Or maybe just leave 
> the
> last sentence off entirely and just say that this is commonly the name
> of the encrypted file, let the implementor figure out what if anything
> he wants to do with it.
>
>
>
> We refer to RFC 822 in two places, but that's been superceded by
> RFC 2822.
>

I only found one, unless you're counting the citation. I updated to be 
2822.

> The only reason I noticed this in my diffing was because we changed
> to put a space after RFC.  But in the references we have no space,
> e.g. [RFC 2045] became [RFC2045].  I guess it's OK to use a space in
> the text and no space in the references, but why not do it the same
> in both contexts?  I would vote for no space, it looks better to me,
> but your eyes may differ.
>

At the risk of sounding like the White Knight, the reason it is the way 
it is is that I consider (e.g.) "RFC 2045" to be the name of the RFC, 
whereas "[RFC2045]" is an identifier that is what the name is called, 
and years of programming has instilled in me an aversion to spaces 
there. Heck, I even usually put them in all upper case. (I recently 
cited 2440 as [OpenPGP] and the mere use of mixed case gave me pause.) 
Just as I'd never refer in English to Mister and Zuccherato's paper as 
"[MZ05]" that's still the identifier I used for it.

>
> Section 13, Security Considerations:
>
>      * In winter 2005, Serge Mister and Robert Zuccherato from Entrust
>        released a paper describing a way that the "quick check" in
>        OpenPGP CFB mode can be used with a random oracle to decrypt two
>        octets of every cipher block [MZ05]. They recommend as
>        prevention not using the quick check at all.
>
>        Many implementers have taken this advice to heart for any data
>        that is both symmetrically encrypted, but also the session key
>        is public-key encrypted. In this case, the quick check is not
>        needed as the public key encryption of the session key should
>        guarantee that it is the right session key. In other cases, the
>        implementation should use the quick check with care. On the one
>        hand, there is a danger to using it if there is a random oracle
>        that can leak information to an attacker. On the other hand, it
>        is inconvenient to the user to be informed that they typed in
>        the wrong passphrase only after a petabyte of data is decrypted.
>        There are many cases in cryptographic engineering where the
>        implementer must use care and wisdom, and this is another.
>
> This is good but I think some of the wording could be smoothed.   The
> first sentence of the second paragraph should not have a comma after
> the first part of the "both" clause, and "but" doesn't seem like the
> right connective.  I suggest,
>
>        Many implementers have taken this advice to heart for any data
>        that is symmetrically encrypted and for which the session key
>        is public-key encrypted.
>

Done.

> I also have a problem with "there is a danger to using it if there is
> a random oracle that can leak information".  This makes it sounds like
> the random oracle is some other entity independent of the 
> implementation.
> I would prefer to avoid the word "oracle" as not all implementors may 
> be
> familiar with the technical meaning, and in common use it has mystical
> or religious connotations.
>

But that's what it's called -- a random oracle.

> I think what we want is something like "there is a danger to using it
> if timing information about the check can be exposed to an attacker,
> particularly via an automated service that allows rapidly repeated
> queries".
>

I made a few edits. See below.

> Finally I think the last clause should say "and this is one" rather
> than "and this is another".
>

Done.

> I do have to add that I think this paragraph is perhaps a little 
> informal
> or even poetic for a security document.  Implementors "take things to
> heart" and use their "care and wisdom".  I could see an implementor
> wondering whether he was reading a spec or beginning a study of Zen.
> Maybe we should think about changing this to be a little more cool and
> just warn them that if they are going to use the check bits, they need
> to be aware of the danger of leaking timing data.  The content of the
> paragraph is good, it's just the style which struck me as being a bit 
> off.
> Again, your taste may differ.
>

Here's my thinking. This isn't a security document. It's a protocol 
document. If you want to be really picky, it's a data format document.

We cannot tell people in here everything to do. We can't tell them what 
to do in something as easy as speculative key ids (which I pick solely 
because we've been discussing it recently). We certainly can't tell 
them when it's proper to do a quick check and when it isn't.

We can and do, however, editorialize and wave a few flags and drop a 
few hints.

I'm glad that leaps out, because that's what I want. I don't want to 
say SHOULD NOT. I don't want to say MAY. I know my opinion is going to 
change on this at least once in the next five years. I want to say -- 
ummm, think long and hard about it and do the best job you can. If the 
new implementer is shocked by this into reading the Mister and 
Zuccherato paper, so much the better. If they check to see what other 
people have done, marvelous.

Here's the final edit I have:

Many implementers have taken this advice to heart for any data that is 
symmetrically encrypted and for which the session key is public-key 
encrypted. In this case, the quick check is not needed as the public 
key encryption of the session key should guarantee that it is the right 
session key. In other cases, the implementation should use the quick 
check with care.

On the one hand, there is a danger to using it if there is a random 
oracle that can leak information to an attacker. In plainer language, 
there is a danger to using the quick check if timing information about 
the check can be exposed to an attacker, particularly via an automated 
service that allows rapidly repeated queries

On the other hand, it is inconvenient to the user to be informed that 
they typed in the wrong passphrase only after a petabyte of data is 
decrypted. There are many cases in cryptographic engineering where the 
implementer must use care and wisdom, and this is one.

>
> Everything else looked good as far as I could see.
>

Thanks. I appreciate the comments and corrections

	Jon

> Hal Finney

Date: Wed, 20 Jul 2005 16:08:26 -0400
From: Adam Back <[email-masked]>
To: Brent Waters <[email-masked]>
Cc: [email-masked], [email-masked], Adam Back <[email-masked]>
Subject: pgp-stealth (Re: Chosen-ciphertext attack on receiver anonymity)
Sender: [email-masked]

There was some work done on this as a filter to pgp (2.x) called
pgpstealth [1].

Basically it should be able to make a reversible transformation where
the output has unbiased rectangular distribution throughout (for both
key-transport, and remove any boilerplate).

openpgp has become a bit more complex since pgp2x but I think there
are potential customers for this -- as input to steganography
programs.

There was some discsussion a long time ago now in the context of the
feature under discussion here of whether pgpstealth-like functionality
could be added as a builtin feature of a pgp implementation.  

As an external filter I'm not sure the 0x000... or short keyid would
really help the transformation because the transformation has to
anyway be wrt a specific key.  ie so you're actually trying each key
with a trial transformation so it would actually hook either
externally where the empty keyid picks a key, does trial
transformation, tries to decrypt, fails, skips to the next keyid in
the keyring.

Of course there are also other potential uses for hiding the recipient
-- broadcast of a message (eg to alt.anonymous.messages), where the
recipient is by prior arrangement scanning for messages he can
decrypt.

Anyway pgp-stealth is at present a bit of an orphan project.  It might
be interesting / useful to update it as a standalone filter working
with openpgp or re-write it as a gnupg extension, or something like
that.

Adam

[1] http://www.cypherspace.org/openpgp/stealth/

On Tue, Jul 12, 2005 at 04:18:20PM -0700, Brent Waters wrote:
> 
> It seems from everyone's comments that there is a desire/need to complete 
> this particular RFC, which makes sense.
> 
> I do think, however, that it would also make sense to eventually define an 
> encryption standard that has "Key-Privacy" built in. I think the norm 
> should be for the ciphertext not to reveal the receiver's identity. If 
> an application wishes to do so they can always tag the ciphertext with the 
> identity and an application that does not wish to do so is not forced to.
> 
> Anyway, if anyone has interest furthering this idea on a different venue 
> let me know.
> 
> -Brent
> 
> 
> 
> On Wed, 6 Jul 2005, Jon Callas wrote:
> 
> >>
> >>Right, that's what I feared.  Has anyone actually
> >>implemented it *and* seen a benefit out in the field?
> >>
> >>
> >
> >I think we should leave it the way it is.
> >
> >Sorry. I want to put this RFC to bed, and that means we have to stop 
> >making tweaks.
> >
> >	Jon
> >
> >

To: [email-masked], [email-masked]
Subject: Re: Section 5.2.3 of latest draft: bis14.
Date: Fri, 15 Jul 2005 16:47:25 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Levi Broderick writes:
> I noticed that the following bullet is missing from the latest draft.
> It used to appear between 'One-octet hash algorithm' and 'Hashed
> subpacket data set' in section 5.2.3.
>
>       - Two-octet scalar octet count for following hashed subpacket
>         data. Note that this is the length in octets of all of the hashed
>         subpackets; a pointer incremented by this number will skip over
>         the hashed subpackets.

This is definitely an error and needs to be fixed.

A couple of other relatively minor points relating to this section.

We now use the term "data set" for the hashed and unhashed subpackets:

      - Hashed subpacket data set. (zero or more subpackets)

      - Two-octet scalar octet count for the following unhashed
        subpacket data. Note that this is the length in octets of all of
        the unhashed subpackets; a pointer incremented by this number
        will skip over the unhashed subpackets.

      - Unhashed subpacket data set. (zero or more subpackets)

"Data set" is defined in the next section, 5.2.3.1:

    A subpacket data set consists of zero or more signature subpackets,
    preceded by a two-octet scalar count of the length in octets of all
    the subpackets; a pointer incremented by this number will skip over
    the subpacket data set.

This definition could be interpreted to mean that the data set includes
the two-octet scalar count.  In fact, in the layout in 5.2.3 the data
set does not include the scalar count.  5.2.3.1 could be reworded to say
"A subpacket data set consists of zero or more signature subpackets,
AND IS preceded by a two-octet scalar count..."

Another slight wording inconsistency is in 5.2.3:

    The data being signed is hashed, and then the signature data from
    the version number through the hashed subpacket data (inclusive) is
    hashed. The resulting hash value is what is signed.

This "x is hashed, and then y is hashed" business has caused confusion
for implementors.  5.2.2 fixed the wording for V3 packets:

    The concatenation of the data to be signed, the signature type and
    creation time from the signature packet (5 additional octets) is
    hashed. The resulting hash value is used in the signature algorithm.

We should make the same change for V4 packets in 5.2.3.  I don't know
if there are any other places where we talk about hashing X and then
Y and then Z instead of, as we should, hashing the contatenation of
X and Y and Z.

I am diffing against bis-12 which is the only old version I have here.
Another change I notice is that the preferred algorithm signature
subpackets in 5.2.3.7, 5.2.3.8 and 5.2.3.9 have their contents changed
from a "sequence" of one-octet values to an "array" of one-octet values.
However we do not otherwise define "array".  Is that word really
better than "sequence" here?  To me, a sequence of values is a plainer
description while an array perhaps connotes a somewhat more complex
data structure.  Of course in C an array is simply bytes in memory so if
that is how it is being read, OK.  I'm just worried that an implementor
is going to look for a definition of array.

Section 5.5.2:

    V2 keys are identical to V3 keys except for the deprecated V3 keys
    except for the version number. An implementation MUST NOT generate
    them and may accept or reject them as it sees fit.

Two "except for"s here, it doesn't look right.

Section 5.9 on literal packets:

      - File name as a string (one-octet length, followed by a file
        name). This may be a zero-length string. Commonly, if the source
        of the encrypted data is a file, this will be the name of the
        encrypted file. An implementation MAY consider the file name in
        the literal packet to be a more authoritative name than the
        actual file name.

I know we discussed this here, but I'm not sure this is right yet.
What is the "actual file name"?  And what does it mean for a name to
be authoritative?  This is making some assumptions about processing flow
which may not be correct.  I think "actual file name" means the name of
the file being decrypted, assuming that the encrypted data actually came
from a file.  But then, usually the encrypted file name is not used for
the decrypted data, rather some modification of that file name is used,
so perhaps that is the "actual file name"?

Maybe we could change the last sentence to "When decrypting, an
implementation MAY use this name as the name of an output file."
That would hint what we mean it to be used for.  Or maybe just leave the
last sentence off entirely and just say that this is commonly the name
of the encrypted file, let the implementor figure out what if anything
he wants to do with it.

We refer to RFC 822 in two places, but that's been superceded by
RFC 2822.

The only reason I noticed this in my diffing was because we changed
to put a space after RFC.  But in the references we have no space,
e.g. [RFC 2045] became [RFC2045].  I guess it's OK to use a space in
the text and no space in the references, but why not do it the same
in both contexts?  I would vote for no space, it looks better to me,
but your eyes may differ.

Section 13, Security Considerations:

     * In winter 2005, Serge Mister and Robert Zuccherato from Entrust
       released a paper describing a way that the "quick check" in
       OpenPGP CFB mode can be used with a random oracle to decrypt two
       octets of every cipher block [MZ05]. They recommend as
       prevention not using the quick check at all.

       Many implementers have taken this advice to heart for any data
       that is both symmetrically encrypted, but also the session key
       is public-key encrypted. In this case, the quick check is not
       needed as the public key encryption of the session key should
       guarantee that it is the right session key. In other cases, the
       implementation should use the quick check with care. On the one
       hand, there is a danger to using it if there is a random oracle
       that can leak information to an attacker. On the other hand, it
       is inconvenient to the user to be informed that they typed in
       the wrong passphrase only after a petabyte of data is decrypted.
       There are many cases in cryptographic engineering where the
       implementer must use care and wisdom, and this is another.

This is good but I think some of the wording could be smoothed.   The
first sentence of the second paragraph should not have a comma after
the first part of the "both" clause, and "but" doesn't seem like the
right connective.  I suggest,

       Many implementers have taken this advice to heart for any data
       that is symmetrically encrypted and for which the session key
       is public-key encrypted.

I also have a problem with "there is a danger to using it if there is
a random oracle that can leak information".  This makes it sounds like
the random oracle is some other entity independent of the implementation.
I would prefer to avoid the word "oracle" as not all implementors may be
familiar with the technical meaning, and in common use it has mystical
or religious connotations.

I think what we want is something like "there is a danger to using it
if timing information about the check can be exposed to an attacker,
particularly via an automated service that allows rapidly repeated
queries".

Finally I think the last clause should say "and this is one" rather
than "and this is another".

I do have to add that I think this paragraph is perhaps a little informal
or even poetic for a security document.  Implementors "take things to
heart" and use their "care and wisdom".  I could see an implementor
wondering whether he was reading a spec or beginning a study of Zen.
Maybe we should think about changing this to be a little more cool and
just warn them that if they are going to use the check bits, they need
to be aware of the danger of leaking timing data.  The content of the
paragraph is good, it's just the style which struck me as being a bit off.
Again, your taste may differ.

Everything else looked good as far as I could see.

Hal Finney

From: Jon Callas <[email-masked]>
Subject: Re: Meet in Paris?
Date: Fri, 15 Jul 2005 16:17:49 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I'm going to be in Paris. A meeting is just fine.

I want us to go to last call on this, and discuss other things like 
compatibility bakeoffs, etc.

	Jon

Date: Thu, 14 Jul 2005 15:26:05 -0400
From: Levi Broderick <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Section 5.2.3 of latest draft: bis14.
OpenPGP: id=3FE7C25A; url=http://www.andrew.cmu.edu/user/lpb/pubkey.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig8CE7E42D3F3504F6B2B53A73
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I noticed that the following bullet is missing from the latest draft.
It used to appear between 'One-octet hash algorithm' and 'Hashed
subpacket data set' in section 5.2.3.

      - Two-octet scalar octet count for following hashed subpacket
        data. Note that this is the length in octets of all of the hashed
        subpackets; a pointer incremented by this number will skip over
        the hashed subpackets.

Is this an intentional (and possibly breaking) change to the V4
signature packet format, or was this just an editing error?

Thanks!

~ Levi

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

--------------enig8CE7E42D3F3504F6B2B53A73--

content-class: urn:content-classes:message
Subject: PGP 8.1 - One Pass Signature Format
Date: Thu, 14 Jul 2005 13:27:28 -0400
From: "Hasnain Mujtaba" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Greetings,

I received a Signed & Encrypted Message from a customer who uses PGP
8.1. The source file was zero bytes long (for reasons unknown). Out of
curiosity, I ran the message through gpg --list-packets and discovered
that the onepass signature message was unusually constructed: onepass
pkt, signature pkt, literal data pkt (output included below).  I then
signed&encrypted a non-zero byte file with PGP. The resulting message
was properly constructed, as expected.

I guess it doesn't matter for zero-byte files what the format ends up
being. But I can't help asking whether I have run into a corner case
bug.

Regards,
Hasnain.

:marker packet:
 50 47 50
:pubkey enc packet: version 3, algo 16, keyid 7D41D4AD53DEA729
        data: [2048 bits]
        data: [2047 bits]
:encrypted data packet:
        length: 146
        mdc_method: 2
gpg: encrypted with 2048-bit ELG-E key, ID 53DEA729, created 2005-07-13
      "testuser <[email-masked]>"
:compressed packet: algo=2
:onepass_sig packet: keyid 353954462BBAC0C9
        version 3, sigclass 00, digest 2, pubkey 17, last=1
:signature packet: algo 17, keyid 353954462BBAC0C9
        version 3, created 1121293327, md5len 5, sigclass 00
        digest algo 2, begin of digest 43 51
        data: [158 bits]
        data: [160 bits]
:literal data packet:
        mode b (62), created 50331648, name="zero3.txt",
        raw data: 0 bytes
:mdc packet: length=20

Subject: OpenPGP-Header (Was: Meet in Paris?)
From: Jeroen Massar <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: Derek Atkins <[email-masked]>, [email-masked]
Organization: Unfix
Date: Wed, 13 Jul 2005 13:34:04 +0200
Sender: [email-masked]

--=-kgKm4I3oYRHkcFgHBvmE
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-07-13 at 10:31 +0200, Simon Josefsson wrote:
> Derek Atkins <[email-masked]> writes:
>=20
> > Hi,
> >
> > Do the members of this working group feel we need a meeting
> > in Paris?  I think we might want to meet in order to consider
> > work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
> > that's been proposed).
>=20
> I would likely be around to talk about the OpenPGP mail header [1], if
> there is interest.  Feedback from OpenPGP experts on the usefulness of
> adding a "supports" token to the header is one open issue that may be
> useful to discuss.

I actually am more in it for just specifying where the keyserver for
this key is located. Or actually just having the address of this key.

Eg, when I send mail out, it gets signed by my [email-masked] key. But
there is no reference to that anywhere to which id which key belongs
(afaik).

Currently a raw mail contains something like:
8<-----------------------------------------------------------------
--=3D-Zzt3A5Tzpnkf1gPDBX5s
Content-Type: application/pgp-signature; name=3Dsignature.asc
Content-Description: This is a digitally signed message part

----------------------------------------------------------------->8

What if we added, in addition to the "Comment:" line a line like:
8<-----------------------------------------------------------------
User-ID: [email-masked]
----------------------------------------------------------------->8

We then know, programmatically, who this key is supposed to represent.
We can then:

8<-----------------------------------
$ dig +short _pgpkey._service.unfix.org any
_pgpkey-http._tcp.unfix.org.
_pgpkey-https._tcp.unfix.org.
----------------------------------->8
PTR records

8<-----------------------------------
$ dig +short _pgpkey-http._tcp.unfix.org. any
"path=3D/pks/"
42 100 80 purgatory.unfix.org.
$ dig +short _pgpkey-https._tcp.unfix.org. any
"path=3D/pks/"
13 100 443 purgatory.unfix.org.
----------------------------------->8
TXT + SRV record.

https having the weight, from which we can construct:
https://purgatory.unfix.org/pks/

where a onak cgi is located, basically doing hkp, but then over full
https. (one can also do _pgpkey-hkp for hkp://.... but I don't have a
hkp server on that box, so it is not in DNS)

We then know:
 - if DNSSEC would be deployed we for sure would know
   the dns answer was valid and that the above servers
   are authoritive keyservers for the unfix.org domain.
   But we can assume this is pretty correct even without dnssec.
 - ssl on the https + the certifacate make sure we
   are talking to the correct box.
 - the user was able to put his key on the keyserver
   running for this domain

Then we can assume:
 - when we do a https://purgatory.unfix.org/pks/lookup/[email-masked]
   that they key returned is valid for this ID.

We can now verify it, giving it some extra 'trust points' because the
domain said this key belongs to it. Or we could require that keyservers
used in this way make sure all the keys get signed by the operator, who
has a key in the strong set. eg large ISP's could automatically generate
keys for their users and sign outgoing mail based on SMTP AUTH, to avoid
people having to do pgp themselves.

Another verification could be comparing that the 'home keyserver', as
found in the key itself,=20

This brings us distributed keyservers.
Though one still requires to have a lot of keys in a local cache, which
at a certain point most likely is at least 60% of the keys.

Having this field also allows one to specify a nice policy for email, eg
in a SPF record: "pgp:unfix.org", saying that mail send from this domain
has to be signed with a key which has a user-id in unfix.org.

/me now expects an avalanche of comments about many things I did not
take into the sum of the equation ;)

Greets,
 Jeroen

--=-kgKm4I3oYRHkcFgHBvmE
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-kgKm4I3oYRHkcFgHBvmE--

From: Simon Josefsson <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Subject: Re: Meet in Paris?
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 13 Jul 2005 10:31:06 +0200
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:

> Hi,
>
> Do the members of this working group feel we need a meeting
> in Paris?  I think we might want to meet in order to consider
> work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
> that's been proposed).

I would likely be around to talk about the OpenPGP mail header [1], if
there is interest.  Feedback from OpenPGP experts on the usefulness of
adding a "supports" token to the header is one open issue that may be
useful to discuss.

I'd hate to see anything slow down 2440bis further though.

[1] http://josefsson.org/openpgp-header/

Date: Tue, 12 Jul 2005 16:18:20 -0700 (PDT)
From: Brent Waters <[email-masked]>
To: Jon Callas <[email-masked]>
cc: Ian Grigg <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Sender: [email-masked]

It seems from everyone's comments that there is a desire/need to complete 
this particular RFC, which makes sense.

I do think, however, that it would also make sense to eventually define an 
encryption standard that has "Key-Privacy" built in. I think the norm 
should be for the ciphertext not to reveal the receiver's identity. If 
an application wishes to do so they can always tag the ciphertext with the 
identity and an application that does not wish to do so is not forced to.

Anyway, if anyone has interest furthering this idea on a different venue 
let me know.

-Brent

On Wed, 6 Jul 2005, Jon Callas wrote:

>> 
>> Right, that's what I feared.  Has anyone actually
>> implemented it *and* seen a benefit out in the field?
>> 
>> 
>
> I think we should leave it the way it is.
>
> Sorry. I want to put this RFC to bed, and that means we have to stop making 
> tweaks.
>
> 	Jon
>
>

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-14.txt 
Date: Mon, 11 Jul 2005 15:50:02 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-14.txt
	Pages		: 72
	Date		: 2005-7-11
	
This document is maintained in order to publish all necessary
    information needed to develop interoperable applications based on
    the OpenPGP format. It is not a step-by-step cookbook for writing an
    application. It describes only the format and methods needed to
    read, check, generate, and write conforming packets crossing any
    network. It does not deal with storage and implementation questions.
    It does, however, discuss implementation issues necessary to avoid
    security flaws.

    OpenPGP software uses a combination of strong public-key and
    symmetric cryptography to provide security services for electronic
    communications and data storage.  These services include
    confidentiality, key management, authentication, and digital
    signatures. This document specifies the message formats used in
    OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-14.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-14.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Sat, 09 Jul 2005 12:31:28 +0100
From: Ben Laurie <[email-masked]>
To: Derek Atkins <[email-masked]>
CC: [email-masked]
Subject: Re: Meet in Paris?
Sender: [email-masked]

Derek Atkins wrote:
> Hi,
> 
> Do the members of this working group feel we need a meeting
> in Paris?  I think we might want to meet in order to consider
> work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
> that's been proposed).
> 
> If you feel strongly that we either should or should not meet
> in Paris, please let me know.
> 
> If you have a non-2440bis work item that you'd like (Ben: This is
> a hint to you) please let me know how much time you'd like on
> the agenda to discuss your new work items.

Unfortunately, IETF decided to schedule up against USENIX Security, so 
I'll be in Baltimore, not Paris.

Cheers,

Ben.

-- 
 >>>ApacheCon Europe<<<                   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

To: Jon Callas <[email-masked]>
Cc: Ian Grigg <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 08 Jul 2005 09:05:16 +0200
Sender: [email-masked]

On Wed, 6 Jul 2005 22:35:54 -0700, Jon Callas said:

> I think we should leave it the way it is.

Agreed.

> Sorry. I want to put this RFC to bed, and that means we have to stop
> making tweaks.

Yes please.

Shalom-Salam,

   Werner

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 06 Jul 2005 12:09:58 +0200
Sender: [email-masked]

On Tue, 05 Jul 2005 20:13:06 +1200, Peter Gutmann said:

> Well, in your implementation perhaps.  If you've got an interface that

It is an optional feature so I believe it is okay to just throw an
error if you can't find the key 0x0000000. 

> ID), not only is there no easy way to say "keep fetching whatever keys happen
> to turn up until I tell you to stop" without maintaining state in the key-
> source (making it non-multithreadable), but handling all of this stuff in an

Agreed. I have another implementation where I can't enumerate the keys
and then it also won't work unless one implements an option to define
a list of keys to check on a wildcard keyid.

Shalom-Salam,

   Werner

From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Date: Thu, 7 Jul 2005 14:06:59 +0100
Cc: Jon Callas <[email-masked]>
Sender: [email-masked]

On Thursday 07 July 2005 06:35, Jon Callas wrote:

> Sorry. I want to put this RFC to bed, and that means we have to stop 
> making tweaks.

I agree with anything that completes the RFC.  It's
been too long.

(In this case it is already a MAY so it's a teacup
looking for a storm.)

iang

-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

Cc: Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Date: Wed, 6 Jul 2005 22:35:54 -0700
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

>
> Right, that's what I feared.  Has anyone actually
> implemented it *and* seen a benefit out in the field?
>
>

I think we should leave it the way it is.

Sorry. I want to put this RFC to bed, and that means we have to stop 
making tweaks.

	Jon

Date: Wed, 06 Jul 2005 11:00:09 +0100
From: Ben Laurie <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Signature Subpacket type 8
Sender: [email-masked]

This subpacket is not defined in the I-D - but I am told it occurs in 
the keyrings.

Does anyone know what its for?

Cheers,

Ben.

-- 
 >>>ApacheCon Europe<<<                   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

From: Derek Atkins <[email-masked]>
To: [email-masked]
Subject: Meet in Paris?
Date: Tue, 05 Jul 2005 15:16:20 -0400
Sender: [email-masked]

Hi,

Do the members of this working group feel we need a meeting
in Paris?  I think we might want to meet in order to consider
work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
that's been proposed).

If you feel strongly that we either should or should not meet
in Paris, please let me know.

If you have a non-2440bis work item that you'd like (Ben: This is
a hint to you) please let me know how much time you'd like on
the agenda to discuss your new work items.

Thanks,

-derek, your friendly neighborhood chair
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

From: Ian Grigg <[email-masked]>
To: Peter Gutmann <[email-masked]>
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Date: Tue, 5 Jul 2005 12:20:28 +0100
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On Tuesday 05 July 2005 04:13, Peter Gutmann wrote:

> It's not just misleading, it's an absolute bastard to support for
> implementors.  So I think it should be deprecated not only because it serves
> little useful purpose, but also because the large amount of complexity added
> in supporting it isn't reflected by any matching payback in security.

Right, that's what I feared.  Has anyone actually
implemented it *and* seen a benefit out in the field?

To which Brent answered:
> As far as whether it is a problem, I believe that Hushmail uses such 
> feature to implement BCC functionality. Also, I PGP is used in some other 
> contexts such as newsgroups like alt.anonymous. In short it seems that 
> some applications might rely on the feature whether it was intended to be 
> strong or not.

Bummer.  Well, any views from Hushmail or from
whoever is encrypting to alt.anonymous?

Is there any reason why it has to be supported?
It's a MAY - just don't support it would be one
answer.  Hushmail supporting it in their 'closed'
system is fine, and as soon as they go out into
the broader world this is at their risk.

Maybe just mark the feature as only supported
within a given cooperating group of users - so
Hushmail can do it within their users, but it
won't be supported outside?

> In the short term it might help to serve notice in some way. 
> Perhaps a note of the RFC would be good. While there does seems to be a 
> bit of work to do, it seems feasible to implement the feature properly. 
> My opinion is that eventually it would probably be best to either provide 
> the feature fully or remove it. Which one to do probably depends on what 
> goals of PGP are.

I don't recall that the goals of PGP in the wider sense
ever really considered anonymity or psuedonymity
except in the sense of avoiding mistakes surrounding
meatspace identity and ending up with engineering
psuedonymity.  PGP history quite clearly expresses
that you can call yourself Micky Mouse, but it doesn't
extend much if any guarantees about whether the software
protects you against any threats that might arise in that
cartoon.

Certainly *this RFC* is not the place to start on that.
It would seem that we need some project or team
to explore the possibilities, and create some demo
patches to gpg, and a paper or two.  Starting another
RFC might be possible but on our current record, I'd
not suggest that.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

From: Ian Grigg <[email-masked]>
To: "Hal Finney" <[email-masked]>
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Date: Tue, 5 Jul 2005 11:35:49 +0100
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Tuesday 05 July 2005 00:59, Hal Finney wrote:
> I'm not familiar with this term "throw-keyid".  We don't use it in
> RFC2440-bis as far as I know.  I think however that you are referring
> to this feature discussed in section 5.1:
> 
>    An implementation MAY accept or use a Key ID of zero as a "wild
>    card" or "speculative" Key ID. In this case, the receiving
>    implementation would try all available private keys, checking for a
>    valid decrypted session key. This format helps reduce traffic
>    analysis of messages.
...
> That does seem to be a valid attack against the anonymity.  However
> you should be aware that OpenPGP is not trying to provide very strong
> anonymity here.  No effort is made to obfuscate the key size, for example,
> so unusually sized keys tend to reveal themselves.  All the RFC phrasing
> suggests or claims is that it can "help reduce" traffic analysis.
> 
> If we really wanted to guarantee strong anonymity I think we would have
> to do quite a bit more work here.  Your attack is definitely something
> to consider.  However, strong anonymity is not something we have aimed
> to provide.

Yes.  This has never been a direction the project
that I've known, and has always been something
thrust up to the human layer as a "maybe".

> Given the weak level of anonymity it affords, perhaps the zero keyid
> feature is misleading to users?  If so, should we consider deprecating
> it until we are willing to do the work necessary to do the job right?
> Or we could at least put a note in the RFC emphasizing that this feature
> does not provide strong anonymity and should not be relied upon for
> that purpose.

I think the paragraph covers all that adequately,
in that it is already a MAY, and the purpose says
that it "helps" to reduce TA.

We can't expect the RFC to teach basic crypto
or basic security.  This group and other resources
exist to fill in the gap.

OTOH, I must admit to being mildly conflicted about
the feature.  I think it was I who suggested it, and I
was somewhat surprised when it was accepted.  I
personally would have shot it down as an uneccessary
complication, myself ;-)  But it is only a MAY and I
can't quite put my finger on where it would cause a
problem to a developer.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 05 Jul 2005 20:13:06 +1200
Sender: [email-masked]

Werner Koch <[email-masked]> writes:
>On Tue, 05 Jul 2005 15:13:53 +1200, Peter Gutmann said:
>> It's not just misleading, it's an absolute bastard to support for
>> implementors.  So I think it should be deprecated not only because it serves
>
>Decryption are 38 lines including verbose error checking and status
>reporting.

Well, in your implementation perhaps.  If you've got an interface that
supports a general-purpose key-fetch (fetch the key for this person or this
ID), not only is there no easy way to say "keep fetching whatever keys happen
to turn up until I tell you to stop" without maintaining state in the key-
source (making it non-multithreadable), but handling all of this stuff in an
implementation that's designed for "identify-key, fetch, decrypt" greatly
complicates the code.

Peter.

To: [email-masked] ("Hal Finney")
Cc: [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 05 Jul 2005 09:36:36 +0200
Sender: [email-masked]

On Mon,  4 Jul 2005 16:59:00 -0700 (PDT), "Hal Finney" said:

> Given the weak level of anonymity it affords, perhaps the zero keyid
> feature is misleading to users?  If so, should we consider deprecating
> it until we are willing to do the work necessary to do the job right?

For one recipient it is actually a valuable feature.  MTAs using this
to hide BCC messages are of course not using it proper - they need to
send several messages.

> Or we could at least put a note in the RFC emphasizing that this feature
> does not provide strong anonymity and should not be relied upon for
> that purpose.

A word on that there are problems when used with more than one
recipient would be good.  However, the wild card keyID is an OpenPGP
feature and how it it used is more a matter of the actual
implemention.  I'll add a warning to gpg's man page.

Shalom-Salam,

   Werner

To: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 05 Jul 2005 09:31:15 +0200
Sender: [email-masked]

On Tue, 05 Jul 2005 15:13:53 +1200, Peter Gutmann said:

> It's somewhat confusing GPG terminology.

I agree that --hidden-recipient is a better name; however 7 years ago
someone asked for an option of this name to be able to send anonymous
messages to public newsgroups without prior negotiation of a one time
key.

> It's not just misleading, it's an absolute bastard to support for
> implementors.  So I think it should be deprecated not only because it serves

Decryption are 38 lines including verbose error checking and status
reporting.

Salam-Shalom,

   Werner

Date: Mon, 4 Jul 2005 21:49:45 -0700 (PDT)
From: Brent Waters <[email-masked]>
To: Hal Finney <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Sender: [email-masked]

> I'm not familiar with this term "throw-keyid".  We don't use it in
> RFC2440-bis as far as I know.  I think however that you are referring
> to this feature discussed in section 5.1:
>
>   An implementation MAY accept or use a Key ID of zero as a "wild
>   card" or "speculative" Key ID. In this case, the receiving
>   implementation would try all available private keys, checking for a
>   valid decrypted session key. This format helps reduce traffic
>   analysis of messages.
As Peter pointed out, I was using GNUPG command-line terminology. However, 
it seems we are talking about the same thing.

> That does seem to be a valid attack against the anonymity.  However
> you should be aware that OpenPGP is not trying to provide very strong
> anonymity here.  No effort is made to obfuscate the key size, for example,
> so unusually sized keys tend to reveal themselves.  All the RFC phrasing
> suggests or claims is that it can "help reduce" traffic analysis.
>
> If we really wanted to guarantee strong anonymity I think we would have
> to do quite a bit more work here.  Your attack is definitely something
> to consider.  However, strong anonymity is not something we have aimed
> to provide.
>
> Given the weak level of anonymity it affords, perhaps the zero keyid
> feature is misleading to users?  If so, should we consider deprecating
> it until we are willing to do the work necessary to do the job right?
> Or we could at least put a note in the RFC emphasizing that this feature
> does not provide strong anonymity and should not be relied upon for
> that purpose.

Yes, there are certainly other issues in anonymity. Even if two keys are 
the same number of bits there could be attacks. E.g. If 110000001 and 
100000001 were both primes used for different ElGamal keys and adversary 
would still have a significant advantage in distinguishing the receiver. 
Having common ElGamal NIST primes would take care of this and have the 
small benefit of faster key generation. This is discussed in a Bellare 
paper: http://www-cse.ucsd.edu/users/mihir/papers/anonenc.html .
The thing unique about the attack I described is that no one has 
considered a definition "Key-Privacy" in the multiple recipient 
case. However, I believe a solution from "commodity parts" can be made.

As far as whether it is a problem, I believe that Hushmail uses such 
feature to implement BCC functionality. Also, I PGP is used in some other 
contexts such as newsgroups like alt.anonymous. In short it seems that 
some applications might rely on the feature whether it was intended to be 
strong or not.

In the short term it might help to serve notice in some way. 
Perhaps a note of the RFC would be good. While there does seems to be a 
bit of work to do, it seems feasible to implement the feature properly. 
My opinion is that eventually it would probably be best to either provide 
the feature fully or remove it. Which one to do probably depends on what 
goals of PGP are.

-Brent

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Date: Tue, 05 Jul 2005 15:13:53 +1200
Sender: [email-masked]

[email-masked] ("Hal Finney") writes:

>I'm not familiar with this term "throw-keyid". 

It's somewhat confusing GPG terminology.

>Given the weak level of anonymity it affords, perhaps the zero keyid feature
>is misleading to users?  If so, should we consider deprecating it until we
>are willing to do the work necessary to do the job right?

It's not just misleading, it's an absolute bastard to support for
implementors.  So I think it should be deprecated not only because it serves
little useful purpose, but also because the large amount of complexity added
in supporting it isn't reflected by any matching payback in security.

Peter.

To: [email-masked], [email-masked]
Subject: Re: Chosen-ciphertext attack on receiver anonymity
Date: Mon,  4 Jul 2005 16:59:00 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Brent Waters writes:
> I wanted to bring up an issue that had to do with chosen-ciphertext 
> attacks on receiver anonymity.
>
> The specific case I am worried about is when the "throw-keyid" option is
> used to encrypt a message to multiple recipients. My understanding is that
> the throw-keyid option should hide the identity of the a receiver of the
> message (by throwing away the key-id) even from other receivers of a
> message.

I'm not familiar with this term "throw-keyid".  We don't use it in
RFC2440-bis as far as I know.  I think however that you are referring
to this feature discussed in section 5.1:

   An implementation MAY accept or use a Key ID of zero as a "wild
   card" or "speculative" Key ID. In this case, the receiving
   implementation would try all available private keys, checking for a
   valid decrypted session key. This format helps reduce traffic
   analysis of messages.

> Suppose I made such an encryption of M to Alice and Bob, then the
> hybrid encryption (at a high level) would look something like this:
> 1)Choose random symmetric key key K
> 2)Ciphertext: (C1,C2,C')=E_{KeyAlice}(K)E_{KeyBob}(K),E_K(Message)
> where C1,C2 are asymmetric encryption and C' is a symmetric key 
> encryption.
>
> At this point Alice and Bob can both decrypt the message, but neither can
> tell if the other was the other receiver. Suppose Bob suspects Alice was 
> the other receiver. Then he can create a ciphertext:
> (C1,C'')=E_{KeyAlice}(K)E_K(NewMessage)
> and send this to Alice, if Alice responds to this in a meaningful way she
> was the other receiver. NewMessage could be something simple like "Do you
> want to go to lunch?" which would likely elicit a response. Note, this can
> be a problem even if the ciphers are CCA-secure.

That does seem to be a valid attack against the anonymity.  However
you should be aware that OpenPGP is not trying to provide very strong
anonymity here.  No effort is made to obfuscate the key size, for example,
so unusually sized keys tend to reveal themselves.  All the RFC phrasing
suggests or claims is that it can "help reduce" traffic analysis.

If we really wanted to guarantee strong anonymity I think we would have
to do quite a bit more work here.  Your attack is definitely something
to consider.  However, strong anonymity is not something we have aimed
to provide.

Given the weak level of anonymity it affords, perhaps the zero keyid
feature is misleading to users?  If so, should we consider deprecating
it until we are willing to do the work necessary to do the job right?
Or we could at least put a note in the RFC emphasizing that this feature
does not provide strong anonymity and should not be relied upon for
that purpose.

Hal Finney

Date: Mon, 4 Jul 2005 16:03:49 -0700 (PDT)
From: Brent Waters <[email-masked]>
To: [email-masked]
Subject: Chosen-ciphertext attack on receiver anonymity
Sender: [email-masked]

I wanted to bring up an issue that had to do with chosen-ciphertext 
attacks on receiver anonymity.

The specific case I am worried about is when the "throw-keyid" option is
used to encrypt a message to multiple recipients. My understanding is that
the throw-keyid option should hide the identity of the a receiver of the
message (by throwing away the key-id) even from other receivers of a
message. Suppose I made such an encryption of M to Alice and Bob, then the
hybrid encryption (at a high level) would look something like this:
1)Choose random symmetric key key K
2)Ciphertext: (C1,C2,C')=E_{KeyAlice}(K)E_{KeyBob}(K),E_K(Message)
where C1,C2 are asymmetric encryption and C' is a symmetric key 
encryption.

At this point Alice and Bob can both decrypt the message, but neither can
tell if the other was the other receiver. Suppose Bob suspects Alice was 
the other receiver. Then he can create a ciphertext:
(C1,C'')=E_{KeyAlice}(K)E_K(NewMessage)
and send this to Alice, if Alice responds to this in a meaningful way she
was the other receiver. NewMessage could be something simple like "Do you
want to go to lunch?" which would likely elicit a response. Note, this can
be a problem even if the ciphers are CCA-secure.

I have been discussing this type of a problem in the context of BCC 
privacy for email programs with Adam Barth and Dan Boneh. However, there 
could be wider implications as PGP is used in other contextes.
Anyway, I would be interested to hear comments.

Regards,
Brent

http://crypto.stanford.edu/~bwaters/