Subject: RE: [Cfrg] Who needs collision-resistance, anyway?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 18 Mar 2005 15:50:43 -0800

This is true if the MAC key is a salt is published in the sig, it is not
true if the MAC key is a secret transported separately.

I fail to see how you are able to determine that secrecy is a superfluous
requirement in my applications when I have not told you what they are.

> -----Original Message-----
> From: Hugo Krawczyk [mailto:[email-masked]] 
> Sent: Friday, March 18, 2005 4:45 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> Subject: RE: [Cfrg] Who needs collision-resistance, anyway? 
> 
> 
> Phil,
> 
> Using a randomized hash for a signature doesn't make the 
> signed msg any more protected than with a regular hash. Since 
> the "salt" is known then there is no "secret key" to protect 
> your msg. In particular, if I have a guess of the message and 
> you use RSA with a randomized hash I can still verify my guess.
> 
> Hugo
> 
> PS: Besides, I also recommend not to overload signatures with 
> unnecessary requiremnts such as secrecy. It is difficult 
> enough to get the signature schemes to do their essential 
> job, so why add superflous requirements?
> 
> On Fri, 18 Mar 2005, Hallam-Baker, Phillip wrote:
> 
> >
> >
> > > From: Steven M. Bellovin [mailto:[email-masked]]
> >
> > > In message 
> > > 
> <[email-masked]
> > > om>, "Hallam-Baker, Phillip" writes:
> >
> > > Correct me if I'm wrong, but I thought that preference these days 
> > > was to sign the ciphertext, not the plaintext.The 
> presence of an IV 
> > > in the encryption (or, for that matter, the use of a new 
> key) will 
> > > cause the ciphertext to vary, of course.(Yes, I know that 
> S/MIME can 
> > > do the signing and encryption in either order.)
> >
> > That depends on what the security model is. Signing the 
> ciphertext is 
> > only possible if you have end to end security. That model does not 
> > work in contexts where it is either difficult to identify 
> the end or 
> > there is more than one end point.
> >
> > For example a Web Services mediated transaction can involve three, 
> > four any number of parties who have to be considered as fist class 
> > endpoints in respect to some part of the transaction
> >
> > I can imagine a lot of cases where signatures are going to end up 
> > stored in databases separately from the data that is signed.
> >
> > Signing a MAC has the interesting property that I have a signature 
> > that can only be verified if the verifyier knows the secret. This 
> > provides control over non-repudiation preventing a third 
> party relying 
> > on data.
> >
> > > >
> > > >I do not want the signature on a message to leak any information 
> > > >concerning the contents. This means that I don't have to worry 
> > > >about where the signature is being stored when auditing for
> > > confidentiality
> > > >protection.
> > >
> > > I hear you, and I'm not prepared to say you're wrong, though it 
> > > would be nice to spend more time discussing the actual 
> threat model.
> > > >
> > > >I note that the one digital signature function that the NSA
> > > has given
> > > >us has this property which is quite interesting in and of itself.
> > > >
> > > I wouldn't read too much into that.For one thing, they were very 
> > > constrained; they really wanted a signature function that 
> couldn't 
> > > be used for secrecy.Second, the presence of the random 
> number in DSA 
> > > created a serious vulnerability: anyone who knew it could recover 
> > > the secret key.
> > >
> > > 		--Prof. Steven M. Bellovin, 
> http://www.cs.columbia.edu/~smb
> > >
> > >
> > >
> >
> > 
> _______________________________________________
> > Cfrg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/cfrg
> >
> 
> 
> 

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Sat, 19 Mar 2005 02:15:50 +0200 (IST)

On Fri, 18 Mar 2005, Hallam-Baker, Phillip wrote:

> requirement in my applications when I have nottold you what they are.

I was not trying to say anything about your specific applications which I
do not know and may well need secrecy. My point was, and excuse me if it
came across differently, that adding secrecy to the basic requirments of
signatures (as a basic cryptographic primitive) is not a good idea.
Signatures are essentially about binding a document to a cryptographic
key (and transitively to a signer) and not about hiding the document.

Applications that need secrecy should provide it by specific and
explicit means.

Hugo