Subject: Re: Mandatory Algorithm Changes?

From: [email-masked] ("Hal Finney")
Date: Tue, 8 Feb 2005 11:44:42 -0800 (PST)

I agree with Werner specifically that it seems premature to jump
onto SHA-256, at this time of flux in the cryptographic commmunity's
understanding of hash functions.  MD5 and several other comparable hashes
are broken but the techniques are still secret and unpublished AFAIK.
Reduced forms of SHA-1 have some attacks but the full version is still OK.
There were even comments suggesting that the SHA-256 family may not be
as secure as was previously believed.

I haven't heard much more about these since then.  Looking at the IACR
eprints archive, I find http://eprint.iacr.org/2005/010 from January 2005,
by Rijmen and Oswald:

"We report on the experiments we performed in order to assess the security
of SHA-1 against the attack by Chabaud and Joux. We present some ideas for
optimizations of the attack and some properties of the message expansion
routine. Finally, we show that for a reduced version of SHA-1, with 53
rounds instead of 80, it is possible to find collisions in less than
$2^{80}$ operations."

That's the known state of the art, and it's not terribly worrisome,
but these researchers are not employing the secret Chinese techniques.
SHA-1 is structurally similar to MD5 so there is reason to fear that the
MD5 break could be extended to SHA-1, either by the original researchers,
or by others once they publish their methods.  OTOH SHA-1 does have some
twists and complexity that MD5 does not, which could immunize it against
the attacks.

The information on SHA-256 is available at http://eprint.iacr.org/2004/207,
by Hawkes et al.  While this is not an attack, it shows flaws in an
earlier analysis that suggested that the SHA-256 family was strong in
certain ways.

All in all the field is in turmoil these days.  I would hesitate to take
any steps right now with the hash functions, beyond of course deprecating
MD5 as we have done.

Hal Finney

---

From: Ian G <[email-masked]>
Date: Tue, 08 Feb 2005 21:27:30 +0000

I agree that switching from SHA1 to SHA256 seems
like a move without clear basis, given the results
from that last conference.  I think we just have to
sit it out and see what happens.

As far as AES is concerned, I'm less definately for
or against ;)

I can't see a problem directly with making it a must,
as we are now at the point where TDES is "ok if
you have to but we'd rather you didn't."  (The
comments by Steve Bellovin last week were new
for me at least.)

If both of the major OpenPGP implementations
already support it, is there any reason to doubt
the little guys will follow along eventually?

(I agree it should be AES128 that should be the
must, if it is going that way...)

iang

-- 
News and views on what matters in finance+crypto:
        http://financialcryptography.com/

---

From: Werner Koch <[email-masked]>
Date: Wed, 09 Feb 2005 08:39:02 +0100

> the little guys will follow along eventually?

There are other implementations using OpenPGP as well.  For embedded
systems adding another MUST cipher is a problem, in particular if 3DES
is already done in (old) hardware.  There might also be the need to
implement the preferences system unless both, 3DES and AES, are
declared as fallback algorithms.

Shalom-Salam,

   Werner

---

From: Ian G <[email-masked]>
Date: Wed, 09 Feb 2005 12:25:14 +0000

>declared as fallback algorithms.

Right, in that it's a given that there are always
problems for any change.  But let's explore this
a bit more.

What is being changed (suggested) is the OpenPGP
RFC - standard.  No implementation needs to change,
and the only implementations that would want to
change would be future ones that need to adhere
to the standard.

Embedded devices don't really need to adhere
(here, I am assuming that such embedded are
totally embedded and aren't communicating
with the open email community).

Also, as time goes on, those that do not support
AES are going to raise more and more eyebrows.
I think the time is going to come fairly shortly
where I'd say "implementing AES" was more
important than "slavishly following the standard
in every detail."

Are there any little guys here would like to add
anything?  Positive or negative?

FTR: Edwin informs me that the Cryptix OpenPGP
has no objection.

(Which should be taken to mean I vote for the
change - I'm just playing the devil's advocate here.)

iang

---

From: Jon Callas <[email-masked]>
Date: Thu, 10 Feb 2005 17:11:30 -0800

Mandatory-to-implement does not mean mandatory-to-use.

If we change 3DES to AES, things don't instantly stop working. If we do 
that, 3DES would be a SHOULD, of course, and there will be a note that 
says that if you don't implement 3DES there could be interoperability 
issues.

I don't think that any reasonable implementor is going to run right out 
and code stupidly. It will obviously take a couple of years before 
someone can safely assume, for example, that the 
algorithm-of-last-resort would be AES.

However, if we ever want to roll 3DES over to AES, we have to start 
sometime. The couple of years of bake-in doesn't start until a change 
is made. Why not now?

I'm willing to concede the point on SHA-256, I wouldn't have brought it 
up at all if NIST hadn't said a couple days ago they're phasing out 
SHA-1 and rolling to SHA-256.

	Jon

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Feb 2005 09:23:28 +0000

Jon Callas wrote:
> sometime. The couple of years of bake-in doesn't start until a change is 
> made. Why not now?
> 

Oops. What I said was that this seems like a candidate for having flags 
in the PGP certificates that say what is supported by the receiving 
application(s).

Cheers,

Ben.

-- 
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: Werner Koch <[email-masked]>
Date: Mon, 21 Feb 2005 12:03:44 +0100

On Mon, 21 Feb 2005 09:23:28 +0000, Ben Laurie said:

> Oops. What I said was that this seems like a candidate for having
> flags in the PGP certificates that say what is supported by the
> receiving application(s).

Sorry, I don't understand this.  We do have these preferences since
the very beginning.

Salam-Shalom,

   Werner

---

From: Ben Laurie <[email-masked]>
Date: Mon, 21 Feb 2005 12:18:10 +0000

> Sorry, I don't understand this.  We do have these preferences since

Sorry, not very well today, and it seems not thinking straight. So why 
is there an issue with compatibility?

BTW, I see that 5.2.3.7. says "It is assumed that only algorithms listed 
are supported by the recipient's software" but this language is not 
carried forward into 5.2.3.8/9. In fact 5.2.3.9 explicitly rules out 
indicating what exactly is supported ("...the key holder's software 
might have no compression software").

Cheers,

Ben.

---

From: Werner Koch <[email-masked]>
Date: Mon, 21 Feb 2005 15:09:59 +0100

> is there an issue with compatibility?

This happens as soon as you switch your software without updating all
copies of your public key.  In particular downgrading the software is
troublesome but also upgrading sometimes (e.g. Tiger/192 has been
removed).  You might also have two different applications using the
same keypair.

For the average user the preferences work.

Shalom-Salam,

   Werner