Re: Signing encrypted data

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

----- Original Message -----
From: "Amir Herzberg" <AMIR@newgenpay.com>
To: <hal@finney.org>; <xml-encryption@w3.org>
Sent: Wednesday, March 21, 2001 1:43 AM
Subject: RE: Signing encrypted data


> Yes, we were miscommunicating. I hope my goal, of allowing signature to a
> message containing encrypted and non-encrypted objects, and of signing
> (potentially) both ciphertext and plaintext, and allowing verification of
a
> signature by agents which do not have access to some encrypted objects, is
> now clear.

I think the decision about the nature of the encryption here gives some form
of guidance. The decision I mean in particular is that encryption after
signature should void the signature. This leads rather cleanly to stating
that everything inside a signature goes unparsed to a very large degree
(barring canonocalization, etc). The only other issue would be making sure
that the encryption does not cross signature boundaries, in particular that
all the keys in use are also signed (everything from the certificate down in
most cases). Would making those statements clear be useful?

> >
> > Of course you can sign AFTER encrypting; that has never been
> > a security
> > issue.  The only question in that case is to design data structures
> > that allow you to indicate whether the signature is on the ciphertext
> > or the plaintext.  But if that is all you want to do, there is no need
> > for salt and no need to encrypt the signature.
>
> If your signature is (also) on the plaintext, the concerns are the same as
> before.

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.

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

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). 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. 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>
This would actually create boundary problems for generating an pre/post
image collision provided that you generate the hash beginning with
<begin...... and ending with ....tag> because of the 512-bit alignment in
SHA-1, the same for the post-image (other sizes would have to be chosen for
other hash functions).
                Joseph Ashwood
                Cryptanalyst

Received on Wednesday, 21 March 2001 14:34:00 UTC