Subject: Signed + Encrypted messages

From: "Hasnain Mujtaba" <[email-masked]>
Date: Thu, 26 Aug 2004 20:08:18 -0400

Hi all,

Would it be a safe assumption that the signed component of signed +
encrypted messages will always be one-pass signatures rather than
regular signatures? Incidently, this seems to be the default case with
GPG and PGP. 

Thanks
Hasnain.

---

From: Lutz Donnerhacke <[email-masked]>
Date: Fri, 27 Aug 2004 07:37:25 +0000 (UTC)

* Hasnain Mujtaba wrote:
> regular signatures?

No.

> Incidently, this seems to be the default case with GPG and PGP.

Yes.

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: Signed + Encrypted messages
Date: Fri, 27 Aug 2004 07:37:25 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Fri, 27 Aug 2004 07:37:25 +0000 (UTC)
Sender: [email-masked]

* Hasnain Mujtaba wrote:
> regular signatures?

No.

> Incidently, this seems to be the default case with GPG and PGP.

Yes.

content-class: urn:content-classes:message
Subject: Signed + Encrypted messages
Date: Thu, 26 Aug 2004 20:08:18 -0400
From: "Hasnain Mujtaba" <[email-masked]>
To: "[email-masked]" <[email-masked]'>
Sender: [email-masked]

Hi all,

Thanks
Hasnain.

From: "Carl Ellison" <[email-masked]>
To: "'Lutz Donnerhacke'" <[email-masked]>, <[email-masked]>
Subject: SHA-1 (was RE: MD5 warning)
Date: Sat, 21 Aug 2004 22:33:39 -0700
Sender: [email-masked]

Rumors aside, there is no published break of SHA-1.  Even SHA-0 isn't fully
broken.  People will continue to work on SHA-1 so it might break one of
these years, but I will still recommend using it.

 - Carl 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Lutz Donnerhacke
> Sent: Saturday, August 21, 2004 3:14 PM
> To: [email-masked]
> Subject: Re: MD5 warning
> 
> 
> * David Shaw wrote:
> > On Sat, Aug 21, 2004 at 09:23:13PM +0000, Lutz Donnerhacke wrote:
> >> Not necessary. All known attacks does not impose a direct 
> risk to md5 based
> >> OpenPGP issues.
> >
> > True, but would you recommend using MD5 these days?
> 
> No. I won't recommend any hash solely based on bit-logic and modular
> arithmetic these days.
> 
> > The time to deprecate it is before it is completely broken, and the
> > attacks do pose a direct risk.
> 
> OpenPGP recommends SHA1. I'm feeling bad with this, but this 
> is not the
> subject of discussion.
> 
> > MD5 showed some signs of weakness a few years ago.  A few 
> days ago, it
> > showed some pretty serious problems.  Let's let it go now 
> while it is
> > relatively easy to do so.
> 
> MD5 shares some weaknesses with other hash algorithms. Don't 
> blame MD5 alone.
> 
> > In section 9.4, add a note indicating that hash algorithm 1 is MD5,
> > but MD5 is deprecated, and SHOULD NOT be used.
> 
> So please add "SHA1 MAY NOT be used."
> 

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: MD5 warning
Date: Sat, 21 Aug 2004 22:13:33 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 26
NNTP-Posting-Host: belenus.iks-jena.de
NNTP-Posting-Date: Sat, 21 Aug 2004 22:13:33 +0000 (UTC)
Sender: [email-masked]

* David Shaw wrote:
> On Sat, Aug 21, 2004 at 09:23:13PM +0000, Lutz Donnerhacke wrote:
>> Not necessary. All known attacks does not impose a direct risk to md5 based
>> OpenPGP issues.
>
> True, but would you recommend using MD5 these days?

No. I won't recommend any hash soley based on bit-logic and modular
arithmentic these days.

> The time to deprecate it is before it is completely broken, and the
> attacks do pose a direct risk.

OpenPGP recommends SHA1. I'm feeling bad with this, but this is not the
subject of discussion.

> MD5 showed some signs of weakness a few years ago.  A few days ago, it
> showed some pretty serious problems.  Let's let it go now while it is
> relatively easy to do so.

MD5 shares some weeknesses with other hash algoithms. Don't blame MD5 alone.

> In section 9.4, add a note indicating that hash algorithm 1 is MD5,
> but MD5 is deprecated, and SHOULD NOT be used.

So please add "SHA1 MAY NOT be used."

Date: Sat, 21 Aug 2004 17:54:43 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: MD5 warning
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sat, Aug 21, 2004 at 09:23:13PM +0000, Lutz Donnerhacke wrote:
> 
> * David Shaw wrote:
> > That said, the security considerations section of the draft currently
> > has some language mildly discouraging the use of MD5 ("The MD5 hash
> > algorithm has been found to have weaknesses (pseudo-collisions in the
> > compress function) that make some people deprecate its use.  They
> > consider the SHA-1 algorithm better.")  Can we make this stronger, and
> > deprecate MD5 use for OpenPGP in general?
> 
> Not necessary. All known attacks does not impose a direct risk to md5 based
> OpenPGP issues.

True, but would you recommend using MD5 these days?  The time to
deprecate it is before it is completely broken, and the attacks do
pose a direct risk.

MD5 showed some signs of weakness a few years ago.  A few days ago, it
showed some pretty serious problems.  Let's let it go now while it is
relatively easy to do so.

To put my suggestion into a specific proposal for the draft:

In section 9.4, add a note indicating that hash algorithm 1 is MD5,
but MD5 is deprecated, and SHOULD NOT be used.

In section 13, rephrase the current mild note about MD5 to be stronger
and cite the paper giving the MD5 collisions.

David

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: MD5 warning
Date: Sat, 21 Aug 2004 21:23:13 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 10
NNTP-Posting-Host: belenus.iks-jena.de
NNTP-Posting-Date: Sat, 21 Aug 2004 21:23:13 +0000 (UTC)
Sender: [email-masked]

* David Shaw wrote:
> That said, the security considerations section of the draft currently
> has some language mildly discouraging the use of MD5 ("The MD5 hash
> algorithm has been found to have weaknesses (pseudo-collisions in the
> compress function) that make some people deprecate its use.  They
> consider the SHA-1 algorithm better.")  Can we make this stronger, and
> deprecate MD5 use for OpenPGP in general?

Not necessary. All known attacks does not impose a direct risk to md5 based
OpenPGP issues.

Date: Fri, 20 Aug 2004 11:35:49 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: MD5 warning
Mail-Followup-To: [email-masked]
Sender: [email-masked]

With regards to reinstating TIGER, I agree that there is little need
to do anything in crisis mode.  Let's give the various discussions
about MD5 and general hash health time to reach some sort of
conclusion.  We already have quite a number of hashes other than MD5,
and in V4, SHA-1 is the standard hash anyway.  Despite various rumors
to the contrary, SHA-1 was not broken.

That said, the security considerations section of the draft currently
has some language mildly discouraging the use of MD5 ("The MD5 hash
algorithm has been found to have weaknesses (pseudo-collisions in the
compress function) that make some people deprecate its use.  They
consider the SHA-1 algorithm better.")  Can we make this stronger, and
deprecate MD5 use for OpenPGP in general?

David

Date: Thu, 19 Aug 2004 00:20:24 +0100
From: Ian Grigg <[email-masked]>
To: Len Sassaman <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: re-consideration of TIGER
Sender: [email-masked]

Len Sassaman wrote:
> On a different note, I'm also in favor of dropping backwards compatibility
> with v3 in the spec, as I've mentioned before. This would also allow us to
> easily drop MD5 from v4. I think any backwards compatibility is adequately
> handled in the client implementations, and does not belong as a part of
> the OpenPGP message format. (I.e., there are clients that offer S/MIME
> compatibility, yet there's no reason for that to be part of this spec,
> either. We already have RFC 1991.)

I'm in total agreement there.

With one caveat - the chair would have to ponder whether
"this late" in the spec there are major changes allowed.

Some mentioned that v3 may be compromised even more by
this recent message digest news, and if so, that would be
sufficient casus belli, IMHO, to seriously consider doing
such a major step.

iang

PS: I note the comment on DSA/DSS keys ... if the above
logic doesn't fly, I'd suspect there is no case to drop
those keys, but I'm listening :-)

Date: Wed, 18 Aug 2004 13:49:51 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: re-consideration of TIGER
Sender: [email-masked]

On Wed, 18 Aug 2004 [email-masked] wrote:

> now that sha-0 has been broken,

SHA-0 was (theoretically) broken in 1998. The recent work is simply an
improvement in the break.

> and sha-1 is actively being looked at for a possible extension of the
> attack,
>
> and MD5, HAVAL, and RIPEMD are also being attacked
> http://eprint.iacr.org/2004/199.pdf)

Actually, all three are broken. But MD5 was (theoretically) broken in
1996, and RIPEMD has been considered weak for years. (Note, RIPEMD is
based on MD4.  It is *not* the same as RIPEMD-160 (based on RIPEMD, but
with considerable input from Dobbertin, who broke MD4 and MD5, or
RIPEMD-128 (based on RIPEMD-160, intended as a "drop in" replacement for
RIPEMD or MD4/5.)

> would it be reasonable to re-accept the non-sha based hashes, (e.g. TIGER)
> as a potential backup hash for implementations/users that may wish to
> begin doing so?

SHA-256 and SHA-512 are not based on the MDx family, and have arguably
gotten more scrutiny than TIGER. Even if SHA-1 or RIPEMD-160 were
threatened, we already have alternatives.

The bigger problem I see is with the lack of a sound hash function
firewall in OpenPGP v4 DSA keys. We can add all the strong hash functions
we want, but as long as there exists a weak hash function in the spec, an
attacker can theoretically cause a collision in the weak hash function to
match the strong hash function's results, and break the signature scheme.

We either need to fix this, drop DSA keys, require that all DSA keys
actually be DSS (and then deal with the consequences if SHA-1 is broken),
or standardize on a single hash (and have a backup hash ready if need be.)

Thinking about this more now, I suppose dropping DSA would be the
simplest, though that would cause a lot of compatibility issues.

On a different note, I'm also in favor of dropping backwards compatibility
with v3 in the spec, as I've mentioned before. This would also allow us to
easily drop MD5 from v4. I think any backwards compatibility is adequately
handled in the client implementations, and does not belong as a part of
the OpenPGP message format. (I.e., there are clients that offer S/MIME
compatibility, yet there's no reason for that to be part of this spec,
either. We already have RFC 1991.)

--Len.

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: re-consideration of TIGER
Date: Wed, 18 Aug 2004 19:20:07 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 13
NNTP-Posting-Host: belenus.iks-jena.de
NNTP-Posting-Date: Wed, 18 Aug 2004 19:20:07 +0000 (UTC)
Sender: [email-masked]

* Florian Weimer wrote:
> * Lutz Donnerhacke:
>> Currently the attack looks like exploiting insufficient highest bit
>> handling of the internal state variables. This is a matter if the
>> protocol applies a random(!) padding directly before hashing.
>
> Source?

Personal impression.

> (The impact on V3 keys could be interesting, though.)

Of course.

To: Lutz Donnerhacke <[email-masked]>
Cc: [email-masked]
Subject: Re: re-consideration of TIGER
From: Florian Weimer <[email-masked]>
Date: Wed, 18 Aug 2004 18:53:56 +0200
Sender: [email-masked]

* Lutz Donnerhacke:

> Unless the attack is not substantiated, wild actionism should be avoided.

Agreed.

> Currently the attack looks like exploiting insufficient highest bit
> handling of the internal state variables. This is a matter if the
> protocol applies a random(!) padding directly before hashing.

Source?

Based on my extrapolation of the pseudo-paper, it also depends where
the padding is added, if some length information is protected by the
hash, and the overall purpose of the hash function.  While MD5 has
certainly been broken, this doesn't seem to lead to immediate attacks
on real protocols.

(The impact on V3 keys could be interesting, though.)

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: re-consideration of TIGER
Date: Wed, 18 Aug 2004 09:36:40 -0700
To: <[email-masked]>
Sender: [email-masked]

On 18 Aug 2004, at 6:54 AM, <[email-masked]> wrote:

> would it be reasonable to re-accept the non-sha based hashes, (e.g. 
> TIGER)
> as a potential backup hash for implementations/users that may wish to
> begin doing so?
>

Not really, no. There are already perfectly good backup algorithms.

The reason we removed Tiger is that it hasn't been examined or used at 
all. None of these things apply to Tiger, and it is therefore still not 
well examined nor used. Going from a hash function that has been 
examined to one that hasn't isn't presently warranted.

SHA-1 isn't broken yet. Even the ones that have been broken haven't 
been broken (yet) in ways that permit signature forging. What we know 
now is that the functions we've been saying for close to a decade 
shouldn't be used really shouldn't be used.

If you're worried about SHA-1, you should move to SHA-256. Don't be 
scared by the fact that it's called "SHA."

If you want to do something *really* practical and good, stop using 
your V3 keys. (That's the editorial you, not vedaal specifically.)

I'm sitting in the hash sessions at Crypto now, and SHA-1 isn't broken. 
Again, if you still want to do something, start using SHA-256.

	Jon

From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: re-consideration of TIGER
Date: Wed, 18 Aug 2004 19:21:05 +0300
Sender: [email-masked]

This is a multi-part message in MIME format.

------=____1092846065832_Zmv+Fc?)QY
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Greetings,
the recent breakthrough appears to apply to all
the MDx based hash algorithms.
while TIGER is not, i am told, it does not mean that
it is more secure, as it has not been subject to same
scrutiny as the MDx based hashes.
i believe that less is better, however, diversity
is a good thing, especially when the algorithms
are un-related.  After all, this is the reason
why there are numerous algorithms in a crypto suite.
i am no expert of course, but it would be a cautious
thing to trim down the algorithms of similar ones
for the sake to complexity, and augment them with
dissimilar ones for the sake of hedging one's bet.
given the above a case for re-instating TIGER in openpgp
could be made.
hth
best regards
Imad R. Faiad

> 
> From: <[email-masked]>
> Date: 2004/08/18 Wed PM 04:54:42 EAT
> To: [email-masked]
> Subject: re-consideration of TIGER
> 
> 
>now that sha-0 has been broken,
>and sha-1 is actively being looked at for a possible >extension of the
>attack,
>
>and MD5, HAVAL, and RIPEMD are also being attacked
>http://eprint.iacr.org/2004/199.pdf)
>
>
>would it be reasonable to re-accept the non-sha based >hashes, (e.g. TIGER)
>as a potential backup hash for implementations/users >that may wish to
>begin doing so?
>
>
>vedaal

------=____1092846065832_Zmv+Fc?)QY
Content-Transfer-Encoding: base64
Content-Type: null;
	name="replyAll"
Content-Disposition: inline;
	filename="replyAll"

------=____1092846065832_Zmv+Fc?)QY--

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups:  iks.lists.ietf-open-pgp
Subject:  Re: re-consideration of TIGER
Date: Wed, 18 Aug 2004 14:41:56 +0000 (UTC)
Organization:  IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: taranis.iks-jena.de
NNTP-Posting-Date: Wed, 18 Aug 2004 14:41:56 +0000 (UTC)
Sender: [email-masked]

* <[email-masked]> wrote:
> would it be reasonable to re-accept the non-sha based hashes, (e.g. TIGER)
> as a potential backup hash for implementations/users that may wish to
> begin doing so?

Unless the attack is not substantiated, wild actionism should be avoided.
Currently the attack looks like exploiting insufficient highest bit handling
of the internal state variables. This is a matter if the protocol applies a
random(!) padding directly before hashing.

Date: Wed, 18 Aug 2004 06:54:42 -0700
To: [email-masked]
Cc: 
Subject: re-consideration of TIGER
From: <[email-masked]>
Sender: [email-masked]

now that sha-0 has been broken,
and sha-1 is actively being looked at for a possible extension of the
attack,

and MD5, HAVAL, and RIPEMD are also being attacked
http://eprint.iacr.org/2004/199.pdf)

would it be reasonable to re-accept the non-sha based hashes, (e.g. TIGER)
as a potential backup hash for implementations/users that may wish to
begin doing so?

vedaal

Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

Date: Thu, 5 Aug 2004 14:20:27 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Partial chunking question
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Thu, Aug 05, 2004 at 01:53:40PM -0400, Hasnain Mujtaba wrote:

> I had a question on breaking data into partial chunks. If someone can
> clarify this, I'd appreciate it:
> 
> Suppose the chunk size you are using is 8192 bytes and the final data
> chunk is less than 8192, say it is 6480. My chunking implementation puts
> these final 6480 bytes into one non-partial length chunk so that the
> chunk sequence looks like this: 8192, 8192, ... , 8192, 6480.
> 
> GPG and PGP, however, break this final data into power of two lengths,
> i.e 8192, 8192, ... , 8192, 4096, 2048, 336. 
> 
> My approach interoperates with both GPG and PGP. But I am curious as to
> why GPG and PGP break the final data this way, rather than putting it
> all in one final non-partial chunk. I hope I have not overlooked some
> RFC requirements.

It's not an RFC requirement.  When writing a stream, GnuPG picks the
largest possible power of 2 for the amount of data it is ready to
write at that point.  I suspect PGP does something similar for similar
reasons.

What you are doing is also perfectly legal.

David

content-class: urn:content-classes:message
Subject: Partial chunking question
Date: Thu, 5 Aug 2004 13:53:40 -0400
From: "Hasnain Mujtaba" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi all,

I had a question on breaking data into partial chunks. If someone can
clarify this, I'd appreciate it:

Suppose the chunk size you are using is 8192 bytes and the final data
chunk is less than 8192, say it is 6480. My chunking implementation puts
these final 6480 bytes into one non-partial length chunk so that the
chunk sequence looks like this: 8192, 8192, ... , 8192, 6480.

GPG and PGP, however, break this final data into power of two lengths,
i.e 8192, 8192, ... , 8192, 4096, 2048, 336. 

My approach interoperates with both GPG and PGP. But I am curious as to
why GPG and PGP break the final data this way, rather than putting it
all in one final non-partial chunk. I hope I have not overlooked some
RFC requirements.

Regards,
Hasnain

----
The information contained in this electronic mail and any attached
document is the confidential and proprietary business information of
Forum Systems, Inc. It is intended solely for the addressed recipient
listed above. It may not be distributed in any manner without the
express written consent of Forum Systems, Inc.