From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Sonntag, 17. September 2006 06:01
For another example of just how badly this kind of thing can
be done, look at this code excerpt from Firefox version
1.5.0.7, which is the fixed version. There are two PKCS-1
parsing
As other's have mentioned, I don't believe the small RSA exponent (e = 3)
is to blame in Bleichenbacher's attack.
Indeed, the mathematical problem of computing the cubic root of m modulo
an rsa modulus n, for a *fixed*, arbitrary m, is still considered to be
hard (no one has shown the opposite).
From: Ralf-Philipp Weinmann
[mailto:[EMAIL PROTECTED]
[...]
Unfortunately we only found out that there has been prior art
by Yutaka Oiwa et al. *AFTER* we successfully forged a
certificate using this method (we being Andrei Pyshkin, Erik
Tews and myself).
The certificate we forged
On Sep 20, 2006, at 3:10 PM, Kuehn, Ulrich wrote:
-BEGIN CERTIFICATE-
MIICgzCCAWugAwIBAgIBFzANBgkqhkiG9w0BAQUFADBoMQswCQYDVQQGEwJVUzEl
MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMp
U3RhcmZpZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDYw
On Sep 16, 2006, at 11:31 PM, Eric Young wrote:
This is a question I would not mind having answered; while the
exponent 3 attack works when there are low bits to 'modify', there
has been talk of an attack where the ASN.1 is correctly right
justified (hash is the least significant bytes),
--
imon Josefsson wrote:
Again, there is no problem in ASN.1 or PKCS#1 that is
being exploited here, only an implementation flaw,
even if it is an interesting one.
But why did several people independently implement the
same or similar flaws?
The answer is in Jack Lloyd's post:
I wrote a
Whyte, William [EMAIL PROTECTED] writes:
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
I noticed the exact same code being present in the mozilla 1.7.13 source ... I
wonder what the correct consequence would be? Have us crypto people proof-read
all relevant source code? Better educate developers?
Interestingly the attacker's playground between the 0, 1, 0 and the hash gets
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
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
For another example of just how badly this kind of thing can be done,
look at this code excerpt from Firefox version 1.5.0.7, which is the
fixed version. There are two PKCS-1 parsing functions, one which returns
the hash and its prefix, the other of which is given the hash and asked
whether it
--
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
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
--
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
Victor Duchovni [EMAIL PROTECTED] writes:
This, in my view, has little to do with ASN.1, XML, or other encoding
frameworks. Thorough input validation is not yet routinely and consistently
practiced by most software developers. Software is almost invariably written
to parse formats observed in
On Thu, 14 Sep 2006 17:21:28 -0400, Victor Duchovni
[EMAIL PROTECTED] wrote:
If so, I fear we are learning the wrong lesson, which while valid in
other contexts is not pertinent here. TLS must be flexible enough to
accommodate new algorithms, this means that the data structures being
From http://www.w3.org/2001/tag/doc/leastPower.html :
When designing computer systems, one is often faced with a choice between
using a more or less powerful language for publishing information, for
expressing constraints, or for solving some problem. This finding explores
tradeoffs relating
--
Victor Duchovni wrote:
If so, I fear we are learning the wrong lesson, which
while valid in other contexts is not pertinent here.
TLS must be flexible enough to accommodate new
algorithms, this means that the data structures being
exchanged are malleable, and that implementations must
Steven M. Bellovin [EMAIL PROTECTED] writes:
As for the not compatible with a well-socialized human -- well, maybe -- I
don't think normal people describe themselves as paranoid by profession
Might I refer the reader to http://www.cs.auckland.ac.nz/~pgut001/. I've even
received mail from
James Donald writes:
There is no need, ever, for the RSA signature to encrypt
anything other than a hash, nor will their ever be such
a need. In this case the use of ASN.1 serves absolutely
no purpose whatsoever, other than to create complexity,
bugs, and opportunities for attack. It is
James A. Donald wrote:
--
Greg Rose wrote:
At 19:02 +1000 2006/09/14, James A. Donald wrote:
Suppose the padding was simply
010101010101010 ... 1010101010101 hash
with all leading zeros in the hash omitted, and four
zero bits showing where the actual hash begins.
Then the error
If so, I fear we are learning the wrong lesson, which
while valid in other contexts is not pertinent here.
TLS must be flexible enough to accommodate new
algorithms, this means that the data structures being
exchanged are malleable, and that implementations must
validate strict
At 19:02 +1000 2006/09/14, James A. Donald wrote:
Suppose the padding was simply
010101010101010 ... 1010101010101 hash
with all leading zeros in the hash omitted, and four
zero bits showing where the actual hash begins.
Then the error would never have been possible.
I beg to differ. A
On Thu, Sep 14, 2006 at 11:25:11AM -0400, [EMAIL PROTECTED] wrote:
James A. Donald writes:
-+---
| snip
|
| ASN.1 provided additional redundant information, making
| possible unexpected data layouts that should not
| normally happen. It had too much expressive
--
Greg Rose wrote:
At 19:02 +1000 2006/09/14, James A. Donald wrote:
Suppose the padding was simply
010101010101010 ... 1010101010101 hash
with all leading zeros in the hash omitted, and four
zero bits showing where the actual hash begins.
Then the error would never have been
25 matches
Mail list logo
