Re: Exponent 3 damage spreads...

2006-09-16 Thread James A. Donald

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

2006-09-16 Thread Travis H.

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

2006-09-16 Thread Taral

On 9/15/06, David Shaw [EMAIL PROTECTED] wrote:

GPG was not vulnerable, so no fix was issued.  Incidentally, GPG does
not attempt to parse the PKCS/ASN.1 data at all.  Instead, it
generates a new structure during signature verification and compares
it to the original.


*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. Anything
you don't understand/control that might be variable (e.g. options) is
eliminated by this process.

I don't think there's anything inherently wrong with ASN.1 DER in
crypto applications.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: A note on vendor reaction speed to the e=3 problem

2006-09-16 Thread Peter Gutmann
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:

2006-09-16 Thread James A. Donald

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

2006-09-16 Thread James A. Donald

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

2006-09-16 Thread James A. Donald

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

2006-09-16 Thread Ben Laurie
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:

2006-09-16 Thread James A. Donald

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