RE: Signing encrypted data

Joe says, 
> > .... In many secure e-payments and e-commerce
> > applications, we sign plaintext to provide non-repudiation (without
exposing
> > all content to some parties that still need to verify the signature). I
now
> > understand that the current draft intentionally excludes this for
security
> > concerns.
> 
> What the current draft very intentionally excludes is the 
> ability to publish
> a signature on data that was encrypted after the signature 
> was performed.
> This should not be used by anyone for very good security 
> reasons. 

So, it seems we do agree, at least, on what we disagree on: whether the
draft should intentionally exclude signing of plaintext (while sending only
an encrypted version of it for confidentiality). Right?

You seem to think this is justified for a `very good security reasons`.
Right? 

Question: what are these security reasons?

Comments:
1. Signing of secret values (encrypted or not) is done by existing
protocols. E.g. in SET we sign the credit card number, after performing HMAC
of it with a random key and pad, much like I proposed as a possible
implementation. 
2. I've consulted again with some of the leading cryptographers in this
area, specifically Shai Halevi, Ran Canetti and Hugo Krawczyk, and they all
agreed it is perfectly reasonable and secure to sign secret values using
such techniques (in particular signing HMAC (x,rand)). 
3. There are important applications where signing secret values is
necessary. Standards should try to support such cases, warning if necessary
so that implementors can avoid security pitfalls, but not excluding an
important application due to a security concern which may be avoided by
proper implementation. 

...... skip
> Actually there remains this pesky little proof that you only 
> have to guess
> the entropy content to guess the exact text. 

This certainly is not a security concern. The signer is in complete control
over the amount of randomness added to the signed data (and hence of the
entropy), therefore can easily use sufficient random bits to make this
attack infeasible. Guessing is always possible - you can guess secret keys
as well - but when length is appropriate, this is not a realistic attack. 

> > Joe was concerned about this suggestion:
> > >
> > > It depends on how post-image resistant the hash function in
> > > use is. If SHA-1
> > > is used then it will add most of what you expect, MD-5 it will add
> > > significantly less than expected (there are known 
> collisions in the
> > > compression function).
> >
> > Actually, the property we need here is unrelated to 
> collisions, and... <skip>
> 
> I'm sure I'm not the first person to tell you that all a hash 
> fucntion has
> is collisions and collision-resistance. If it's not related 
> to collicions,
> it's not related to hash functions, which means that it's not 
> related to
> modern cryptographic signature techniques. 

As in an earlier `errata` note I've sent immediately after sending the note
you responded to, I agree - I made a mistake, collision resistance is
necessary to provide non-repudiable signatures. 

However, as a side comment, the definitions used by most experts do not
require collisions-resistance from every hash function (and certainly
require additional properties). See really any textbook to see that there
are many applications where hash functions which allow collisions can be
appropriate. But indeed not for non-repudiation. 

Best regards, 
Amir Herzberg
CTO, NewGenPay Inc.  

See our demo and overview/tutorials on secure e-commerce in
http://www.NewGenPay.com

Received on Monday, 26 March 2001 18:54:27 UTC