Re: IGE mode is broken (Re: IGE mode in OpenSSL)
On 9/9/06, Adam Back [EMAIL PROTECTED] wrote: IGE if this description summarized by Travis is correct, appears to be a re-invention of Anton Stiglic and my proposed FREE-MAC mode. However the FREE-MAC mode (below described as IGE) was broken back in Mar 2000 or maybe earlier by Gligor, Donescu and Iorga. I recommend you do not use it. There are simple attacks which allow you to manipulate ciphertext blocks with XOR of a few blocks and get error recovery a few blocks later; and of course with free-mac error recovery means the MAC is broken, because the last block is undisturbed. http://groups.google.ca/group/sci.crypt/browse_thread/thread/e1b9339bf9fb5060/62ced37bb9713a39?lnk=st Travis H. wrote: I don't see why integrity+confidentiality has to cost n log n operations. I haven't read the whole paper yet (and the proof is at the end) The idea is to costlessly piggy back integrity on top of confidentiality is to have error propagation, so that any fiddling with the message will cause all packets after the fiddling to be random noise. Unfortunately, if this is done with linear operations, it can be undone with linear operations. If it is done with non linear operations (my recommendation), it is hard to prove anything. Or are universal hashes considered cryptographic-weight primitives, and thus this constitutes a second pass over the plaintext? Yes. The idea is to get integrity for free, but unfortunately so many integrity-for-free schemes have come undone, making people suspicious. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Exponent 3 damage spreads...
Hi, We have been researching, which vendors were generating Exponent 3 keys, and we found the following until now: * Cisco 3000 VPN Concentrator * CSP11 * AN.ON / JAP (they told me they would change it on the next day) (perhaps more to come) My current estimate is that 0.26% of the certificates in the wild have Exponents =17 Best regards, Philipp Gühring - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
On 9/15/06, Taral [EMAIL PROTECTED] wrote: *That* is the Right Way To Do It. If there are variable parts (like hash OID, perhaps), parse them out, then regenerate the signature data and compare it byte-for-byte with the decrypted signature. You know, this sort of reminds me of a problem with signatures on tar.gz files. Basically, you have to keep them around so you can check the signature, but you can't delete them because you can't reconstruct the original tar file from an untarred copy because it's full of metadata that won't necessarily be replicated on your system. For example, uids and gids. Unfortunately, cpio appears to be worse. From a tape backup standpoint, tar doesn't store enough (extended attributes, hard links, etc.) and so it appears to store both too much and too little at once. It would be nice if there was a format other than shar which was deterministic and only contained the contents of the files; no metadata. Then we could sign the code and nothing else. From a security point of view, shar has obvious problems :-) Anyone know of a relevant tool? -- Enhance your calm, brother; it's just ones and zeroes. Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/ GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Exponent 3 damage spreads...
Leichter, Jerry [EMAIL PROTECTED] writes: I agree that there are two issues, and they need to be treated properly. The first - including data after the ASN.1 blob in the signature computation but then ignoring it in determining the semantics - is, I'll argue, an implementation error. You list only OpenSSL as definitely vulnerable, NSS as ?, so it sounds like only one definitive example. Yes. I'm only familiar with NSS as a user, not as a developer. For some reason, the Mozilla bug tracker hides information about this problem from us, so it is difficult to track the code down. I believe I identified the patch that solved the problem in NSS, search for 350640 in: http://bonsai.mozilla.org/cvsquery.cgi?branch=HEADfile=mozilla/security/nss/date=month The bug discussion is not public: https://bugzilla.mozilla.org/show_bug.cgi?id=350640 Possibly also bug reports 351079 and 351848 are related to the same problem, but these bugs are also hidden. The actual patch for 350640 is: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=contextwhitespace_mode=showsubdir=mozilla/security/nss/lib/utilcommand=DIFF_FRAMESETfile=secdig.crev1=1.6rev2=1.7root=/cvsroot If some NSS developer could chime in, that would help. Even if NSS has the same problem, one has to look at code provenance. Sure. OSS efforts regularly share code, and code to pick apart data fields is hardly kind of thing that is going to inspire someone to go out and do it better - just share. I think you want to read up on free software license compatibilities, and in particular OpenSSL vs GPL. But this is a very different topic, that we shouldn't pursue here... The second - embedded parameter fields - is a much deeper issue. That's a protocol and cryptographic error. The implementations appear to be correctly implementing the semantics implied by the spec - ignore parameters you don't care about. At least some versions of PKCS#1 does NOT say that, e.g., RFC 3447. RFC 3447 essentially says to generate a new token and use memcmp(). Such implementations would not be vulnerable to any of the current attacks, except the Kaliski ASN.1 OID attack (an attack that doesn't work on existing implementations). This is common practice, and a fine idea in *most* situations, since it allows for extensions without breaking existing implementations. I believe the principle of Be conservative in what you do; be liberal in which you accept from others is generally a bad advice. The principle hides problems that should be fixed. Hiding a problem instead of fixing it typically enables bad things to happen. We've seen that lead to security problems for many years, this is just one example. /Simon - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
