Subject: [Hash] BOF Goals

From: Jon Callas <[email-masked]>
Date: Tue, 12 Jul 2005 19:37:00 -0700

In my involvement with IETF groups, one thing that has always struck me  
as a good thing is its decisions to stick to well-defined, practical  
matters. Furthermore, these have been more in layout than anything  
else. We don't like APIs, we like message transactions. Even when we  
venture into advice, it's always actionable, meaning that there are  
specific things that a practitioner can do. These preferences are  
positively cliché, none of us needs to read the words "rough consensus  
and working code" -- we've already been humming that tune in our heads.

It's therefore a bit unusual for me to ask one of my own cliché  
questions: What problem are we trying to solve? and have that be both  
genuine and backed with my own puzzlement. I don't know what we are  
doing, expect, plan, or even hope.

Yes, cryptographic engineering is in the uncomfortable situation  
presently that we're staring at embarrassing surprises with our present  
suite of hash functions. But the present-day workarounds are clear; we  
have hash functions that are good enough for the short and medium-term  
future. We also know that some uses of the present hash functions work  
just fine, thank you. (HMAC-MD5 springs to mind.)

As it has been stated, there are two problems we're looking at:

(1) truncating existing wide hashes for use in systems like DSA.

(2) to explore "randomized" hashes.

The first one is pretty easy to deal with, in the general case. We  
already addressed this in OpenPGP.

FIPS-180, which describes all of the SHA-family hashes [1] answers this  
question on page 73:

     "Some applications may require a hash function with an output size
     (i.e., message digest size) different than those provided by the
     hash functions in this Standard. In such cases, a truncated hash
     output may be used, whereby a hash function with a larger output
     size is applied to the data to be hashed, and the resulting output
     (i.e., message digest) is truncated by selecting an appropriate
     number of the leftmost bits. For example, if an output of 96 bits is
     desired, the SHA256 hash function could be used (e.g., because it is
     available to the application), and the leftmost 96 bits of the
     output are selected as the message digest, discarding the rightmost
     160 bits of the SHA-256 output."

Now, I should add that we decided not to do this in PGP's products, nor  
in OpenPGP. At PGP Corporation, we coded such a truncation into our DSA  
implementation for early releases of PGP 9. However, when I mentioned  
this a senior NIST person, I was asked not to. We accidentally let the  
truncated-SHA-256 version of DSA escape in one beta test, but we don't  
have it in there.

The reason we decided to stick with DSA as-is is that DSA does not  
include hash information in the signature itself. Consequently, there's  
a chance of cross-hash collisions in addition to the normal chance of  
hash collisions. I think that the risk of this is low when the hash  
functions are strong, and higher if the hash functions are weak. Thus,  
truncating SHA-256 conceivably makes the overall system *less* secure  
by opening up the possibility of cross-hash collisions.

NIST is supposed to release an addendum to DSA for wide hashes and keys  
bigger than 1024 bits. The *correct* thing for us to do is wait for  
that. That they haven't done so yet is disappointing. I was asking for  
it pretty-please with sugar on top in August '04 at Crypto, and we're  
still waiting. But -- they have their reasons, whatever they are. If  
someone finds the wait unacceptable, then there's an obvious workaround  
-- use RSA with SHA-256.

I don't think we need to do anything with the truncation issue. The  
answer of how to truncate the wide SHAs is answered for us in FIPS 180.  
The answer of what to do with DSA is "Don't." We can wait for NIST. If  
we don't we're going to have to do what they say, anyway. Why make more  
work?

The second issue, using salted hashes (I prefer this to "randomized"),  
is more interesting technologically, but there are still a number of  
extremely important issues open about them.

The first open issue is their expected security when compared both to  
the unsalted version and comparable other functions. For example, we  
know that SHA-1 should have 80 bits of security and doesn't. Will as  
salted SHA-1 have 80 bits of security? What makes us think so? SHA-256  
should have 128 bits of security, and many of us (I know I am one)  
expect it to have flaws. However, do we expect it to have less than 80  
bits of security? I don't.

It is a fair criticism of our history of designing hash functions that  
we've tweaked them rather than redesign them. But salting the hash is  
also a tweak. If SHA-256 is so broken that alone it has less security  
than 80 bits, what could possibly make us think that a tweak like  
salting will actually increase security? I wrote a long note to the  
CFRG list on this theme, which I will be happy to repost here. I  
believe that whatever flaws SHA-256 might have, it has enough security  
to last us for five to fifteen years at 80 to 100 bits of security. My  
rationale for my opinion is in that CFRG email.

The second issue is the performance of the salted hash functions. In  
discussions in the CFRG list, Dan Bernstein has suggested that salted  
MD5 has similar performance to unsalted SHA-256. If this is so, then  
whyever would you use salted MD5? Surely no one suggests that SHA-256  
has fewer than 64 bits of security, do they? If salted MD5 and SHA-256  
are similar in performance, then the *only* reason to consider using  
salted MD5 is that whatever protocol you're using can support a 128-bit  
hash, but not a 256-bit hash. And even in that case, the *real*  
question we should be asking is whether truncated SHA-256 has 64 bits  
of security!

It seems to me that if there are questions that a hashing working group  
should be asking, they are not the ones we're asking, but other ones  
that include:

* What is the security of a salted hash function? Does salted MD5 have  
64 bits of security? Does salted SHA-1 have 80 bits of security? Does  
salted SHA-256 have 128 bits of security? Why do we think this? I've  
seen no reasoning nor metrics.

* What is the security of a truncated hash function? Examples: Suppose  
SHA-256 has 110 bits of security (if it is as broken as SHA-1, this is  
my predicted security value). If you truncate SHA-256 to 128 bits, does  
that mean that it has 55 bits of security? Or does it mean that it has  
64 bits of security? Or something in the middle? Why do we think this?  
What do we expect its security to be if you truncate it to 160 bits and  
why?

* What is the performance of a salted hash function? Bernstein's claim  
that salted MD5 has similar performance to SHA-256 has gone  
unchallenged, and he himself has noted this silence.

* Are there other constructions we can perform that give us security  
over the naked hash function, but require less work than salting? For  
example, suppose we took SHA-256 and folded its halves, XORing them  
together. Does this give us more security than straight truncation? If  
not, why not (since it seems intuitive that folding would have at least  
an eensy bit more security)? What other constructions could we make  
that improve over raw truncation without the cost of salting?

Without answers to these questions, I don't see how this working group  
can give any meaningful results. Worse, I don't see how any  
recommendation of this group can improve over the simple advice of "use  
SHA-256." If this BOF results in a working group, I believe it *must*  
address the questions I outlined above, as well as the issues I and  
Bernstein have brought up in CFRG.

If salted hashes are slower than wider hashes and the wider hash has  
enough security (enough being greater than 64 bits for an MD5  
replacement and greater than 80 bits for a SHA-1 replacement), then we  
should just use the wider hash and be done with it -- except when  
that's not reasonable.

It is only when the actual size of the hash function is an issue and  
you can't just switch to RSA that the simple advice isn't worth taking.  
I can think of one such instance, and it's a draft that I work on --  
syslog-sign. In syslog-sign, space is at a premium, and it uses DSA for  
this reason. (A DSA signature is twice the size of the hash function  
rather than proportional to the size of the key, and syslog packets are  
teenie.) Furthermore, the way that syslog-sign is used, it is far  
better to have a 160-bit hash with 80 bits of security than it is to  
have anything else; space is at that much of a premium. In *this* case,  
I'd be happy to seemingly contradict my previous grouchiness and say,  
"Aw, just truncate SHA-256 to 160 bits and use that in DSA." There may  
be other cases where the use model of the protocol might warrant that.

But in the vast majority of cases, the simple advice:

(1) If you're using DSA, grin and bear it until NIST comes out with  
wide DSA
(2) If you're using RSA, switch to using SHA-256
(3) If you're using DSA and don't like (1), switch to (2)

is perfectly fine advice.

	Jon

[1]  
<http://csrc.nist.gov/publications/fips/fips180-2/fips180 
-2withchangenotice.pdf>

-- 
Jon Callas
CTO, CSO
PGP Corporation         Tel: +1 (650) 319-9016
3460 West Bayshore      Fax: +1 (650) 319-9001
Palo Alto, CA 94303     PGP: ed15 5bdf cd41 adfc 00f3
USA                          28b6 52bf 5a46 bc98 e63d

-- 
Jon Callas
CTO, CSO
PGP Corporation         Tel: +1 (650) 319-9016
3460 West Bayshore      Fax: +1 (650) 319-9001
Palo Alto, CA 94303     PGP: ed15 5bdf cd41 adfc 00f3
USA                          28b6 52bf 5a46 bc98 e63d

________________________________________________________________
This message could have been secured by PGP Universal. To secure
future messages from this sender, please click this link:

https://keys.pgp.com/b/b.e?r=hash%40ietf.org&n=I6LW%2FTFegliptjmtozrp%2Bg%3D%3D

_______________________________________________
Hash mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hash

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Jul 2005 12:19:49 -0700

This guidance is provided for unforeseen applications in order to 
provide interoperability. A standard method for truncating hash 
function outputs is provided strictly as a convenience for 
implementers and application developers. No claims are made about the 
suitability of truncating the hash output or about the security level 
obtained by truncating the hash output. The proper use of truncated 
hash outputs is an application-level issue.

Truncating the hash function output can impact the security of an 
application. For example, applications that use the truncated hash 
output risk attacks based on confusion between different parties 
about the specific amount of truncation used, and the specific hash 
function whose output was truncated.  Any application using truncated 
hash output is responsible for ensuring that the truncation amount 
and the hash function used are known to all parties, with no chance 
of ambiguity.

Truncated hash output shall not be used in place of the full hash 
output by standardized applications that reference this Standard, 
e.g. digital signatures (FIPS 186-2) or keyed hash functions used for 
message authentication (FIPS 198).

At 7:37 PM -0700 7/12/05, Jon Callas wrote:
>questions: What problem are we trying to solve? and have that be 
>both genuine and backed with my own puzzlement. I don't know what we 
>are doing, expect, plan, or even hope.

This is not a Working Group to produce a protocol. As the proposed 
charter says, "The proposed working group responds to the current 
state of research in this area.  However, additional research is 
likely to provide new insights as the working group progresses." In 
other words, our job is to help in an area that people didn't feel 
the need for help before, namely the use of hashes in protocols.

>(2) to explore "randomized" hashes.

Those are only the first two. There is a third problem we may be 
looking at in the longer term: "The optional second phase will 
identify one or more standards-track one-way hash functions that 
fulfill the requirements stated in the BCP documents developed in the 
first phase.  Guidance will also be developed
to assist protocol developers in the selection among the 
standards-track one-way hash functions."

>FIPS-180, which describes all of the SHA-family hashes [1] answers 
>this question on page 73:
>

>NIST is supposed to release an addendum to DSA for wide hashes and 
>keys bigger than 1024 bits.

I see nothing on the NIST site that says that they will release this 
addendum, nor have I heard it from the NIST folks I have spoken with. 
That is not to say that they aren't working on it, just that we 
shouldn't assume that the addendum is a fact.

>The *correct* thing for us to do is wait for that.

Some folks at NIST have told us (quite informally) that us working on 
the truncation issue would be a good thing. Certainly, if it turns 
out that simple truncation can be shown to be as safe as any other 
shortening method, that would help DSA because it would make the 
algorithm much simpler. This is why I asked in the previous message 
for input on research in this area.

>If someone finds the wait unacceptable, then there's an obvious 
>workaround -- use RSA with SHA-256.

This is simplistic on a couple of levels.

- There are many properties where DSA and RSA differ, and a protocol 
developer may have chose DSA for one of those.

- The assumption of SHA-256 seems rash. In particular, we don't yet 
have information preimage attacks on SHA-1, we haven't specified 
which kinds of uses of hashes with digital signatures are affected by 
the reduction in collision strength, and we haven't looked at whether 
other formulations of hashes might appear to more immune to attacks 
related to the ones we know now.

- Changing protocols is very difficult for typical users. They may be 
using a protocol in which there is no identifier for "RSA with 
SHA-256". They may be using the algorithm for long-lived signatures, 
where switching means using multiple protocols with different 
properties. Having some users change while others don't can cause 
long-term problems for both groups: that's why the IETF tries to be 
clear which algorithms to use, and when.

>The answer of how to truncate the wide SHAs is answered for us in FIPS 180.

If you only read the paragraph you quoted, yes. The rest of that 
section from FIPS 180 says:

>This guidance is provided for unforeseen applications in order to 
>provide interoperability. A standard method for truncating hash 
>function outputs is provided strictly as a convenience for 
>implementers and application developers. No claims are made about 
>the suitability of truncating the hash output or about the security 
>level obtained by truncating the hash output. The proper use of 
>truncated hash outputs is an application-level issue.
>
>Truncating the hash function output can impact the security of an 
>application. For example, applications that use the truncated hash 
>output risk attacks based on confusion between different parties 
>about the specific amount of truncation used, and the specific hash 
>function whose output was truncated.  Any application using 
>truncated hash output is responsible for ensuring that the 
>truncation amount and the hash function used are known to all 
>parties, with no chance of ambiguity.
>
>Truncated hash output shall not be used in place of the full hash 
>output by standardized applications that reference this Standard, 
>e.g. digital signatures (FIPS 186-2) or keyed hash functions used 
>for message authentication (FIPS 198).

Not wearing my BOF chair hat: the little that is said in FIPS 180 is 
not sufficient to decide that we know enough about the issue to 
decide anything. The cryptographic community is certainly able to 
deal with this issue better than the first paragraph of the section 
in FIPS 180.

>The answer of what to do with DSA is "Don't." We can wait for NIST. 
>If we don't we're going to have to do what they say, anyway. Why 
>make more work?

Because the "more work" may be valuable research, even for NIST.

To be clear: I'm not saying we should have truncation in our WG 
charter, and Jon is the first so far to speak up to say we shouldn't. 
Hearing from others on the mailing list would be useful.

>The second issue, using salted hashes (I prefer this to 
>"randomized"), is more interesting technologically, but there are 
>still a number of extremely important issues open about them.

Exactly!

>The first open issue is their expected security when compared both 
>to the unsalted version and comparable other functions. For example, 
>we know that SHA-1 should have 80 bits of security and doesn't. Will 
>as salted SHA-1 have 80 bits of security? What makes us think so? 
>SHA-256 should have 128 bits of security, and many of us (I know I 
>am one) expect it to have flaws. However, do we expect it to have 
>less than 80 bits of security? I don't.

This paragraph again assumes a move to SHA-256. It might be better to 
deal with the tradeoffs, as is done in the one Internet Draft we 
have, 
<http://www.ietf.org/internet-drafts/draft-irtf-cfrg-rhash-00.txt>.

>In discussions in the CFRG list, Dan Bernstein has suggested that 
>salted MD5 has similar performance to unsalted SHA-256.

Seeing actual numbers on this would be a great boon to the discussion.

>It seems to me that if there are questions that a hashing working 
>group should be asking, they are not the ones we're asking, but 
>other ones that include:
>
>* What is the security of a salted hash function? Does salted MD5 
>have 64 bits of security? Does salted SHA-1 have 80 bits of 
>security? Does salted SHA-256 have 128 bits of security? Why do we 
>think this? I've seen no reasoning nor metrics.

Good questions, and ones we should answer.

>* What is the security of a truncated hash function? Examples: 
>Suppose SHA-256 has 110 bits of security (if it is as broken as 
>SHA-1, this is my predicted security value). If you truncate SHA-256 
>to 128 bits, does that mean that it has 55 bits of security? Or does 
>it mean that it has 64 bits of security? Or something in the middle? 
>Why do we think this? What do we expect its security to be if you 
>truncate it to 160 bits and why?

Good questions, and ones we should answer. So, now you want to keep 
the item in the WG charter? :-)

>* What is the performance of a salted hash function? Bernstein's 
>claim that salted MD5 has similar performance to SHA-256 has gone 

These should not be difficult values to start generating.

>over the naked hash function, but require less work than salting? 
>For example, suppose we took SHA-256 and folded its halves, XORing 
>them together. Does this give us more security than straight 
>truncation? If not, why not (since it seems intuitive that folding 
>would have at least an eensy bit more security)? What other 
>constructions could we make that improve over raw truncation without 
>the cost of salting?

Good questions, and ones we should answer.

>Without answers to these questions, I don't see how this working 
>group can give any meaningful results. Worse, I don't see how any 
>recommendation of this group can improve over the simple advice of 
>"use SHA-256." If this BOF results in a working group, I believe it 
>*must* address the questions I outlined above, as well as the issues 
>I and Bernstein have brought up in CFRG.

A specific list of issues on *this* list, not on CFRG, would help us 
finalize the charter.

>replacement and greater than 80 bits for a SHA-1 replacement), then 
>we should just use the wider hash and be done with it -- except when 
>that's not reasonable.

Having a description of when it is reasonable also seems to be 
valuable to be written down.

--Paul Hoffman, Director
--VPN Consortium

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Jul 2005 12:45:30 -0000

Another 160-bit possibility to consider is RIPEMD-160. RIPEMD-160 has
been around since 1996 and is faster than 160-bit-truncated SHA-256.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 15 Jul 2005 07:16:13 -0700 (PDT)

> been around since 1996 and is faster than 160-bit-truncated SHA-256.

If people don't know (and in the future please provide references to
algorithms whenever possible), good page about RIPEMD160 is:
  http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html

Regarding being faster then SHA256, that maybe true but RIPEMD itself
is not as fast as SHA functions and there has not been enough study of
RIPEMD to make certain it does not have same potential collision problems.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Jon Callas <[email-masked]>
Date: Wed, 20 Jul 2005 15:16:21 -0700

Paul's asked me to discuss more, particularly so we can have more email 
discussions prior to Paris. He's also rightly pointed out that my CFRG 
discussion isn't here, and without good cross-referencing, I shouldn't 
assume people here have read it. So here's the note that I sent some 
time ago:

Begin forwarded message:

From: Jon Callas <[email-masked]>
Date: 13 June 2005 3:38:10 PM PDT
To: [email-masked]
Subject: Re: [Cfrg] new i-d: randomized hashing

On 13 Jun 2005, at 7:18 AM, Ben Laurie wrote:

> D. J. Bernstein wrote:
>> Ben Laurie writes:
>>> It seems to me that life would be generally easier if you defined a 
>>> modified hash function H_r(m) and then constructed H'(m)=(r,H_r(m)). 
>>> This way transport of r happens automatically, but the hash gets 
>>> wider.
>> Even better, use the extra space for a longer _deterministic_ hash. 
>> For
>> example, instead of using 96 bits for r and 160 bits for SHA-1 output,
>> simply use SHA-256.
>
> That assumes we're confident SHA-256 won't have similar flaws.
>

Ben brings up a good point, but I side with Dan Bernstein. I think 
SHA-256 is the right way to go, and we don't need anything else until 
we get new hash functions that have the attributes we want.

I am quite confident that SHA-256 has similar flaws to SHA-1 and all 
the others, but I think the right thing to do for the time being is to 
just use it. This is what we've done in PGP.

Here's my reasoning why:

SHA-1 is supposed to have 80 bits of security. Our present knowledge of 
it has it around 69. (I will handwave what this means, because yes, I 
know that this isn't pre-image collision, it doesn't apply to hmacs or 
similar constructions, etc.) It's thus missing 11 bits of security.

SHA-256 is supposed to have 128 bits of security. If we assume a 
similar flaw, SHA-256 should be missing about 17.6 bits of security. 
(That's (11/80) * 128.)

Let's take that 17.6 and round it up to 38. Yup, thirty-eight. Not 
twenty-eight, not eighteen. I have a cynical rounding function. That 
gives us 90 bits of security.

At 90 bits of security, I'm happy to live with SHA-256 for a while. I 
believe that the hash function we *want* to be using hasn't been 
written yet. (My guess is that it will be announced around the time of 
Asiacrypt '06, and papers published in FSE '07. We're not going to be 
comfortable with it until early '08, but will still whine and mutter 
about it until September '09. The FIPS for it won't appear -- sorry, 
I'm not going to make that cheap joke; NIST will actually make a FIPS 
before the whining stops.)

At 90 bits of security, we can live with it for another five years. And 
this assumes my rounding function, which scopes the "similar" flaw in 
SHA-256 to actually be a million times more devastating than the SHA-1 
one. If my rounding function should round 17.6 to 28 instead, then 
SHA-256 will last for another 15 years just fine. I think that factor 
of 1024 takes into account a additional decade of semiconductor 
improvements adequately. If my rounding function should round 17.6 to 
18, then SHA-256, while flawed, can live out its natural life. Normal 
engineering improvements can dispose of it sometime in the indefinite 
future -- probably around '09. (Oh, and if it were 80, then we could 
use it for all the same things we expect SHA-1 to do at the mere cost 
of being slow and big.)

We also know that there's no real mathematical insight that Wang and 
others have. It is true that attacks don't get worse, they only get 
better, but there's no reason to think that the attacks on any of the 
hash functions are going to get different in kind, merely in degree. I 
believe that SHA-256 has at least 100 bits of security in it. That's 
why my gedankenexperiment backs it down to 90.

Any number of people have observed that we have taken one basic 
construction for hash functions has been a bunch of tweaks, rather than 
a design change. Everything we have has at some level the same 
architecture. My concern about randomized hashing is that I see it as 
another tweak. Yes, it's a tweak in a higher level construct, but it's 
still a tweak. It's a tweak that requires more fundamental changes to 
the protocols and systems that *use* hash functions than merely 
swapping in a new function. That one is bad enough. I also see no 
reason why this is going to change our core mechanisms of operating. If 
we learn how to make a good hash function sometime between 2010 and 
2020, then that's within the pragmatic safety considerations of 
SHA-256. If something extraordinary happens, then gosh darnit, SHA-512 
should work. I can't believe that SHA-512 will have less than 128 bits 
of security. I'm sorry, I don't. If I'm proved wrong, then we really, 
really don't know what we're doing, and there are many dramatic things 
in information security we have to change.

So to sum up -- this is all interesting, to make randomized hashing, 
but why should I trust it, why should I convert to it? Why am I not 
jumping from the frying pan into another frying pan? Especially when my 
present plan is to use SHA-256, and if that is unacceptable, SHA-512. 
Does anyone believe that they're really that broken? Or to sum up my 
summary, in waiting for the right hash function, am I waiting for 
Godot?

	Jon

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Jon Callas <[email-masked]>
Date: Wed, 20 Jul 2005 16:26:36 -0700

> other words, our job is to help in an area that people didn't feel the 
> need for help before, namely the use of hashes in protocols.
>

Does it need a working group?

I thought the I-D you and Bruce did was smashing. I thought it 
describes the current state of affairs quite well, especially that the 
main thing we know is the depth of what we don't know.

Now, if what we'd do in this working group is to come up something that 
was like that only better, fair enough. Then I have misunderstood what 
this WG would accomplish, and apologize.

> standards-track one-way hash functions."

But that should be a separate thing that happens when there's something 
to say. Guidance is simple right now and will give us a five-page RFC. 
There are lots and lots of edge conditions that can't be simply 
addressed in a single document.

> shouldn't assume that the addendum is a fact.

At CRYPTO '04, I spoke to people and actually saw a proposed DSS 
update. Obviously, they haven't been happy with it. This is 
frustrating, but like it or not, they're the people who produce DSS, 
and when they come out with something, that's what to do.

If they don't come out with something before people really start 
switching, that would be sad, but that puts the urgency on them.

> the truncation issue would be a good thing. Certainly, if it turns out 
> that simple truncation can be shown to be as safe as any other 

(I hope I'm not repeating myself.) Last summer, at PGP, we coded up DSA 
with truncated SHA-256. When the new results came out in February, we 
put it into alphas of PGP 9. I told some NIST people, who gave me the 
most dreadful look, and we took it out. (Actually, we didn't fully take 
it out in Beta 1, and so there were a few DSA-SHA256 signatures that 
leaked out into the world.)

The reason we didn't was that we decided that truncating wasn't the 
right thing, and sticking to SHA-1 is all right for the time being.

> have information preimage attacks on SHA-1, we haven't specified which 
> kinds of uses of hashes with digital signatures are affected by the 
> reduction in collision strength, and we haven't looked at whether 

I worried about my last missive being far too long, and drastically 
truncated it before I sent it. I'll try to avoid that error again 
(which is part of why I risked repeating myself above, because even if 
I am, it's emphasis).

I'm the one responsible for the pithy comment about SHA-1 that it's 
time to walk, not run to the exit. I know that there are complications. 
Believe me.

I'm the author of both OpenPGP (which possibly has the widest use of 
DSA), and syslog-sign (which depends on DSA because it's really, really 
important to short signatures in a syslog packet).

In the OpenPGP case, it's cold comfort indeed to be told "make another 
key, then." I haven't. Heck, I got chewed out last weekend for our 
deprecating MD5. People get emotional about this.

In the syslog-sign case, we're in a bad spot. It's really, really 
important to have short signatures. Moving to SHA-256 is not 
convenient, and 40-byte sigs are important. This is a place were 
truncation or something else would be good. However -- I still say to 
stay the course on SHA-1. It's good enough for now. I repeat, for now.

Yes, this is not simple, and that's my point! If you want a simple 
answer, I gave one. That the simple answer is simplistic only 
underscores my questions about the WG's purpose and existence.

> section from FIPS 180 says:
[elided]

Thank you! This is precisely my point. This is part of why we decided 
to not use truncated SHA-256. FIPS 180 tells us *how* to do it. It does 
not tell us *when* to, *why* to, or other things. But that's not what I 
said. I said that if one of the goals of the WG is *how* to truncate 
the wide SHAs, FIPS 180 tells us.

> not sufficient to decide that we know enough about the issue to decide 
> anything. The cryptographic community is certainly able to deal with 
> this issue better than the first paragraph of the section in FIPS 180.
>
>> If we don't we're going to have to do what they say, anyway. Why make 
>> more work?
>

Then this should be in the IRTF, not the IETF.

>> still a number of extremely important issues open about them.

Thanks.

>> salted SHA-1 have 80 bits of security? What makes us think so? 
>> SHA-256 should have 128 bits of security, and many of us (I know I am 
>> one) expect it to have flaws. However, do we expect it to have less 
>> than 80 bits of security? I don't.
>
> deal with the tradeoffs, as is done in the one Internet Draft we have, 

I read it. As a protocol author, I find it amazingly unsatisfying.

If my worry, that this WG would take that draft, turn it into an RFC, 
and then start recommending, coercing, whatevering people to use it is 
an unfounded worry, then again, I apologize. I've been seeing things 
under the bed.

> Seeing actual numbers on this would be a great boon to the discussion.

My point, as well.

>> group should be asking, they are not the ones we're asking, but other 
>> ones that include:
>>
>> have 64 bits of security? Does salted SHA-1 have 80 bits of security? 
>> Does salted SHA-256 have 128 bits of security? Why do we think this? 
>> I've seen no reasoning nor metrics.
>

Again, I don't see that as what a working group does.

> the item in the WG charter? :-)

My objection is to the WG charter, not its contents. If, however, I 
cannot affect the decision of *whether* to have a charter and we are 
indeed having one, then yes, I want it in the charter.

>> together. Does this give us more security than straight truncation? 
>> If not, why not (since it seems intuitive that folding would have at 
>> least an eensy bit more security)? What other constructions could we 
>> make that improve over raw truncation without the cost of salting?
>

But that is at odds with one of the WG goals -- to explore salted 
hashing. I think it's far too early to do that.

My perception is that we're getting the verdict first -- 
randomized/salted hashing -- and collecting evidence later. If my 
perception is out of whack, please let me know.

> A specific list of issues on *this* list, not on CFRG, would help us 

Mea culpa. I forwarded my previous CFRG note here.

> valuable to be written down.

Assuming we have something to say that has a shelf life longer than 
bottled water, yes. I am not convinced we have that.

	Jon