Re: Signing encrypted data

> > First I think this is a XML-DSIG problem.
> 
> I believe it is a problem with the line between them. BUt if I were to place
> it in one generically I would agree, however the DSIG spec is effectively
> done, so the place to make changes to the line would be here.

Agree.

> > DSA and ECDSA all require to have a random seed "r"
> > for each signature.
> 
> Yes but with both cases the original hash can be found with vastly
> diminished work. So the effect is that of publishing the hash (with some
> extra workload), which is exactly where the problem started.

Assume that the hash function (e.g., SHA1) is an ideal collision-resistent
hash function, then the hash output is an ideal random output.
Then DSA is believed to be existentially forgery free.
Indeed, two years ago, the Frankfurt group (Schnorr's group)
proved that if the hash function is an ideal random function
and the base group is generic, then DSA is provably secure
no matter how short plaintext message you sign (you can
sign polynomially many messages). That is, publishing hash
value will not give the adversary any advantage assuming that
SHA1 is ideal (and people generally believe so).

> > And the security issues are discussed
> > in the DSA or ECDSA standard. It is not a problem for
> > XML-Encryption.
> 
> Actually there is surprisingly little discussion about the entropy content
> issues in either the DSS or SHS papers (DSA and SHA-1). They generally
> simply assume that the problems of hash algorithms and signatures is known,
> the proof of usability supplied by the papers is of little use because they
> provide proof of difficulty of changing the hash value.

There is huge number of academic research papers on the security
of DSA (or what you mean entropy).

> > Also generally the signatures are on
> > plaintext.
> 
> I think much of this discussion is on what needs to be considered plaintext.
> If the data will be enrypted either the signature needs to be a part of that
> plaintext, or the signature needs to be performed on the ciphertext.

OK.. I agree that there might need much discussion here.
Indeed, opinion from cryptographers should be consulted.
Look at those guys who designed Bluetooth and IEEE802.11,
I am sure any real cryptographer can break these protocols
in half hour if they really have interest and have a look
at the protocol details... I mentioned this since I feel
the knowledge from crypto-research is quite important in
designing secure protocols. Some guys (e.g., those who designed
Bluetooth and IEEE802.11) may feel they have quite confidence
in cryptography, but the fact is they know nothing.

> > So this is really no reason to exclude
> > the case that one can sign on a plaintext. Most
> > contract are signed on plaintext (of course, need to
> > hash it first).
> 
> However you will still have to have the decryption key to verify that
> signature, which means there is no reason at all to leave the signature in
> the open, and significant risk associated with it. Based on this I see very
> significant reasons to specifically exclude the simultaneous operation of
> encryption and signing.

OK.. this is again the above question. If XML-encryption want to leave
this as an implementation issue, then we might need not to 
discuss it here. However, if XML-encryption need address this problem
of the ordering of signature and encryption. I think there might
be several choices:

If the order is: "signature first, then encryption", then
as mentioned in the requirement, the signature and the hash
value must be encrypted also.

If the order is: "encryption first, then signature", I think 
there is no much space for discussion here then.

Of course, I personally prefer the second choice, that is,
"encryption first, then signature". Have a look at 
Sheffer and Krawczyk's IETF draft on the working group
"IP Secure Remote Access":
http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-01.txt

In the last section of this draft, they mentioned a recent
result by H.Krawczyk (who is also one of the authors
of HMAC): from a communication security viewpoint,
MAC should be after encryption.. Unfortunately, I have not
got this paper, thus have no chance to have a look
the reason. But this result gives us some intuition that
the best way is to encryption first, and then signature.

I am citing without the permission their words here
(i hope this is leagal):

   Recent research shows that the best way to combine the authentication 
   (MAC) and encryption of the legacy-authentication and credential 
   material is by first encrypting the information and then applying the 
   MAC on the ciphertext. Indeed, using results from [14] one can show 
   that under this order of operations PIC can be proved secure. 
   Unfortunately, the existing ISAKMP specifications and payload 
   processing support the other ordering, namely, first MAC the 
   plaintext then encrypt (i.e. compute a HASH payload on the plaintext, 
   then, if encryption is required, compute it over the plaintext and 
   HASH).  
    

> We need to enforce that they are serialized. If the encryption happens
> before the signing there is not problem. If the encryption happens after the
> signing there needs to be a some method in place that will disallow guessing
> attacks. Since the prime target for this seems to be credit cards which have
> significantly less than 64-bits of entropy the reasonable decision would be
> to simply not do it (to do it securely you have to blend the encryption and
> signature, which would put it outside the scope of the encryption and dsig
> groups). All that will happen by exposing signatures on data that is later
> encrypted is the exposure of another potential method of attack.

Strongly agree with this point.

Best regards,
Yongge

>                     Joe
> 
>

Received on Monday, 26 March 2001 22:31:36 UTC