From: Yongge Wang <ywang@certicom.com>

Date: Mon, 26 Mar 2001 22:31:20 -0500 (EST)

To: Joseph Ashwood <jashwood@arcot.com>

cc: "Xml Encrypt (E-mail)" <xml-encryption@w3.org>

Message-ID: <Pine.BSF.3.96.1010326215235.3442A-100000@eng1.certicom.com>

Date: Mon, 26 Mar 2001 22:31:20 -0500 (EST)

To: Joseph Ashwood <jashwood@arcot.com>

cc: "Xml Encrypt (E-mail)" <xml-encryption@w3.org>

Message-ID: <Pine.BSF.3.96.1010326215235.3442A-100000@eng1.certicom.com>

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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:32:00 UTC
*