Subject: Suggested DER Prefixes

From: "Imad R. Faiad" <[email-masked]>
Date: Wed, 21 May 2003 13:11:35 +0200

-----BEGIN PGP SIGNED MESSAGE-----

Greetings,

Please find below some suggested DER prefixes
for the hash algorithms with no OID's.

Best regards

Imad R Faiad

PS Can someone clarify OpenPGP symmetric
algorithm ID: 6 (DES/SK), I mean, what
variant of the DES algorithm are we talking about.
TIA

//Double width SHA (SHA1x) experimental algorithm
//Used In: PGP 5.x
//OpenPGP Hash Algorithm ID: 04
unsigned char const SHA1xDERprefix[] = {
	0x30, /* Universal, Constructed, Sequence */
	0x35, /* Length 53 (bytes following) */
		0x30,  /* Universal, Constructed, Sequence */
		0x09,  /* Length 9 bytes*/
			0x04, /* Universal, Primitive, Octet string */
			0x05, /*Length 5 bytes*/
			   0x53, 0x48, 0x41, 0x31, 0x78,  /*SHA1x*/
			0x05,  /* Universal, Primitive, NULL */
			0x00, /* Length 0 */
		0x04, /* Universal, Primitive, Octet string */
		0x28 /* Length 40 bytes = 320 bits*/
		/* 40 bytes SHA1x digest start here */
};

//HAVAL 5 pass, 160 bits (HAVAL-5-160)
//OpenPGP Hash Algorithm ID: 07
//Used in: PGP 2.6.3ia-multi04+
unsigned char const HAVAL-5-160DERprefix[] = {
	0x30, /* Universal, Constructed, Sequence */ 
	0x27, /* Length 39 (bytes following) */
		0x30,  /* Universal, Constructed, Sequence */
		0x0f,  /* Length 15 bytes*/
			0x04, /* Universal, Primitive, Octet string */
			0x0B, /*Length 11 bytes*/
			   0x48, 0x41, 0x56, 0x41, 0x4C, 0x2D,
			   0x35, 0x2D, 0x31, 0x36, 0x30, /*HAVAL-5-160*/
			0x05,  /* Universal, Primitive, NULL */
			0x00, /* Length 0 */
		0x04, /* Universal, Primitive, Octet string */
		0x14 /* Length 20 bytes = 160 bits*/
		/* 20 bytes HAVAL-5-160 digest start here */
};

//HAVAL 5 pass, 256 bits (HAVAL-5-256)
//OpenPGP Hash Algorithm ID: None
//Used in: PGP 2.6.3ia-multi04+
//Hash Algorithm ID used: 11
unsigned char const HAVAL-5-256DERprefix[] = {
	0x30, /* Universal, Constructed, Sequence */ 
	0x33, /* Length 51 (bytes following) */
		0x30,  /* Universal, Constructed, Sequence */
		0x0f,  /* Length 15 bytes*/
			0x04, /* Universal, Primitive, Octet string */
			0x0B, /*Length 11 bytes*/
			   0x48, 0x41, 0x56, 0x41, 0x4C, 0x2D,
			   0x35, 0x2D, 0x32, 0x35, 0x36, /*HAVAL-5-256*/
			0x05,  /* Universal, Primitive, NULL */
			0x00, /* Length 0 */
		0x04, /* Universal, Primitive, Octet string */
		0x20 /* Length 32 bytes = 256 bits*/
		/* 32 bytes HAVAL-5-256 digest start here */
};

---

From: Jon Callas <[email-masked]>
Date: Wed, 21 May 2003 09:34:17 -0700

> variant of the DES algorithm are we talking about.

DES/SK is being removed. Don't implemented it.

> /* 40 bytes SHA1x digest start here */

Double-width SHA was an experimental thing some people were using for wider
DSA, it was never widely implemented. Don't implement it.

> /* 32 bytes HAVAL-5-256 digest start here */

Haval is being removed. Don't bother.

Now that there are the wide SHAs, they are what you should be implementing.

    Jon

---

From: "Imad R. Faiad" <[email-masked]>
Date: Thu, 29 May 2003 00:12:53 +0200

Hello Mr Callas,

Please, do allow me to table the followings:-

And while you are at it, please do kindly remove
IDEA, CAST5, MD2, MD5, and AES < 256 bits.

The above algorithms, will, no doubt, be rendered useless,
given any advances in the attacks.

The OpenPGP suite of symmetric ciphers, and hashing algorithms
are deficient, more algorithms are needed.  While less is better,
I don't think that this principle should be applied
to the fundamental level of ciphers and hashes.
The implementer does not write the code for these, he just
plugs them in.  If he is too lazy to do so, then, I think,
that he ought to consider some other endeavor.
I wish that the "less is better" principle is
applied to the higher levels, this is where
all the complexities lies.

my 2c,

Best Regards,

Imad R. Faiad

P.S. Just out of curiosity, what in the heck is "DES/SK"?
     any references?

On Wed, 21 May 2003 09:34:17 -0700, you wrote:

>Double-width SHA was an experimental thing some people were using for
>wider DSA, it was never widely implemented. Don't implement it.
>

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 May 2003 00:50:53 -0700

> given any advances in the attacks.

In the soon-to-be finished bis08, IDEA is a MAY. MD2 has been removed (since
anything that used it is long-dead), and MD5 is moved to a MAY with lots of
grumbling. There's no reason to remove CAST5, and no reason to remove AES
below 256. In fact, there are those who feel safer with AES at 128 than at
256.

> P.S. Just out of curiosity, what in the heck is "DES/SK"?

It is an improvement on DES from Uri Blumenthal and Steve Bellovin. Here's a
reference: <http://www.research.att.com/~smb/papers/ides.pdf>. It's a way to
get reasonable security out of DES without having to do 3DES. It's a pretty
cool idea, but it never went anywhere, for a number of reasons.

    Jon

---

From: "Richard Laager" <[email-masked]>
Date: Thu, 29 May 2003 09:44:11 -0500

Jon Callas wrote:
>            In fact, there are those who feel safer with AES 
> at 128 than at
> 256.

Any particular reason(s)? Is there any merit to these reason(s)?

Thanks,
Richard Laager

---

From: Derek Atkins <[email-masked]>
Date: 29 May 2003 11:21:56 -0400

> Any particular reason(s)? Is there any merit to these reason(s)?

The difficulty in obtaining 256 bits of key entropy?

> Richard Laager

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: "Jeroen C. van Gelderen" <[email-masked]>
Date: Thu, 29 May 2003 12:52:56 -0400

> The difficulty in obtaining 256 bits of key entropy?

Hmm... if I read you correctly that would imply that AES-256 with a key 
containing 128 bits of entropy is less secure than AES-128 with a key 
containing 128 bits of entropy. Do you know of a document where this 
would be explained?

Cheers!
-J
-- 
Jeroen C. van Gelderen - [email-masked]

When Germany invaded Czechoslovakia and Poland, its declared 
justification
was to free the Germans living in those countries from the tyranny of 
the
Czech and Polish governments. When Germany invaded the Soviet Union in
1941, one of its declared purposes was to "liberate" the Russian people
from communist tyranny.

---

From: Derek Atkins <[email-masked]>
Date: 29 May 2003 12:55:29 -0400

"Jeroen C. van Gelderen" <[email-masked]> writes:

> Hmm... if I read you correctly that would imply that AES-256 with a
> key containing 128 bits of entropy is less secure than AES-128 with a
> key containing 128 bits of entropy. Do you know of a document where
> this would be explained?

I certainly did not say "less secure", did I?  It's certainly
much SLOWER, and certainly is not MORE secure... 

-derek

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

---

From: Jeroen van Gelderen <[email-masked]>
Date: Thu, 29 May 2003 13:05:08 -0400

> much SLOWER, and certainly is not MORE secure...

The original statement was:

   "In fact, there are those who feel safer with AES at 128 than at 256."

According to my English interpreter this implied "...more secure with 
AES 128...". Still does. You answered with what appeared to be a 
rationale for precisely this statement.

Cheers,
-J

---

From: Mike Markowitz <[email-masked]>
Date: Thu, 29 May 2003 13:27:47 -0500

>   "In fact, there are those who feel safer with AES at 128 than at 256."

I believe that when rumors of the initial Courtois & Pieprzyk work first 
made the
rounds (Crypto '01?), it was "whispered" that their attack only applied to 
(or was
simply more efficient at?) the 2 larger key sizes, but not to/at 128. The 
situation
now seems to be much more complicated. See, for example:
         http://www.minrank.org/aes/

-mjm

---

From: Jon Callas <[email-masked]>
Date: Thu, 29 May 2003 18:50:42 -0700

> Any particular reason(s)? Is there any merit to these reason(s)?

The main reason is that before the AES competition, no one ever built a
128-bit block, nor a 256-bit key. If there is a new way to analyze the
mixing of key, data, and blocksize, you would expect a design oops to show
up on the combination of more key and more blocksize.

Is there merit? What do you mean by merit?

The above concerns are reasonable. Otherwise sane security experts have said
these things. Do I share them myself? Not really. Do I think that even if
there's a weakness in AES-256, it will be *weaker* than AES-128? No.

However, on the other hand, I think that the instant leap to longer keys is
a sign of not understanding crypto. For example, I think that using Blowfish
with a 448 bit key is the sign of a crypto-duffer. There is *nothing* wrong
with a 128 bit key. Let's face it, whatever weakness there is in your system
will almost certainly *not* be in the cipher parts of the system. The cipher
system is the *strongest* part of the system, once you're at 128 bits.

Any OpenPGP-approved cipher is likely to be the strongest link of the chain
of whatever crypto system you're using. A chain is only as strong as its
weakest link, and people who fuss over ciphers are fussing about
strengthening the strongest parts. It's like putting stronger lock on a door
that still hollow wood frame.

The odds are that for any given user, their passphrase is the weakest link
in their OpenPGP use. 128-bit keys are probably the strongest.

    Jon

---

From: Adam Back <[email-masked]>
Date: Fri, 30 May 2003 20:48:17 +0100

On Thu, May 29, 2003 at 12:55:29PM -0400, Derek Atkins wrote:
> > >>> at 128 than at256.
> [...]

Actually it may be more secure; AES-256 has more rounds to offer a
more conservative security margin because the key is longer.  If half
of the key is unused, the extra rounds can only help.

So it is either as strong (if AES-128 truly offers 128 bits of
security), or stronger; but not "certainly is not MORE secure..."

Adam

---

From: Derek Atkins <[email-masked]>
Date: 30 May 2003 15:57:14 -0400

I beg to differ, but extra rounds do not necessarily improve
the security.  You still have a 2^128 brute-force attack
against the cipher if you use a 128-bit key.  It doesn't matter
what happens to the other bits.

Regardless, I believe that AES-128 has had significantly more
peer review than the larger elements, and "bigger is not necessarily
better".  As a security engineer you need to use prudence in
choosing which tools to use in which situation.   Based on the
state-of-the-art in 2003, and forseeable for the next few years,
I believe that AES-128 is sufficient for our needs.

Adding additional ciphers will just decrease interoperability, which
will reduce security because people wont use it.  "The perfect is
the enemy of the good".  Let's get it out there, get it deployed,
make it ubiquitous.  Until that happens, I don't feel we should
be entertaining additional ciphers.

-derek

---

From: Adam Back <[email-masked]>
Date: Fri, 30 May 2003 22:35:23 +0100

On Fri, May 30, 2003 at 03:57:14PM -0400, Derek Atkins wrote:
> You still have a 2^128 brute-force attack against the cipher if you
> use a 128-bit key.  It doesn't matter what happens to the other
> bits.

If the cipher retains 128 bits of security in both configurations
AES-128 and AES-256 with a 128 bit key then the security is equal.

But the point at which the security margin of the cipher becomes
interesting is when someone starts to make in-roads into reduced-round
variants, and starts to find attacks with work-factors sub-exponential
in the key-size.

> the security.  

One common method of heuristically measuring the strength of a cipher
is to attack reduced-round variants, clearly indicating that less
rounds is less secure.

I take this to mean that practically more rounds IS more secure.

Consider that the cipher state goes through a state analogous to a
state it would go through in a reduced round version on it's way to
the longer round version.  Unless the later rounds somehow _undo_ some
of the security provided by the earlier rounds it will not be less
secure.

Clearly the AES designers consider more rounds adds more security or
AES-256 would not have more rounds than AES-128.

> As a security engineer you need to use prudence in

Some people may need security beyond the "next few years".  I'd argue
for standardizing on AES-256.  The computational cost of a few extra
rounds is negligible.

> be entertaining additional ciphers.

Having a smaller choice of options is generally a good thing I agree.

Adam

---

From: John Wilkinson <[email-masked]>
Date: Fri, 30 May 2003 19:48:34 -0400

With all due respect, Jon, I would like to see a quote from a recognized 
crypto expert who feels that AES-128 is "safer" than AES-256.

AES-256 may not be *more* secure than AES-128, and, as a practical 
matter, I don't think that it is. However, the addition of more rounds 
*cannot* make it weaker. The differences in the key schedule could 
theoretically make AES-256 weaker than AES-128, but there is no reason 
to believe this is the case, and there are good reasons to believe that 
the key schedule of AES-256 makes the cipher at least as strong as or 
stronger than AES-128. One should NEVER fix any bytes of the key to be 
zero, in order to use a 128-bit key with AES-256; this may not make the 
cipher vulnerable, if it is resistant to related-key attacks, but it is 
not good practice.

If the choice for standardization is between AES-128 and AES-256, and 
the sole criterion is algorithm strength, I would recommend AES-256, 
because is might be stronger, and there is very little chance that it is 
weaker. If, however, there are other reasons, such as compatibility with 
other deployed applications, speed or effeciency, there seems little to 
differentiate the two security-wise, and one should choose the more 
compatible/deployable one.

Of course, 3DES is still the most trusted block cipher of all, and there 
are really no security advantages to other ciphers (including AES) for 
encrypting less than 2^32 blocks (32 GB) of data. 3DES is the MUST 
implement algorithm, and this is appropriate given the widespread 
confidence in its design.

Since most security products are advertized on the basis of their 
security, and many uninformed users would instinctively prefer AES-256 
to AES-128 or 3DES, if we *must* migrate away from 3DES for some reason, 
it may be adviseable to make AES-256 the "standard" algorithm, just to 
make these people happy, and avoid their switching to another 
application with better support for AES-256 or...<shudder>...2048-bit 
RC4. Of course, if ultimate algorithm confidence is the goal, I think a 
better use of our time would be moving to double-encryption of the 
message key with RSA-KEM and ACE-KEM, as recommended by the Nessie 
project. Come to think of it, a much better use of our time would be 
implementing a form of authenticated encryption. 3DES followed by 
HMAC-SHA1, anyone? :)

---

From: Hironobu SUZUKI <[email-masked]>
Date: Sat, 31 May 2003 09:52:53 +0900

I really think AES-128 is safe against brute-force attack in next a
decade but that is not enough.

First of all, I have to say that I am a paranoid ;-)

In PGP, TLS and other so-called PKC applications, the symmetric cipher
algorithm will be used with secret key exchange protocol.  There are
possibility the key space of symmetric cipher shrink if key exchange
protocol has flaw.

Symmetric cipher is good, PKC cipher is good also. But protocol has
flaw then security mergin would be shrunken.

If 50% of key space (128 -> 64, 256 -> 128) corrupt?.  64bit key size
is no survive.

I never ignore AES-256 because it become a sort of "insurance" when
the worst case of protocol problem is happened.

Regards,

-- 
Hironobu SUZUKI
E-Mail: [email-masked]
URL: http://h2np.net

---

From: David Shaw <[email-masked]>
Date: Fri, 30 May 2003 21:32:52 -0400

> be entertaining additional ciphers.

Just to clarify what I thought I was reading: are you suggesting that
AES-256 (and presumably AES-192) be dropped from OpenPGP, or is that
just a general comment?

I was in favor of dropping TIGER, MD2, SAFER, etc, but AES-192 and 256
are already widely implemented and deployed (PGP 7 and later, GnuPG
1.0.4 and later).  Removing those two ciphers now would cause pretty
serious interoperability problems.

Perhaps I misunderstood your thrust, in which case, my apologies.

David

---

From: Werner Koch <[email-masked]>
Date: Sat, 31 May 2003 11:05:44 +0200

> the sole criterion is algorithm strength, I would recommend AES-256,

It doesn't get you anything to double the length of the key if at the
same time you need to make tradeoffs in choosing the quality of the
random numbers.  Entropy is a scare resource and one should take
caution for what to spend it.

I am sure that the strength of any OpenPGP algorithm is far away rom
beein the weakes link in a OpenPGP cryptosystem.  The probability of
bugs in the software is much higher than any weakness in an algorithm.
That is what a cryptoplumber should to take care about, unless the
marketing departments gets involved ;-)

Shalom-Salam,

   Werner

-- 
  Nonviolence is the greatest force at the disposal of
  mankind. It is mightier than the mightiest weapon of
  destruction devised by the ingenuity of man. -Gandhi

---

From: [email-masked] (Bodo Moeller)
Date: Sat, 31 May 2003 15:10:02 +0200 (CEST)

> caution for what to spend it.

This is not quite true.  If you have N bits of unpredictable entropy
and feed this and some "random" but predictable data into an
appropriate hash function to generate a 2N-bit key, then this will
provide more security against brute force and quantum brute force
attacks than directly using a cipher with N-bit keys.  (Not much more
security, but some: a brute force attack against the cipher with N-bit
keys can directly cover all of the keyspace; for the attack against
the 2N-bit cipher, the hash preprocessing step has to be included into
the brute-force design, which will slow down the attack.)

Also if one of the ciphers is slower than the other, it is a bit more
secure (literally a bit if it runs at half the speed).

Of course arguably 128 bits are by far enough so that you don't really
have to worry about anything of this -- unless you think that quantum
attacks might become realistic.

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: John Wilkinson <[email-masked]>
Date: Sat, 31 May 2003 09:35:29 -0400

>attacks might become realistic.

I think that we are all in violent agreement that 128-bit key lengths 
are likely sufficient, and that both AES-128 and AES-256 are likely to 
be the strongest link in the OpenPGP chain. I was only trying to refute 
the argument that AES-128 is likely to be stronger than AES-256; this 
isn't a persuasive argument. The answer to the question, "why not use 
AES-256," is, "because AES-128 is sufficient," *not*, "because AES-128 
is stronger." However, since this question comes up *so* frequently, I 
am tempted to concur with Ross Anderson and argue that we should simply 
always use AES-256.

WRT Werner's comment, I agree that gathering entropy is a problem. 
However, a known problem with many entropy gathering daemons is that 
they overestimate the entropy they have gathered. Ross Anderson makes 
the argument, and I agree, that using a 256-bit key allows the user to 
hope that if the EGD overestimates entropy by a factor of two, then one 
still has 128-bits of entropy in his 256-bit key. This is obviously a 
hack, and the preferred solution would be to fix the EGD.

---

From: Ian Grigg <[email-masked]>
Date: Sat, 31 May 2003 11:33:58 -0400

I think it's pretty clear that both AES versions
should stay in OpenPGP.  Until the market reaches
some sort of consensus that an algorithm is dead,
discussions on the relative strengths argument would
appear not to be directly relevant to OpenPGP's
standardisation efforts?

-- 
iang

---

From: John Wilkinson <[email-masked]>
Date: Sat, 31 May 2003 17:18:45 -0400

>appear not to be directly relevant to OpenPGP's
Agreed. As long as the MUST have cipher is 3DES, we have no problems. 
When and if (hopefully never) OpenPGP chooses to deprecate 3DES in favor 
of some other cipher, be prepared for a battle...

---

From: Jon Callas <[email-masked]>
Date: Sat, 31 May 2003 15:25:41 -0700

> appear not to be directly relevant to OpenPGP's

Just to note, OpenPGP has 3 key sizes for AES. I'd be happy to drop the 192
one for simplicity's sake.

    Jon

---

From: David Shaw <[email-masked]>
Date: Sat, 31 May 2003 19:08:51 -0400

> one for simplicity's sake.

Please do not do this.  This can cause interoperability problems since
AES192 is already widely deployed and widely included in cipher
preference lists.

PGP 7 and 8 create keys with cipher preferences including "AES256,
AES192, AES128" in that order.  If AES192 is dropped, then the owner
of such a key will not be able to communicate with an implementation
that predates 2440bis and doesn't support AES256.

A somewhat contrived example, to be sure.  Still, I was and continue
to be in favor of trimming the hash and cipher algorithms, but it
seems bad form to remove a cipher that is already included in
countless cipher preference lists.

David

Date: Sat, 31 May 2003 19:08:51 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: AES-256 vs AES-128
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

> one for simplicity's sake.

Please do not do this.  This can cause interoperability problems since
AES192 is already widely deployed and widely included in cipher
preference lists.

PGP 7 and 8 create keys with cipher preferences including "AES256,
AES192, AES128" in that order.  If AES192 is dropped, then the owner
of such a key will not be able to communicate with an implementation
that predates 2440bis and doesn't support AES256.

A somewhat contrived example, to be sure.  Still, I was and continue
to be in favor of trimming the hash and cipher algorithms, but it
seems bad form to remove a cipher that is already included in
countless cipher preference lists.

David

To: John Wilkinson <[email-masked]>
Cc: [email-masked]
Subject: Re: AES-256 vs AES-128 
Date: Sat, 31 May 2003 18:55:56 -0400
From: "Steven M. Bellovin" <[email-masked]>
Sender: [email-masked]

>of some other cipher, be prepared for a battle...
AD hat on...  I would be unhappy if AES -- pick your key size -- were a 
SHOULD instead of a MUST.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

Date: Sat, 31 May 2003 15:25:41 -0700
Subject: Re: AES-256 vs AES-128
From: Jon Callas <[email-masked]>
To: <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

    Jon

Date: Sat, 31 May 2003 17:18:45 -0400
From: John Wilkinson <[email-masked]>
To: [email-masked]
Subject: Re: AES-256 vs AES-128
Sender: [email-masked]

Date: Sat, 31 May 2003 11:33:58 -0400
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
Cc: [email-masked]
Subject: Re: AES-256 vs AES-128
Sender: [email-masked]

-- 
iang

Date: Sat, 31 May 2003 09:35:29 -0400
From: John Wilkinson <[email-masked]>
To: [email-masked]
Subject: Re: AES-256 vs AES-128
Sender: [email-masked]

Date: Sat, 31 May 2003 15:10:02 +0200 (CEST)
From: [email-masked] (Bodo Moeller)
To: [email-masked]
Subject: Re: AES-256 vs AES-128
Sender: [email-masked]

To: John Wilkinson <[email-masked]>
Cc: [email-masked]
Subject: Re: AES-256 vs AES-128
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Sat, 31 May 2003 11:05:44 +0200
Sender: [email-masked]

Shalom-Salam,

   Werner

Date: Fri, 30 May 2003 22:10:55 -0400
From: John Wilkinson <[email-masked]>
To: [email-masked]
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
Sender: [email-masked]

Steve, I appreciate your comments, and while I acknowledge that the 
differing key schedules between AES-128 and AES-256 could, in theory, 
make AES-256 weaker than AES-128, IMHO, the reverse is more likely true. 
It bears repeating that I don't think it makes much difference, since, 
in practice, both are likely to remain unbroken for at least a few decades.

If one recoveres a single round key from AES-128, one can calculate all 
the other round keys, and the primary key. This is by design, to 
conserve on memory, since the expanded key does not need to be stored. 
With AES-256, one has to recover two (consecutive?) round keys to 
recover the other round keys or the primary key. So, I respectfully 
disagree that AES-256 suffers from the problem of trying to spread 
"twice as many bits over less than twice as many operations."

Date: Fri, 30 May 2003 21:32:52 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
Mail-Followup-To: [email-masked]
Sender: [email-masked]

David

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked]
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes) 
Date: Sat, 31 May 2003 09:52:53 +0900
Sender: [email-masked]

Regards,

To: [email-masked]
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes) 
Date: Fri, 30 May 2003 20:46:35 -0400
From: "Steven M. Bellovin" <[email-masked]>
Sender: [email-masked]

Although I'm not concerned about 128-bit keys being too short -- I 
don't think there will *ever* be a brute-force attack on 128 bits -- 
there are some points to think about.  In Rich Schroeppel's comments on 
AES (see http://csrc.nist.gov/CryptoToolkit/aes/round2/comments/R2comments.txt)
he notes that

	Except for RC6 and perhaps Mars, all the ciphers have the property that
	recovering the expanded key will translate into recovering the primary
	key.  More seriously, the key schedules of Rijndael, and to some extent
	Serpent, allow an attacker who recovers (or guesses) some of the
	expanded key to compute additional bits of the expanded key.  Recall
	that both differential and linear attacks on DES benefited from
	replicated subkey bits -- as soon as an attack finds a few subkey bits,
	the game is over.

If the additional rounds for AES256 are not enough to properly mix in 
the extra key bits -- we're spreading twice as many bits over less than 
twice as many operations -- it might (repeat, *might*) make it easier 
to recover some key bits.

But -- no, I don't think that AES256 is less secure than AES128.  I 
also don't think it's needed.  Remember that if you're worried about 
O(2^128) attacks, you really need a much larger public key, too.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

Date: Fri, 30 May 2003 19:48:34 -0400
From: John Wilkinson <[email-masked]>
To: [email-masked]
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
Sender: [email-masked]

Date: Fri, 30 May 2003 22:35:23 +0100
From: Adam Back <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked], Adam Back <[email-masked]>
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
Sender: [email-masked]

Adam

To: Adam Back <[email-masked]>
Cc: "Jeroen C. van Gelderen" <[email-masked]>, Richard Laager <[email-masked]>, [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
Date: 30 May 2003 15:57:14 -0400
Lines: 45
Sender: [email-masked]

-derek

Date: Fri, 30 May 2003 20:48:17 +0100
From: Adam Back <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: "Jeroen C. van Gelderen" <[email-masked]>, Richard Laager <[email-masked]>, [email-masked]
Subject: AES-256 vs AES-128 (Re: Suggested DER Prefixes)
Sender: [email-masked]

Adam

Date: Thu, 29 May 2003 18:55:43 -0700
Subject: Re: Use of the term "notarised signature"?
From: Jon Callas <[email-masked]>
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 5/29/03 4:33 PM, "Ian Grigg" <[email-masked]> wrote:
>  0x50: 3rd party confirmatory signature.

I used "Third-Party Confirmation Signature."

    Jon

Date: Thu, 29 May 2003 18:50:42 -0700
Subject: Re: Suggested DER Prefixes
From: Jon Callas <[email-masked]>
To: Richard Laager <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

    Jon

Date: Thu, 29 May 2003 21:39:50 -0400
From: David Shaw <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Use of the term "notarised signature"?
Mail-Followup-To: Derek Atkins <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Thu, May 29, 2003 at 07:33:26PM -0400, Derek Atkins wrote:

> This is orthogonal to the issue of whether the OpenPGP Notarized
> Signature is useful to a "Notary" (in the legal sense).  Making
> something that is useful is a Good Thing (TM).  I'd rather make
> something useful than make something non-useful.  But not being
> a lawyer (or a Notary) I don't know what would be useful.

I did some research on this a while back.  One of the services that a
(U.S.) notary provides is "acknowledgment", which to my non-notary eye
looked reasonably close to what we're talking about here.  This is the
notary taking note that a document was signed, and documenting the
fact that notice was taken.  The contents of the document are
generally irrelevant here: just that it was signed and the signer
requested a notary to note that fact (and presumably witness the
making of the signature).  The main difference between an
acknowledgment and this is that generally an acknowledgment contains
the statement that the original signer signed the document by his/her
own free will.

When I asked a lawyer and notary friend about it, she said that the
match I had imagined wasn't so good.  In general, real life notary
functions are far more concerned with identification of the signer
than they are about the immutability of the signed document or
signature itself.  Could the building blocks (signature, notary
signature) we have in OpenPGP be usable to a real notary?  Maybe - but
a number of underlying laws and/or assumptions and/or infrastructure
would have to change first.

David

Date: Fri, 30 May 2003 12:40:21 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Suggested DER Prefixes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Derek Atkins <[email-masked]> writes:
>I certainly did not say "less secure", did I?  It's certainly much SLOWER,

"very slightly slower", although given people's obsession with speed at any
cost I guess it'd be safe to say "unacceptably (to the user) slower".

Peter.

Date: Thu, 29 May 2003 19:33:02 -0400
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: David Shaw <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Use of the term "notarised signature"?
Sender: [email-masked]

David Shaw wrote:
> Hash: SHA1
> On Thu, May 29, 2003 at 01:25:14PM -0400, Ian Grigg wrote:
> >
> > When the word "notarised signature" is used, is this
> > a term that has been tested against the legal meaning
> > of the words?
> >
> > Specifically, the term has quite different significances
> > under civil code and common law.  In the civil code, a
> > notary is a very important person, perhaps more significant
> > than an attorney.  He or she has to study for 6 years to
> > obtain their qualification, and it is a tightly constrained
> > field (at least in the country I'm mildly familiar with).
> 
> The term "notary signature" should not imply any legal meaning
> whatsoever.  As you point out, it means different things to different
> people in different places.
> 
> I can't imagine the terminology is a problem.  After all, the terms
> "signature", and "certification" mean different things in different
> legal juristictions as well, and PGP has been using those terms for
> over a decade.

Right.  That precisely is the issue, in that it
has been observed that the misuse of the word
'signature' by the cryptographic communiity has
contributed to the mess that is CAs and PKIs...

People have understood that digital signatures
imply legal signatures in some hand waving sense.
People have therefore tried to build systems to
use digital signatures to replace other forms,
generally with little success.

So, I guess what I'm saying is this:  If one
subscribes to the view that a bug in "digital
signatures" is the word "signature", then
perhaps we should not compound that bug by
expanding the term to "notarised signature".

If so, then what in cryptographic terms is
that new form of signature?  As far as I can
see it is a 3rd party signature over a sig:

   0x50: Notary signature.
       This signature is a signature over some other OpenPGP signature
       packet. It is a notary seal on the signed data. ...

I'd suggest something like:

   0x50: 3rd party confirmatory signature.
       This signature is a signature over some other OpenPGP signature
       packet. It provides a mechanism for a 3rd party to confirm the
       first signature over the signed data, and is analogous to a
       notary seal. ...

Except that is a little clumsy.

(also 5.2.3.25.)

> > If not, as a minimum, it might be a good idea to add
> > a statement that the use of the term is not meant to
> > draw from the legal definition(s) of same.
> 
> I'm okay with this if the WG thinks it is necessary, though if we're
> going to go down that route, it would probably be simpler to put a
> single sentence in the introduction disclaiming any legal standing for
> terminology used in the whole document than it would be to add
> specific notes to the notary section.

Sure.  I'm not wedded to the change myself,
I'm just much more sensitive to the legal
system having been recently squeezed through
the mill (and, PGP signatures played a small
part in that ;-)

My perspective comes down to:  "how can we
reduce costs in future disputes?"

The issue with the current text would be
that some poor muggins might have to go
through a court case explaining why the
phrase

    "It is a notary seal on the signed data."

does not imply that it is a notary seal on
the signed data, and the person who signed
it is not fraudulently purporting to be a
notary.

As the text is quite explicit as to what
it is (normally a laudable objective!),
and as the program (optimistically)
conforms to the RFC, then he has a bit
of a battle making the alternate case...

-- 
iang

To: David Shaw <[email-masked]>
Cc: OpenPGP <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Use of the term "notarised signature"?
Date: 29 May 2003 19:33:26 -0400
Lines: 60
Sender: [email-masked]

Ian,

Feel free to bring a lawyer to the table to provide input, but we're
here to create Internet Standards, not Legal Standards.  So long as we
define our own terminology (or use references to definitions) I see no
problem with using the same term as another field in a way different
than that other field uses it.

This is orthogonal to the issue of whether the OpenPGP Notarized
Signature is useful to a "Notary" (in the legal sense).  Making
something that is useful is a Good Thing (TM).  I'd rather make
something useful than make something non-useful.  But not being
a lawyer (or a Notary) I don't know what would be useful.

I would think that having the ability to reference just the signature
or also sig + document in a notary signature would be sufficient to be
useful to any definition of notary....

-derek

David Shaw <[email-masked]> writes:

> On Thu, May 29, 2003 at 01:25:14PM -0400, Ian Grigg wrote:
> > 
> > When the word "notarised signature" is used, is this
> > a term that has been tested against the legal meaning
> > of the words?
> > 
> > Specifically, the term has quite different significances
> > under civil code and common law.  In the civil code, a
> > notary is a very important person, perhaps more significant
> > than an attorney.  He or she has to study for 6 years to
> > obtain their qualification, and it is a tightly constrained
> > field (at least in the country I'm mildly familiar with).
> 
> The term "notary signature" should not imply any legal meaning
> whatsoever.  As you point out, it means different things to different
> people in different places.
> 
> I can't imagine the terminology is a problem.  After all, the terms
> "signature", and "certification" mean different things in different
> legal juristictions as well, and PGP has been using those terms for
> over a decade.
> 
> > If not, as a minimum, it might be a good idea to add
> > a statement that the use of the term is not meant to
> > draw from the legal definition(s) of same.
> 
> I'm okay with this if the WG thinks it is necessary, though if we're
> going to go down that route, it would probably be simpler to put a
> single sentence in the introduction disclaiming any legal standing for
> terminology used in the whole document than it would be to add
> specific notes to the notary section.
> 
> David

Date: Thu, 29 May 2003 14:55:26 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Use of the term "notarised signature"?
Mail-Followup-To: OpenPGP <[email-masked]>
Sender: [email-masked]

On Thu, May 29, 2003 at 01:25:14PM -0400, Ian Grigg wrote:
> 
> When the word "notarised signature" is used, is this
> a term that has been tested against the legal meaning
> of the words?
> 
> Specifically, the term has quite different significances
> under civil code and common law.  In the civil code, a
> notary is a very important person, perhaps more significant
> than an attorney.  He or she has to study for 6 years to
> obtain their qualification, and it is a tightly constrained
> field (at least in the country I'm mildly familiar with).

The term "notary signature" should not imply any legal meaning
whatsoever.  As you point out, it means different things to different
people in different places.

I can't imagine the terminology is a problem.  After all, the terms
"signature", and "certification" mean different things in different
legal juristictions as well, and PGP has been using those terms for
over a decade.

> If not, as a minimum, it might be a good idea to add
> a statement that the use of the term is not meant to
> draw from the legal definition(s) of same.

I'm okay with this if the WG thinks it is necessary, though if we're
going to go down that route, it would probably be simpler to put a
single sentence in the introduction disclaiming any legal standing for
terminology used in the whole document than it would be to add
specific notes to the notary section.

David

Date: Thu, 29 May 2003 13:27:47 -0500
To: Jeroen van Gelderen <[email-masked]>
From: Mike Markowitz <[email-masked]>
Subject: AES-128 (was Re: Suggested DER Prefixes)
Cc: Derek Atkins <[email-masked]>, "Richard Laager" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

-mjm 

Date: Thu, 29 May 2003 13:25:14 -0400
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
Cc: OpenPGP <[email-masked]>
Subject: Use of the term "notarised signature"?
Sender: [email-masked]

When the word "notarised signature" is used, is this
a term that has been tested against the legal meaning
of the words?

Specifically, the term has quite different significances
under civil code and common law.  In the civil code, a
notary is a very important person, perhaps more significant
than an attorney.  He or she has to study for 6 years to
obtain their qualification, and it is a tightly constrained
field (at least in the country I'm mildly familiar with).

When a notary notarises a document in a civil law country,
he is inherently taking some view on the document.  In
some cases, a notary refuses to participate on some
arbitrary grounds such as an unfamiliar document or a
person not within jurisdiction.  Signatures also may be
meaningless unless notarised.

This seems to be in complete contrast to the common law
view, where only the signature is notarised and the signer
is identified.

My question then would be, has anyone tested this notion
of implying a notary function with a civil law expert?

If not, as a minimum, it might be a good idea to add
a statement that the use of the term is not meant to
draw from the legal definition(s) of same.

Or, describe the feature as potentially providing a
feature useful for notaries, rather than calling it
"notarised signatures."

The main issue here is that if someone does use OpenPGP's
new notarised signature form, will that imply an
unexpected legal meaning in the wrong country?  I know
some countries are very jumpity about the misuse of
terms, and at least one big/rich country in particular
puts people in jail for misrepresenting their status.

(Apologies for jumping in late and briefly on this one.)

-- 
iang

Date: Thu, 29 May 2003 13:05:08 -0400
Subject: Re: Suggested DER Prefixes
Cc: "Richard Laager" <[email-masked]>, <[email-masked]>
To: Derek Atkins <[email-masked]>
From: Jeroen van Gelderen <[email-masked]>
Sender: [email-masked]

Cheers,
-J

To: "Jeroen C. van Gelderen" <[email-masked]>
Cc: "Richard Laager" <[email-masked]>, <[email-masked]>
From: Derek Atkins <[email-masked]>
Subject: Re: Suggested DER Prefixes
Date: 29 May 2003 12:55:29 -0400
Lines: 24
Sender: [email-masked]

-derek

Date: Thu, 29 May 2003 12:52:56 -0400
Subject: Re: Suggested DER Prefixes
Cc: "Richard Laager" <[email-masked]>, <[email-masked]>
To: Derek Atkins <[email-masked]>
From: "Jeroen C. van Gelderen" <[email-masked]>
Sender: [email-masked]

Cheers!
-J

To: "Richard Laager" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Suggested DER Prefixes
From: Derek Atkins <[email-masked]>
Date: 29 May 2003 11:21:56 -0400
Lines: 21
Sender: [email-masked]

-derek

From: "Richard Laager" <[email-masked]>
To: <[email-masked]>
Subject: RE: Suggested DER Prefixes
Date: Thu, 29 May 2003 09:44:11 -0500
Organization: Wikstrom Telecom Internet
Importance: Normal
Sender: [email-masked]

Thanks,
Richard Laager

To: Jon Callas <[email-masked]>
Cc: "Imad R. Faiad" <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Suggested DER Prefixes 
Date: Thu, 29 May 2003 07:30:40 -0400
From: "Steven M. Bellovin" <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Jon Callas writes:

>cool idea, but it never went anywhere, for a number of reasons.

And with the advent of AES, I don't forsee anyone using it.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

Date: Thu, 29 May 2003 00:50:53 -0700
Subject: Re: Suggested DER Prefixes
From: Jon Callas <[email-masked]>
To: "Imad R. Faiad" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

    Jon

Date: Wed, 28 May 2003 23:23:18 -0400
From: David Shaw <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: Signature targets and where they should be used
Mail-Followup-To: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On Tue, May 27, 2003 at 07:57:35PM -0700, Jon Callas wrote:
> 
> On 4/16/03 2:38 PM, "David Shaw" <[email-masked]> wrote:
> 
> Is there a consensus on this?
> 
> Personally, I think that the SHOULD is good enough. If you want to do a
> blind notary, you have the perfect reason not to put the target packet
> there.
> 
> However, I included this text: "Note that we really do mean SHOULD. There
> are plausible uses for this (such a a blind notary that only sees the
> signature, not the key nor source document) that cannot include a target
> subpacket."

The gist of my original comment was that a signature target is
actually needed when issuing a certification revocation signature
(i.e. 0x30).  This is a signature (the 0x30 sig) on the hash of an
object (the pk+user ID) that actually refers to another signature (the
signature being revoked).  A signature target there is necessary to
know which signature is being revoked.

With notary signatures, on the other hand, it is clear which signature
is being signed.  The notary signature itself won't even verify if we
check it against the wrong signature.  Including a signature target
there is like making a signature (the 0x50) on the hash of an object
(the signature being notarized), that contains a second copy of the
signature being notarized in the signature target subpacket.  Why
SHOULD someone include it twice?

Saying nothing at all on the subject of signature targets and notary
signatures, or even making it a "MAY" just seems simpler.

All that said, I'm okay with the added clarification above. :)

David

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Suggested DER Prefixes
Date: Thu, 29 May 2003 00:12:53 +0200
Organization: ECLiPSE
Sender: [email-masked]

Hello Mr Callas,

my 2c,

Best Regards,

Imad R. Faiad

>Now that there are the wide SHAs, they are what you should be

Date: Tue, 27 May 2003 19:57:35 -0700
Subject: Re: Signature targets and where they should be used
From: Jon Callas <[email-masked]>
To: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 4/16/03 2:38 PM, "David Shaw" <[email-masked]> wrote:

Is there a consensus on this?

Personally, I think that the SHOULD is good enough. If you want to do a
blind notary, you have the perfect reason not to put the target packet
there.

However, I included this text: "Note that we really do mean SHOULD. There
are plausible uses for this (such a a blind notary that only sees the
signature, not the key nor source document) that cannot include a target
subpacket."

    Jon

> Hash: SHA1
> On Wed, Apr 16, 2003 at 03:40:24PM -0400, Michael Young wrote:
>> 
>> From: "David Shaw" <[email-masked]>
> 
>>> In the case of notary signatures, there is no "C" to specify.  It is
>>> merely signature A (the 0x50 signature), on data B (the signature to
>>> be notarized).  There is no benefit in specifying B twice as the data
>>> to be signed and then again as an additional subpacket.
>> 
>> I'd agree that the benefit is slight at best.  I suppose if
>> you had "B" and the material it covered (so that you could generate
>> B's hash), and you had a disorganized bunch of notary signatures,
>> then you could pick out the matching ones faster if they had
>> target subpackets.  This doesn't seem like a compelling scenario. :-)
> 
> There is actually another reason why using targets for notary
> signatures is not really good: one of the nice features of notary
> signatures is that the notarizer doesn't need the original signer's
> public key or the material the original signature covered.  All the
> notarizer needs is the signature packet.  Unfortunately, to use a
> signature target in the notary signature, the notarizer needs the
> original signer's public key to extract the hash from the original
> signature packet...
> 
> I suppose we could solve that problem by defining a signature target
> to be the canonical hash of the signature being targeted, but even
> then there is still no good reason why using a target for notary
> signatures needs to be a SHOULD.
> 
> David
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2rc2 (GNU/Linux)
> Comment: http://www.jabberwocky.com/david/keys.asc
> 
> iD8DBQE+nc1c4mZch0nhy8kRAjTQAJ42SnhAoD42MFWJjin3KJXBxZrMDACeNDqK
> hGj20/LjG6I8lBPGqigWOlA=
> =a8B8
> -----END PGP SIGNATURE-----
> 

Date: Wed, 21 May 2003 09:34:17 -0700
Subject: Re: Suggested DER Prefixes
From: Jon Callas <[email-masked]>
To: "Imad R. Faiad" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

    Jon

From: "Imad R. Faiad" <[email-masked]>
To: [email-masked]
Subject: Suggested DER Prefixes
Date: Wed, 21 May 2003 13:11:35 +0200
Organization: ECLiPSE
Sender: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

Greetings,

Best regards

Imad R Faiad

Date: Tue, 6 May 2003 15:20:40 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Administrivia
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, May 01, 2003 at 01:24:11PM -0400, Derek Atkins wrote:

> As was announced yesterday, I'm the new chair of OpenPGP.  My goals
> (as somewhat explained to me by the ADs) are to finish up the existing
> work and try to ramp down the WG.  This means finishing up all the
> open issues, getting 2440bis out the door, and either shutting down
> or rechartering based on what else is left to do.

I'm curious what shutting down actually entails.  Once 2440bis is
complete, what happens when/if something needs to happen in the
OpenPGP space?  Is the WG officially reconvened, or are things not
that formal?  Even if the WG is shut down, I think it would be useful
if this mailing list would continue to exist.  It is a good forum,
with an excellent signal to noise ratio, and it reaches nearly all of
the people working on OpenPGP today.

David

From: "Steven M. Bellovin" <[email-masked]>
To: David Shaw <[email-masked]>
Cc: [email-masked]
Subject: Re: OpenPGP Administrivia 
Date: Tue, 06 May 2003 17:45:20 -0400
Sender: [email-masked]

In message <[email-masked]>, David Shaw writes:
>Hash: SHA1
>On Thu, May 01, 2003 at 01:24:11PM -0400, Derek Atkins wrote:
>
>> As was announced yesterday, I'm the new chair of OpenPGP.  My goals
>> (as somewhat explained to me by the ADs) are to finish up the existing
>> work and try to ramp down the WG.  This means finishing up all the
>> open issues, getting 2440bis out the door, and either shutting down
>> or rechartering based on what else is left to do.
>
>I'm curious what shutting down actually entails.  Once 2440bis is
>complete, what happens when/if something needs to happen in the
>OpenPGP space?  Is the WG officially reconvened, or are things not
>that formal?  Even if the WG is shut down, I think it would be useful
>if this mailing list would continue to exist.  It is a good forum,
>with an excellent signal to noise ratio, and it reaches nearly all of
>the people working on OpenPGP today.
>

Mailing lists can (and often do) continue indefinitely.

As for the WG -- it can go dormant, or it can be disbanded.  If there's 
a need for a new WG in that space, one can be spun up -- the issue 
would be the charter, since any new WG would be doing something 
different.  Minor changes could be done by individual submissions.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

Date: Tue, 6 May 2003 15:20:40 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Administrivia
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, May 01, 2003 at 01:24:11PM -0400, Derek Atkins wrote:

> As was announced yesterday, I'm the new chair of OpenPGP.  My goals
> (as somewhat explained to me by the ADs) are to finish up the existing
> work and try to ramp down the WG.  This means finishing up all the
> open issues, getting 2440bis out the door, and either shutting down
> or rechartering based on what else is left to do.

I'm curious what shutting down actually entails.  Once 2440bis is
complete, what happens when/if something needs to happen in the
OpenPGP space?  Is the WG officially reconvened, or are things not
that formal?  Even if the WG is shut down, I think it would be useful
if this mailing list would continue to exist.  It is a good forum,
with an excellent signal to noise ratio, and it reaches nearly all of
the people working on OpenPGP today.

David

Date: Sat, 3 May 2003 20:34:10 +0100
From: Adam Back <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: CFB vs CBC (Re: Low-level question about OpenPGP - why CFB mode?)
Sender: [email-masked]

PKCS#5 padding is simple to code, however:

- having to pad at all is an inconvenience for some applications where
  space is tight

- having to pad is inconvenent for streaming (need to know ahead when
  the last block is)

- there are people who have used non-PKCS#5 padding, and instead made
  up their own (clueless people, etc; but it's one more thing)

- the PKCS#5 padding end tag offers tends to encourage programmers to
  make their implementations into decryption oracles which can be used
  as an attack point (viz the interactive attack against block ciphers
  using the misformed padding error)

- the psuedo-IV handling (requirement not repeat IV for same key) is a
  non-issue in most contexts where the key changes everytime anyway
  (symmetric key transport already covers cases in PGP where the
  symmetric key is derived from a password)

Adam

On Thu, May 01, 2003 at 07:15:39PM +1200, Peter Gutmann wrote:
> >On use of CFB instead of CBC, I think this is actually goos because it avoids
> >the whole padding issue which people frequently get wrong with bad security
> >implications.  Plus it's simpler to not have to pad. Error recovery is a
> >phantom property, as in no mode is it secure.
> 
> PKCS #5 padding is trivial to get right, any minor gains are more than made up
> for by the painful and clunky pseudo-IV handling, particularly since most
> crypto implementations have an "IV, data, go"-type interface which requires
> error-prone manual handling of the pseudo-IV.
> 
> Peter.

Date: Thu, 01 May 2003 15:47:22 -0700
Subject: Re: OpenPGP Administrivia
From: Jon Callas <[email-masked]>
To: Derek Atkins <[email-masked]>, David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Sender: [email-masked]

On 5/1/03 3:16 PM, "Derek Atkins" <[email-masked]> wrote:

> 
> This is indeed part of what I was looking for.  Jon, what's the
> current status of the work on -08?

I have a number of changes done. What I have pending is some work
deprecating old stuff as we've discussed. We also need to break up the
references into normative and non-normative. Those are the big ones.

I am looking forward to having a place where issues can be stored.

    Jon

To: David Shaw <[email-masked]>
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: OpenPGP Administrivia
Date: 01 May 2003 18:16:23 -0400
Lines: 28
Sender: [email-masked]

This is indeed part of what I was looking for.  Jon, what's the
current status of the work on -08?

-derek

David Shaw <[email-masked]> writes:

> On Thu, May 01, 2003 at 01:24:11PM -0400, Derek Atkins wrote:
> 
> > However, one thing I am lacking is a list of open issues in the
> > existing work.  I'm hoping that John or Jon has a list so we can
> > seed the RT queue.  If all else fails I can go re-read the last
> > year's worth of email and try to glom out the open issues (but I
> > suspect many of the issues are older than that).  You can send
> > issues to the list, to me directly, or add them to the RT queue.
> 
> One thing that would be useful would be to know exactly where we stand
> now in 2440bis.  The last draft was bis-07 from March, but there have
> been a number of issues discussed since then, and it is not clear
> which were incorporated (or earmarked for later incorporation) into
> the draft.  A diff (or an 08) would be extremely helpful.
> 
> David

Date: Thu, 1 May 2003 17:50:44 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Administrivia
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, May 01, 2003 at 01:24:11PM -0400, Derek Atkins wrote:

> However, one thing I am lacking is a list of open issues in the
> existing work.  I'm hoping that John or Jon has a list so we can
> seed the RT queue.  If all else fails I can go re-read the last
> year's worth of email and try to glom out the open issues (but I
> suspect many of the issues are older than that).  You can send
> issues to the list, to me directly, or add them to the RT queue.

One thing that would be useful would be to know exactly where we stand
now in 2440bis.  The last draft was bis-07 from March, but there have
been a number of issues discussed since then, and it is not clear
which were incorporated (or earmarked for later incorporation) into
the draft.  A diff (or an 08) would be extremely helpful.

David

From: "Steven M. Bellovin" <[email-masked]>
To: [email-masked]
Subject: Re: OpenPGP Administrivia 
Date: Thu, 01 May 2003 14:31:47 -0400
Sender: [email-masked]

In message <[email-masked]>, Derek Atkins writes:
>
>A clueful member of the WG asked:
>
>> What is the username and password for the RT?
>
>Unfortunately I was just informed that the RT Queue is not completely
>set up for public access, yet.  I'm sorry for jumping the gun on
>publishing the URL.  I'll let you know the guest username/password
>when I find it out.  I'm an RT newbie myself and have never used it
>before, so I was unaware of the lack of prominent guest account.
>
>I'll be sure to mail out the info as soon as I find it.

To amplify what Derek said -- this is intended to be very open, but 
we're just not there yet.  The server was set up (literally) yesterday; 
we haven't finished configuring it yet.

My goal as AD is to make simple-to-use management tools available to 
all WG chairs.  We need to learn what functions are needed, and how 
best to use common tools.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

To: [email-masked]
Cc: Derek Atkins <[email-masked]>
Subject: Re: OpenPGP Administrivia
From: Derek Atkins <[email-masked]>
Date: 01 May 2003 13:53:05 -0400
Lines: 58
Sender: [email-masked]

A clueful member of the WG asked:

> What is the username and password for the RT?

Unfortunately I was just informed that the RT Queue is not completely
set up for public access, yet.  I'm sorry for jumping the gun on
publishing the URL.  I'll let you know the guest username/password
when I find it out.  I'm an RT newbie myself and have never used it
before, so I was unaware of the lack of prominent guest account.

I'll be sure to mail out the info as soon as I find it.

-derek

> Derek Atkins <[email-masked]> writes:
> 
> > Hi,
> >
> > As was announced yesterday, I'm the new chair of OpenPGP.  My goals
> > (as somewhat explained to me by the ADs) are to finish up the existing
> > work and try to ramp down the WG.  This means finishing up all the
> > open issues, getting 2440bis out the door, and either shutting down
> > or rechartering based on what else is left to do.
> >
> > Another task that I've been asked is to use an online system to keep
> > track of all the open issues.  To further this end we've had an RT
> > Queue created at https://rt.psg.com/ to keep track of all the open
> > issues.  I'd like to try to use this system to make sure we don't lose
> > anything through the cracks.  However, I'm as new to this as you are,
> > so this is going to be a learning experience for all of us.  The ADs
> > have asked for me to write up the issues with using RT.
> >
> > However, one thing I am lacking is a list of open issues in the
> > existing work.  I'm hoping that John or Jon has a list so we can seed
> > the RT queue.  If all else fails I can go re-read the last year's
> > worth of email and try to glom out the open issues (but I suspect many
> > of the issues are older than that).  You can send issues to the list,
> > to me directly, or add them to the RT queue.
> >
> > Lastly, Vienna is coming up soon (well, soonish)...  If we're going to
> > meet I need to know if we have topics to discuss, and if so what they
> > are and how long it will take.  We still have plenty of time to request
> > a slot, but as always the early-bird gets the good slots ;)
> >
> > That's all for now, from your friendly neighborhood working-group chair.
> >
> > -derek
> >
> > -- 
> >        Derek Atkins

To: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: OpenPGP Administrivia
Date: 01 May 2003 13:24:11 -0400
Lines: 36
Sender: [email-masked]

Hi,

As was announced yesterday, I'm the new chair of OpenPGP.  My goals
(as somewhat explained to me by the ADs) are to finish up the existing
work and try to ramp down the WG.  This means finishing up all the
open issues, getting 2440bis out the door, and either shutting down
or rechartering based on what else is left to do.

Another task that I've been asked is to use an online system to keep
track of all the open issues.  To further this end we've had an RT
Queue created at https://rt.psg.com/ to keep track of all the open
issues.  I'd like to try to use this system to make sure we don't lose
anything through the cracks.  However, I'm as new to this as you are,
so this is going to be a learning experience for all of us.  The ADs
have asked for me to write up the issues with using RT.

However, one thing I am lacking is a list of open issues in the
existing work.  I'm hoping that John or Jon has a list so we can seed
the RT queue.  If all else fails I can go re-read the last year's
worth of email and try to glom out the open issues (but I suspect many
of the issues are older than that).  You can send issues to the list,
to me directly, or add them to the RT queue.

Lastly, Vienna is coming up soon (well, soonish)...  If we're going to
meet I need to know if we have topics to discuss, and if so what they
are and how long it will take.  We still have plenty of time to request
a slot, but as always the early-bird gets the good slots ;)

That's all for now, from your friendly neighborhood working-group chair.

-derek

To: [email-masked]
Cc: [email-masked]
From: Derek Atkins <[email-masked]>
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Date: 01 May 2003 12:32:44 -0400
Lines: 29
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:

> In the spirit of improving the codability of
> OpenPGP, I'd suggest it be replaced with a
> standard textbook or FIPS mode.

<chair hat>

In the interest of finishing the OpenPGP work, I claim it is too late
in the process to make such a major change to the protocol in terms of
losing compatibility with all prior versions.  Having implemented this
non-FIPS mode, it is NOT that complicated, and the text we have that
describes it (indeed, the text in RFC 1991 that described it!) has never
been a hinderance to implementation.

The only questions have been "why do you do it this way?" which is not
IMHO a reasonable reason to force a change at this late date.  It may
be a reasonable reason to add text explaining why we do it this way,
or comparing it to the FIPS CFB mode, but that could go in an appendix
just as easily as it could go into the text.

</chair hat>

-derek

Date: Thu, 01 May 2003 11:54:46 -0400
From: Ian Grigg <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Sender: [email-masked]

Peter Gutmann wrote:
> 
> "Hal Finney" <[email-masked]> writes:
> 
> >I think this may have been the reason that Phil chose CFB.  As for the non-
> >standard "sync" operation, I don't remember why he did that. Probably it just
> >seemed to be a natural way of handling CFB given his understanding of its
> >rationale in terms of the way it interfaced with the underlying cipher.
> 
> I believe it was an implementation bug/quirk, not a deliberate design
> decision.

I had heard that it was an attempt to make it
"more secure", like the salting of the Unix
password (DES) :-)

Either way, their appears
to be no justification for continuing its use,
and a good reason for deprecating it:  it is
rather complex to document and program up, this
conversation about the munged CFB mode has been
had many times in the past (here and elsewhere)
and will be had many times in the future.

In the spirit of improving the codability of
OpenPGP, I'd suggest it be replaced with a
standard textbook or FIPS mode.

(Not in the current version of course, but at
the next convenient moment.)

-- 
iang

Date: Thu, 1 May 2003 19:15:39 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Low-level question about OpenPGP - why CFB mode?
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Adam Back <[email-masked]> writes:

>On use of CFB instead of CBC, I think this is actually goos because it avoids
>the whole padding issue which people frequently get wrong with bad security
>implications.  Plus it's simpler to not have to pad. Error recovery is a
>phantom property, as in no mode is it secure.

PKCS #5 padding is trivial to get right, any minor gains are more than made up
for by the painful and clunky pseudo-IV handling, particularly since most
crypto implementations have an "IV, data, go"-type interface which requires
error-prone manual handling of the pseudo-IV.

Peter.