RE: Signing encrypted data

I think we get closer to the real issue, which is: the existing spec seems
to exclude the possibility of signing plaintext (as well as possibly
ciphertext) of encrypted objects. 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. 

Joseph Ashwood (Joe) says: 

> I believe we reached some concensus on a few of these issues.

Do you mean in our discussion or in the past? Again I wish to apologise if
I'm opening issues which were substantially discussed in the past. 

> If you are signing the plaintext then you are signing before encryption,
> which violates several prudent design decisions, It is far better to not
> concurrently have encryption and signing on the same data.

I think this is exactly where we differ. I believe that we can sign the
plaintext is a completely secure way; furthermore there are important,
convincing applications where it is important to have a signature over the
plaintext, to enable proof of signature (non-repudiation) and to allow
removal of the encryption (replacing it with plaintext). 

Definitely, one has to be careful about doing this. However, there are  well
known cryptographic techniques for signing (or hashing) plaintext without
allowing a guessing or other attack on it. Specifically, hash the plaintext
with Perfectly One-Way Probabilistic Hash Functions [CMR]. The exact
function used in [CMR] is actually sufficiently efficient for practical use
(and has formally-proven security), but of course one can also use a
heuristic function assumed to have similar properties, as is done usually in
practice. In particular the following heuristic which I mentioned before
(just as an example): 
> 
> > if a randomizer is appended
> > to the plaintext portions before hashing them, and this 
> randomizer is made
> > available only to entities which have the decryption key - 
> other parties
> > only see the result of the hash. Any problem with this 
> approach, which
> > supports important additional applications?

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 I am not
aware of a known weakness on this (trivial) heuristic when using either MD5
or SHA-1. 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]). 

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

This is another common heuristic, prompted possibly by a paper of my friend
Gene Tsudik many years ago, which again attacks on the collision resistance
property (and hence again is not relevant). However, I certainly have no
objection to using this heuristic as it is almost as simple and efficient as
the previous one. 

> If this is done 
> then your only
> concerns are pre/post-image weak (which is often far removed from not
> strong) or not mid-image strong(which it is believed would imply a not
> strong hash in a very noticable way). I think since you're 
> already using XML
> it may be easier (and would be at least as strong) to do:
> <begin tag>
> <preimage>512 random bits for SHA-1</preimage>
> <data>...</data>
> <postimage>512 random bits for SHA-1</postimage>
> </begin tag>

I'm not quite sure what you meant in this XML fragment. Can you clarify?

<skipped rest since it depends on above>

Best regards, 
Amir Herzberg
CTO, NewGenPay Inc.  

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

[CMR] Perfectly One-Way Probabilistic Hash Functions by Ran Canetti, 
Daniele Micciancio and Omer Reingold, Proceedings of 30th STOC, 1998.

Received on Sunday, 25 March 2001 02:00:09 UTC