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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 18 Mar 2005 12:39:32 -0800

> 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

---

From: Hugo Krawczyk <[email-masked]>
Date: Fri, 18 Mar 2005 23:44:44 +0200 (IST)

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:

> > to sign the ciphertext, not the plaintext.The presence of an IV in
> > the ciphertext to vary, of course.(Yes, I know that S/MIME
> > can do the
> > I wouldn't read too much into that.For one thing, they were very
> > used for secrecy.Second, the presence of the random number in DSA