Subject: [Hash] Hash BoF

From: Russ Housley <[email-masked]>
Date: Thu, 09 Jun 2005 15:28:58 -0400

There are now 41 members on this mail list.  That seems like enough to get 
the discussion going.

I have attached the proposed charter for the Hash WG.

I have asked Paul Hoffman to act as chair for the Hash BoF in Paris.  He 
has agreed.  So, now I will let Paul lead a discussion about this proposed 
charter.

Thanks,
   Russ Housley
   IETF Security Area Director

= = = = = = = = = =

One-way Hash Function BoF (hash)

Security Area Director:
      Sam Hartman <[email-masked]>
      Russ Housley <[email-masked]>

Security Area Advisor:
      Russ Housley <[email-masked]>

Mailing Lists:
      General Discussion: [email-masked]
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/hash
      Archive:            http://www.ietf.org/mail-archive/web/hash/index.html

Description of Proposed Working Group:

Recently, a team of researchers reported that the SHA-1 one-way hash
function offers significantly less collision resistance than could be
expected from a cryptographic hash function with an output of 160 bits.
This result has inspired significant research activities in government
and academia.  Additional information regarding the security of current
one-way hash functions, as well as proposals for new one-way hash
functions, are expected.  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.

A three-phase approach is envisioned.  The second and third phases will
be pursued only if it is clear that the international cryptographic
community is actively participating in the working group.

The first phase of the working group will specify one or more standards-
track mechanism replace or strengthen SHA-1.  At least two approaches
will be considered:

   1) Truncate a larger one-way hash function output so that it can be
      used as a secure replacement of a shorter one-way hash function
      output.  For example, as an alternative to SHA-1, the truncation
      mechanism could be used create a 160-bit result from the output of
      the SHA-256 one-way hash function.

   2) Including a random value in the hash function computation. The
      random block used is transferred as a parameter in the algorithm
      identifier.  This approach is sometimes called a "salted" or
      "randomized" hash function.

The first phase may also consider other potential solutions, and one or
more standards-track mechanism will be selected.

The second phase will consider the suitability of one-way hash
functions for use with IETF protocols.  These requirements will be
published as one or more BCP documents which specify the features
and characteristics for standards-track one-way hash functions.  The
BCP documents will also identify information that must be included in
any request for a hash function to be approved on the standards track.

The third phase will identify one or more standards-track one-way hash
functions that fulfill the requirements stated in the BCP documents
developed in phase two.  Guidance will also be developed to assist
protocol developers in the selection among the standards-track one-way
hash functions.

Goals and Milestones:

September 2005:  Charter to authorize phase one.
October 2005:    Submit initial draft of truncation mechanism.
February 2006:   WG Last Call on truncation mechanism.
April 2006:      Submit truncation mechanism as Proposed Standard.
June 2006:       Recharter to authorize phase two. 

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Jun 2005 13:02:47 -0700

Thanks, Russ. So, there are a couple of questions about the charter 
that we can possibly run in parallel:

- Did we leave anything out of phase 1 that would be both useful and 
possible for an IETF Working Group to achieve before we start phase 2?

- Are the milestones for phase 1 reasonable?

- Is the three-phase approach reasonable?

- Do we need to change or add to phases 2 and 3 now, or can we wait 
until the already-scheduled recharter?

For those of you planning on being at the Paris meeting, let's see 
where we get on the charter discussion before we start to set an 
agenda for our face-to-face meeting.

--Paul Hoffman, Director
--VPN Consortium

---------------------------------------------------
One-way Hash Function BoF (hash)

Security Area Director:

Security Area Advisor:

Mailing Lists:

Goals and Milestones:

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Jun 2005 15:15:43 -0700

[[ Another nudge, and a re-send for the new people on the list. While 
it would be lovely to think that there are absolutely no issues with 
the suggested charter, IETF history suggests there are probably at 
least a few comments. ]]

--Paul Hoffman, Director
--VPN Consortium

Security Area Director:

Security Area Advisor:

Mailing Lists:

Goals and Milestones:

--Paul Hoffman, Director
--VPN Consortium

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 14 Jun 2005 15:43:44 -0700

Qustions that I have are:

1. Is this new hash function we are considering in phase 1 going to be the
same length as SHA-1 or not?  This would appear to be implied by the goals.
Would replacement of SHA-1 with SHA-256 intact be considered as reasonable
in the first phase?

2. Can we do a reasonable job with phase 1 without having atleast some idea
of what would be required from phase 2, even if it is not a full set of
requirements so that we can evaluate phase 1 againist some type of critera.
Do we then want to start phase 2 (even if it is not completed) right away?

3.  I think that adding explicit deliverables for phase 2 could wait, I
think it must wait until a re-charter for phase 3.

4.  If a new hash function is recommended by this group, will it also be
responible to deal with any new signature algorithms and so forth that come
out of this decision?  For example, DSA is fixed on using SHA-1 and would
need changes to adapt to any new hash algorithm be it a trucated or a seeded
hash algorithm.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Hoffman
Sent: Tuesday, June 14, 2005 3:16 PM
To: [email-masked]
Subject: Re: [Hash] Charter discussion, round 1

[[ Another nudge, and a re-send for the new people on the list. While it
would be lovely to think that there are absolutely no issues with the
suggested charter, IETF history suggests there are probably at least a few
comments. ]]

Thanks, Russ. So, there are a couple of questions about the charter that we
can possibly run in parallel:

- Do we need to change or add to phases 2 and 3 now, or can we wait until
the already-scheduled recharter?

For those of you planning on being at the Paris meeting, let's see where we
get on the charter discussion before we start to set an agenda for our
face-to-face meeting.

--Paul Hoffman, Director
--VPN Consortium

Security Area Director:

Security Area Advisor:

Mailing Lists:
      General Discussion: [email-masked]
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/hash
      Archive:
http://www.ietf.org/mail-archive/web/hash/index.html

Recently, a team of researchers reported that the SHA-1 one-way hash
function offers significantly less collision resistance than could be
expected from a cryptographic hash function with an output of 160 bits.
This result has inspired significant research activities in government and
academia.  Additional information regarding the security of current one-way
hash functions, as well as proposals for new one-way hash functions, are
expected.  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.

A three-phase approach is envisioned.  The second and third phases will be
pursued only if it is clear that the international cryptographic community
is actively participating in the working group.

The first phase of the working group will specify one or more standards-
track mechanism replace or strengthen SHA-1.  At least two approaches will
be considered:

The first phase may also consider other potential solutions, and one or more
standards-track mechanism will be selected.

The second phase will consider the suitability of one-way hash functions for
use with IETF protocols.  These requirements will be published as one or
more BCP documents which specify the features and characteristics for
standards-track one-way hash functions.  The BCP documents will also
identify information that must be included in any request for a hash
function to be approved on the standards track.

The third phase will identify one or more standards-track one-way hash
functions that fulfill the requirements stated in the BCP documents
developed in phase two.  Guidance will also be developed to assist protocol
developers in the selection among the standards-track one-way hash
functions.

Goals and Milestones:

--Paul Hoffman, Director
--VPN Consortium

--Paul Hoffman, Director
--VPN Consortium

---

From: "D. J. Bernstein" <[email-masked]>
Date: 15 Jun 2005 22:25:11 -0000

Randomized hashing requires even more protocol changes than moving to a
longer hash, not to mention implementation changes. So it doesn't make
sense to consider randomized hashing without considering longer hashes.

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

---

From: EKR <[email-masked]>
Date: Wed, 15 Jun 2005 19:24:36 -0700

> Would replacement of SHA-1 with SHA-256 intact be considered as reasonable

Right. It's important here to distinguish between DSA/ECDSA and RSA.

There's basically no advantage to using a truncated SHA-256 over
straight SHA-256 with RSA. The performance is (of course) the same
and there's plenty of room for a 256-bit hash in a 1024-bit RSA block
(and people using 512-bit deserve what they get). 

So, defining truncated hashes really only makes sense for ECDSA/DSA
and other algorithms with fixed input sizes....

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Jun 2005 19:41:58 -0700

>sense to consider randomized hashing without considering longer hashes.

We have two use cases here, both of which are probably important. The 
first is algorithms with fixed input sizes; the second is protocols 
with fixed hash sizes (or variable hash sizes that max out at 128 or 
160). Both seem worth investigating and documenting.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Jun 2005 10:30:42 -0400

>Would replacement of SHA-1 with SHA-256 intact be considered as reasonable

This has already been discussed.  Below I propose some words in the charter 
to capture the discussion.

>Do we then want to start phase 2 (even if it is not completed) right away?

I do not think so.  I think we understand the needs for signatures, which 
is the primary issue for phase 1.

>think it must wait until a re-charter for phase 3.

Are you saying that we can do a good job on Phase 2 even if the 
participation from the international crypto community is low?

>need changes to adapt to any new hash algorithm be it a trucated or a seeded

If you are talking about the assignment of algorithm identifiers, I am not 
really concerned about who does it.

A new hash function should not have deep ripples into the signature 
algorithms.  It may have an impact on protocols to carry parameters.

Russ

= = = = = =

Here is the proposed rewording of the charter discussion of phase 1:

The first phase of the working group will specify one or more standards-
track mechanism replace or strengthen SHA-1.  Two classes of signature
algorithm need to be considered.  In support of RSA, there is no
advantage to reducing the size of a longer hash function output; the
RSA modulus size will easily accomodate large hash function output
values.  However, in support of DSA and ECDSA, the hash function output
size nees to match the subgroup size.

The irst phase will consider alt least two approches to strengthen
one-way hash functions:

   1) Truncate a larger one-way hash function output so that it can be
      used as a secure replacement of a shorter one-way hash function
      output.  For example, an alternative to SHA-1, the truncation
      mechanism could be used create a 160-bit result from the output
      of the SHA-256 one-way hash function.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 16 Jun 2005 07:49:14 -0700

> 160). Both seem worth investigating and documenting.

Do you have a specific example in mind of the latter? 

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Jun 2005 10:50:51 -0400

Thomas:

This text is intended to man that the salt is transferred along with the 
algorithm identifier some how.

Using the 1988 ASN.1 syntax, an algorithm identifier is defined as:

    AlgorithmIdentifier  ::=  SEQUENCE  {
         algorithm               OBJECT IDENTIFIER,
         parameters              ANY DEFINED BY algorithm OPTIONAL  }

In this structure, a new value would be assigned to identify the "SHA-1 
with a salt" hash function, and the parameters field would carry the salt 
value.

Russ

At 04:11 AM 6/16/2005, Thomas Roessler wrote:
>Hello,
>
>a quick question for clarification...
>
>On 2005-06-09 13:02:47 -0700, Paul Hoffman wrote:
>
>Is this meant to imply an approach where hash identifiers would look
>like, say, "shaN-0xdeadbeef", 0xdeadbeef being the salt?  Or is it
>merely meant to imply that the seed would be transferred along with
>the algorithm identifier, somehow?
>
>My concern with the first interpretation would be that it mixes
>badly with XML Signature, where algorithm identifiers are URIs
>(hence opaque), but where other mechanisms for passing parameters
>are readily available.
>
>Thanks,
>--
>Thomas Roessler, W3C   <[email-masked]>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Jun 2005 08:41:35 -0700

>Do you have a specific example in mind of the latter?

Nope, but if we find one, it will be important. If there are no IETF 
protocols with fixed hash sizes, but there are non-IETF protocols 
with them, we should probably still consider dealing with it. But, 
the main target of this phase is algorithms with fixed-size inputs.

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Fri, 17 Jun 2005 11:43:16 -0400

Perhaps "as a parameter to the algorithm identifier" captures the intent 
even better.  It would read:

   2) Including a random value in the hash function computation. The
      random block used is transferred as a parameter to the algorithm
      identifier.  This approach is sometimes called a "salted" or
      "randomized" hash function.

Russ

At 04:43 AM 6/17/2005, Thomas Roessler wrote:
>On 2005-06-16 07:53:27 -0700, Paul Hoffman wrote:
>
> > The proposal is a -00 draft, so it has not yet been decided, but it
> > is extremely likely to be the latter. IETF protocols don't usually
> > carry the names of algorithms, but instead use numeric identifiers
> > for them. In the current case, it is likely that the salt would be
> > carried as a parameter in an ASN.1 construct, or something similar.
>
>Thanks for the clarification.
>
>Maybe you could change "in the algorithm identifier" to "with the
>algorithm identifier", to make a little clearer that this
>description is not tied to any particular assumption of what an
>algorithm identifier looks like?
>
>Thanks,
>--

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Fri, 17 Jun 2005 10:24:51 -0600

"a parameter to the algorithm identifier" is even more confusing.  How
about "as a field in the algorithm identifier data structure"?  If that's
not right, then the method of introducing the random value should
be left as a mystery for the reader.

Hilarie

---

From: Russ Housley <[email-masked]>
Date: Fri, 17 Jun 2005 12:27:30 -0400

Good suggestion.  It now reads:

   2) Including a random value in the hash function computation. The
      random block used is transferred as a field in the algorithm
      identifier data structure.  This approach is sometimes called a
      "salted" or "randomized" hash function.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 17 Jun 2005 12:20:17 -0700

Russ, 

> 
> Jim:
> 
> >1. Is this new hash function we are considering in phase 1 
> going to be 
> >the same length as SHA-1 or not?  This would appear to be 
> implied by the goals.
> >Would replacement of SHA-1 with SHA-256 intact be considered as 
> >reasonable in the first phase?
> 
> This has already been discussed.  Below I propose some words 
> in the charter to capture the discussion.

Do we have any research available to use about the strengths of truncated
hashes?

> 
> >2. Can we do a reasonable job with phase 1 without having 
> atleast some 
> >idea of what would be required from phase 2, even if it is 
> not a full 
> >set of requirements so that we can evaluate phase 1 againist 
> some type of critera.
> I do not think so.  I think we understand the needs for 
> signatures, which is the primary issue for phase 1.

In my understanding of the world, it is in the case of signatures that the
requirements placed on hash functions are the most restrictive.  If we
understand this set of needs then phase 2 is just a case of identifying the
other places where hash functions are used and figuring out which of the
signature elements still apply.

Other places that hash functions are used (not all cases are applicable to
the IETF and list is not complete) - 
	- collision resistance - i.e. building a symbol table based on the
hash of a symbol
	- low level integrity check - assumes the absence of an attacker
	- keyed hash function authentication

> Are you saying that we can do a good job on Phase 2 even if 
> the participation from the international crypto community is low?

Yes I think so, we are identifying the locations where hash functions are
being used or are likely to be used in IETF protocols.  We are then
specifying what prosperities are needed in these situations.  This does not
seem to be highly reliant on big research issues.

> 
> >4.  If a new hash function is recommended by this group, 
> will it also 
> >be responible to deal with any new signature algorithms and so forth 
> >that come out of this decision?  For example, DSA is fixed on using 
> >SHA-1 and would need changes to adapt to any new hash 
> algorithm be it a 
> >trucated or a seeded hash algorithm.
> 
> If you are talking about the assignment of algorithm 
> identifiers, I am not really concerned about who does it.
> 
> A new hash function should not have deep ripples into the 
> signature algorithms.  It may have an impact on protocols to 
> carry parameters.

If we propose to replace SHA-1 in DSA/ECDSA then there is a big change for
those signature algorithms.
If we propose to replace SHA-1 for RSA v1.5 - that might be a big change,
but I would say we should just jump to RSA-PSS where this is not a big
issue.
I agree it might have a huge impact on some protocols as well.

> The first phase of the working group will specify one or more 
> standards- track mechanism replace or strengthen SHA-1.  Two 
> classes of signature algorithm need to be considered.  In 
> support of RSA, there is no advantage to reducing the size of 
> a longer hash function output; the RSA modulus size will 
> easily accomodate large hash function output values.  
> However, in support of DSA and ECDSA, the hash function 
> output size nees to match the subgroup size.
> 
> The irst phase will consider alt least two approches to 
> strengthen one-way hash functions:
> 
> The first phase may also consider other potential solutions, 
> and one or more standards-track mechanism will be selected.  
> 
> 
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 20 Jun 2005 10:04:00 -0400

Jim:

> > >1. Is this new hash function we are considering in phase 1 going to be
> > >the same length as SHA-1 or not?  This would appear to be implied by 
> the goals.

As we have already seen posted here, this is the approach being used in 
ECDSA.  Also, NIST is working on a document in this area.  I hope that John 
Kelsey will finish the document before the -00 cutoff, but that seem 
unlikely at this point.

> > >2. Can we do a reasonable job with phase 1 without having atleast some
> > >idea of what would be required from phase 2, even if it is not a full
> > >set of requirements so that we can evaluate phase 1 againist some type 
> of critera.

I do not see any disagreement here ...

>seem to be highly reliant on big research issues.

I would like to see more discussion of this point on this mail list and ant 
the BoF.  You might be able to convince me that we should include Phase 1 
and Phase 2 in the first version if the charter.

> > >4.  If a new hash function is recommended by this group, will it also
> > >SHA-1 and would need changes to adapt to any new hash algorithm be it a

I believe that the complexity should be less than adding support for a new 
hash/signature pair.  This should be fairly straightforward if the 
implementation has any kind of a crypto API.  The biggest ripple would seem 
to be looking into the algorithm identifier parameters.  Previously, these 
were always absent or NULL, so a new bit of code will be needed here.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Jun 2005 17:15:33 -0700

At 10:04 AM -0400 6/20/05, Russ Housley wrote:
>I would like to see more discussion of this point on this mail list 
>and ant the BoF.  You might be able to convince me that we should 
>include Phase 1 and Phase 2 in the first version if the charter.

Remember that this effort is intended to be done in an IETF Working 
Group, and WGs are inherently open to all participants. If we begin 
the work or deciding the criteria that make a good hash without the 
experts from the international crypto community who understand those 
criteria being on-board, the WG will probably tend towards 
non-experts quoting (and misquoting) what they read in the trade 
press.

There is the additional factor that we are just finding out some 
important things about hashes, and have heard very few analyses of 
that new information. Do the discoveries by Wang et. al. only apply 
to collisions? If we wait a year or two, will the crypto community be 
able to extend those into measurable preimage attacks? If so, what 
will we know then?

I'm not saying we need to wait on chartering phase 2, but we should 
certainly not try to rush this based on our limited information.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Mon, 27 Jun 2005 13:01:34 +0100

>      "randomized" hash function.

It strikes me as weird, describing it as a parameter to the algorithm 
identifier - firstly, it seems this wording is derived from where you 
want to fit it into ASN.1, and secondly, why constrain it in this way? A 
protocol could easily transfer the random value somewhere other than in 
the algorithm identification.

Indeed, if the protocol doesn't use algorithm identifiers every time it 
uses a hash (TLS would be an example of this, surely?), you'd be utterly 
screwed by this wording.

Cheers,

Ben.

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

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

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 27 Jun 2005 14:41:38 -0400

Ben:

Good point.  The words should say that three things need to be transferred 
(either implicitly or explicitly).  They are the data to be hashed, the 
hash algorithm, and the random value.   Where in the protocol that these 
values appear is not important to the algorithm development.

Russ

At 08:01 AM 6/27/2005, Ben Laurie wrote:
>identifier - firstly, it seems this wording is derived from where you want 
>to fit it into ASN.1, and secondly, why constrain it in this way? A

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Jun 2005 08:31:58 -0700

At 1:01 PM +0100 6/27/05, Ben Laurie wrote:
>Russ Housley wrote:
>>Perhaps "as a parameter to the algorithm identifier" captures the 
>>intent even better.  It would read:
>>
>It strikes me as weird, describing it as a parameter to the 
>algorithm identifier - firstly, it seems this wording is derived 
>from where you want to fit it into ASN.1

... and PGP and IKE and other protocols that have parameters for 
crypto functions.

>, and secondly, why constrain it in this way? A protocol could 
>easily transfer the random value somewhere other than in the 
>algorithm identification.

You may be right, but I'm not convinced about "easily".

Do you have different wording that would help, for example, TLS use 
these kinds of functions if we define them?

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Tue, 28 Jun 2005 16:54:15 +0100

Paul Hoffman wrote:
>> want to fit it into ASN.1
> 
> 
> ... and PGP and IKE and other protocols that have parameters for crypto 
> functions.

I've managed to avoid IKE (so far) but PGP doesn't have parameters for 
crypto functions.

>> , and secondly, why constrain it in this way? A protocol could easily 
>> transfer the random value somewhere other than in the algorithm 
>> identification.
> 

I'm pretty sure its easy. What isn't so easy is changing all the 
applications to understand the modified protocol.

> these kinds of functions if we define them?

'Including a random value in the hash function computation.  The random 
block used is transferred at appropriate points in the protocol (ideally 
once for each use of the hash function).  This approach is sometimes 
called a "salted" or "randomized" hash function.'

And now I'm thinking harder about this, we also should say that care 
needs to be taken that the right party chooses the random value (or it 
may be that both (all?) parties should choose it in some cases) - since 
allowing the attacker to choose it would be bad.

Cheers,

Ben.

--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Jun 2005 09:20:37 -0700

At 4:54 PM +0100 6/28/05, Ben Laurie wrote:
>I've managed to avoid IKE (so far)

Probably wise, or at least sanity-saving.

>  but PGP doesn't have parameters for crypto functions.

Ah. I now see that. There are parameters, but they're baked into the 
packet format.

>applications to understand the modified protocol.

Of course.

>'Including a random value in the hash function computation.  The 
>random block used is transferred at appropriate points in the 
>protocol (ideally once for each use of the hash function).  This 
>approach is sometimes called a "salted" or "randomized" hash 
>function.'

I prefer "value" to "block" in the second sentence, but the rest 
seems fine to me.

Do others have an opinion on this wording?

>needs to be taken that the right party chooses the random value (or 
>it may be that both (all?) parties should choose it in some cases) - 
>since allowing the attacker to choose it would be bad.

The whole purpose here is to allow the signing party to add 
randomness to the message they are signing. If the attacker is 
signing, don't they already have all the control they need for the 
collision attacks?

--Paul Hoffman, Director
--VPN Consortium

---

From: Ben Laurie <[email-masked]>
Date: Tue, 28 Jun 2005 17:34:05 +0100

Paul Hoffman wrote:
>> random block used is transferred at appropriate points in the protocol 
>> (ideally once for each use of the hash function).  This approach is 
>> sometimes called a "salted" or "randomized" hash function.'
> 
> I prefer "value" to "block" in the second sentence, but the rest seems 
> fine to me.

Fair enough - I took that word from the existing wording.

>> may be that both (all?) parties should choose it in some cases) - 
> The whole purpose here is to allow the signing party to add randomness 
> to the message they are signing.

It is? Isn't the purpose to try to mitigate _all_ the problems caused by 
weak hashes?

> If the attacker is signing, don't they 
> already have all the control they need for the collision attacks?

Not if the relying party chooses the random value.

--

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Jun 2005 09:35:21 -0700

> these kinds of functions if we define them?

TLS probably doesn't need them. Digital signatures in TLS are over
jointly randomly generated values and not for non-repudation purposes.

-Ekr