Re: Signing encrypted data

----- Original Message -----
From: "Amir Herzberg" <AMIR@newgenpay.com>

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

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. Last time
I checked there wasn't any restriction about whether or not you could sign
data that has already been encrypted, in fact I think we discussed it and
decided that if they want to that's fine even though it won't supply exactly
what they might think it will supply.

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

Actually there remains this pesky little proof that you only have to guess
the entropy content to guess the exact text. Assuming [CMR] is deterministic
(which if it isn't it doesn't qualify for many other things), it may be
proven, but it is not useful.

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

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. We can narrow our collision
searches using pre and post image ideas. In fact your example was a
post-image addition to text, so if the cipher is (unknown)post-image weak it
will be broken using this.

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

Actually it's the fairly popular "Can we use this as leverage" heuristic.
What you have to realize is that a hash function is only a N-ary tree where
the data being hashed is used to walk it. In the case of SHA-1 it has 2^160
possible states with 2^512 connections from one state to the next state.
With hash functions we are provided the path to follow and use that to
determine the final node, sometimes we have previous knowledge of the node
we are supposed to be at. It is merely a state machine with a larger than
normal set of states. We have only 1 measure of strength, whether or not we
can compute a path to a given endpoint, and how long it will take. Any
assumptions otherwise are misleading.

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

It was a suggestion of one way to imbue both unknownpre and unknownpost
images into a signature. It was chosen for SHA-1, it has the desirable
properties of fully changing the pre-state, fully moving the post-state, and
because it crosses block boundaries it is more likely to induce chaos.
There's a lot of cryptanalysis behind using a method like that, regardless
the attacker still only has to guess the entropy content which may vary
widely.
                            Joe

Received on Monday, 26 March 2001 14:48:45 UTC