Re: Exponent 3 damage spreads...
-- Peter Gutmann wrote: Right, but it's been pure luck that that particular implementation (and most likely a number of others) happen to have implemented only a small number of hash algorithms that allow only absent or NULL parameters. Anything out there that implements a wider range of algorithms, including any that allow parameters, is most likely toast. Parameters should not be expressed in the relevant part of the signature. The only data that should be encrypted with the RSA private key and decrypted with the public key is the hash result itself, and the padding. If the standard specifies that additional material should be encrypted, the standard is in error and no one should follow it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG sVNWfKHHWrogEro6rkjKzE2XEHGqyk1tXLiayWU7 4joW/r8h3DIfdlwaI5up/06PSaWuhEtwMmF9TsuGR - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: IGE mode is broken (Re: IGE mode in OpenSSL)
On 9/10/06, James A. Donald [EMAIL PROTECTED] wrote:
Typo:
We transmit T(k)= {W(k)} + W(k-1)|{W(k-1)} where |
means bitwise or, curly brace means encryption.
Should read:
We transmit T(k) = {W(k)} + ((~W(k-11){W(k-1)})
where ~ means bitwise negation, | means bitwise or,
curly brace means encryption.
Today wasn't a good day for typing? ;-)
T(k) = {W(k)} + (~W(k-1)|{W(k-1)})
Right?
I'm in agreement with the don't use a screwdriver as a crowbar
crowd; unless the combined modes came with clear proofs and
very weak assumptions computers are fast and getting faster,
and my performance needs remain relatively constant.
--
On the Internet noone knows you're a dog - except Bruce Schneier.
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: A note on vendor reaction speed to the e=3 problem
David Shaw [EMAIL PROTECTED] writes: RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. Ah, OK, and it uses the NULL-parameters interpretation (section 5.2.2), which would actually be incorrect according to the current standards but at least it's unambiguous. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why the exponent 3 error happened:
-- James A. Donald wrote: Code is going wrong because ASN.1 can contain complicated malicious information to cause code to go wrong. If we do not have that information, or simply ignore it, no problem. Ben Laurie wrote: This is incorrect. The simple form of the attack is exactly as described above - implementations ignore extraneous data after the hash. This extraneous data is _not_ part of the ASN.1 data. But it is only extraneous because ASN.1 *says* it is extraneous. If you ignore the ASN.1 stuff, treat it as just arbitrary padding, you will not get this problem. You will look at the rightmost part of the data, the low order part of the data, for the hash, and lo, the hash will be wrong! --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG UXewrm6/A/3rklAbGfwShB29YFqjqqWLa3AU+htK 4Xf+hOFyYI4Pv0jWjzDC226z/LHorwYhZlhfNvl2z - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: A note on vendor reaction speed to the e=3 problem
-- Peter Gutmann wrote: How does [GPG] handle the NULL vs.optional parameters ambiguity? David Shaw: GPG generates a new structure for each comparison, so just doesn't include any extra parameters on it. Any optional parameters on a signature would cause that signature to fail validation. RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which nicely cuts down on ambiguity. This amounts to *not* using ASN.1 - treating the ASN.1 data as mere arbitrary padding bits, devoid of information content. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG KBZXRF1divvJGZ6Zm3lHv3qjnS9Bwhl22NfSlYK3 4zPRSIE0Q6qUaTtmKPPoKOsPNzAtcdWuthGi5nNTi - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: IGE mode is broken (Re: IGE mode in OpenSSL)
--
James A. Donald
We transmit T(k)= {W(k)} + W(k-1)|{W(k-1)} where |
means bitwise or, curly brace means encryption.
Should read: We transmit T(k) = {W(k)} +
((~W(k-11){W(k-1)}) where ~ means bitwise negation,
| means bitwise or, curly brace means encryption.
Travis H. wrote:
Today wasn't a good day for typing? ;-)
T(k) = {W(k)} + (~W(k-1)|{W(k-1)})
Right?
Yes, right, though usually when I get two errors in
rapid succession, I get a third error.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
ORlgCbjNlrRQnTh47hjBg73t8LHfUA5a95TWiM1J
4GftBho6JL/7abDky8QXOX9fhwJxrXqtP87dChEdo
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why the exponent 3 error happened:
James A. Donald wrote: -- James A. Donald wrote: Code is going wrong because ASN.1 can contain complicated malicious information to cause code to go wrong. If we do not have that information, or simply ignore it, no problem. Ben Laurie wrote: This is incorrect. The simple form of the attack is exactly as described above - implementations ignore extraneous data after the hash. This extraneous data is _not_ part of the ASN.1 data. But it is only extraneous because ASN.1 *says* it is extraneous. If you ignore the ASN.1 stuff, treat it as just arbitrary padding, you will not get this problem. You will look at the rightmost part of the data, the low order part of the data, for the hash, and lo, the hash will be wrong! If you ignore the ASN.1 stuff then you won't know what hash to calculate. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Why the exponent 3 error happened:
-- James A. Donald wrote: Code is going wrong because ASN.1 can contain complicated malicious information to cause code to go wrong. If we do not have that information, or simply ignore it, no problem. Ben Laurie wrote: This is incorrect. The simple form of the attack is exactly as described above - implementations ignore extraneous data after the hash. This extraneous data is _not_ part of the ASN.1 data. James A. Donald wrote: But it is only extraneous because ASN.1 *says* it is extraneous. If you ignore the ASN.1 stuff, treat it as just arbitrary padding, you will not get this problem. You will look at the rightmost part of the data, the low order part of the data, for the hash, and lo, the hash will be wrong! Ben Laurie wrote: If you ignore the ASN.1 stuff then you won't know what hash to calculate. If true, irrelevant. If true, it would merely imply that they should not have used ASN.1 to represent the hash type. But in fact it is not true. I suspect a lot of implementations decide the hash type by looking for particular byte values at particular fixed locations, rather than by deciphering the data as ASN.1. To repeat my argument: A program can only correctly handle a small number of fixed data layouts, but ASN.1 can express an infinite variety of layouts, giving great scope for malicious data. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG bUm91GJmI9zp9B7QNyHcQVSy/PJPz6xQb/PIepFe 47yymkER8iV/Dv/2S5EmJ4XMufQI8aDE8j3ZF80nl - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
