RE: Signing encrypted data - fix to stupid error in my last note

Corrections to my last note: 

> 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, 

Sorry, a stupid error, of course we DO care for collisions in a commitment
application and therefore SHA-1 is indeed preferable. 

> But let's agree first on the need, and then we can define a
> specific function which we can all feel is secure enough (we 
> could even use
> the simple, efficient and yet proven-secure construction in [CMR]). 

But I don't recommend it - I think while [CMR] is relatively efficient and
practical, we should allow a solution which is roughly as efficient as
regular hash. 

In fact, Shai Halevi noticed that for the 

Notice that in the application we discuss, of committing to some x using a
randomizer r, the ransomizer may be different for each commitment and kept
secret until proving the commitment. In this case, Shai Halevi noted that
the  trivial c(x)=h(x||r) function I suggested the proof is very simple: 
the binding follows from the collision-resistance of h(), and the secrecy 
follows since c(x) is indistinguishable from random for all x.  For this 
case, where rand is revealed, I don't know how to prove it (other than in 
the random-oracle model). 

> > So while it provides resistance right 
> > now, it does
> > not necessarily provide resistance for the future, in order 
> > to make it as
> > resistant as possible (with currently known hash algorithm 
> > types) you should
> > actually pre and post pend some random data. 

Clearly this constructions, c(x)= h( r1 || x || r2), where both r1 and r2
are random and kept encrypted (secret) until proving commitment, is fine as
well. 

Best regards, 
Amir Herzberg
CTO, NewGenPay Inc.  

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

Received on Sunday, 25 March 2001 02:54:11 UTC