> 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 fun
--
Travis H. wrote:
> Actually, encoding lengths of other fields in a
> protocol is probably the easiest way to introduce a
> remotely-exploitable vulnerability (typically buffer
> overflow). I'm going to have to side with the "no
> redundancy means no inconsistencies possible" argument
> her
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).
Wh
On Sep 20, 2006, at 3:10 PM, Kuehn, Ulrich wrote:
-BEGIN CERTIFICATE-
MIICgzCCAWugAwIBAgIBFzANBgkqhkiG9w0BAQUFADBoMQswCQYDVQQGEwJVUzEl
MCMGA1UEChMcU3RhcmZpZWxkIFRlY2hub2xvZ2llcywgSW5jLjEyMDAGA1UECxMp
U3RhcmZpZWxkIENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDYw
ODE5MTY1MTMwWhcNMDYxMD
> 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
--
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 wrot
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), b
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
bigger
"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
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 mat
> > > > 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.
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
--
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
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
--
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
> exac
> > 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
> > valida
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 beg
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
"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 mai
--
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
>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 t
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
>
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 i
--
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 n
On Thu, Sep 14, 2006 at 11:25:11AM -0400, [EMAIL PROTECTED] wrote:
>
> "James A. Donald" writes:
> -+---
> |
> |
> | ASN.1 provided additional redundant information, making
> | possible unexpected data layouts that should not
> | normally happen. It had too much express
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
"James A. Donald" writes:
-+---
|
|
| ASN.1 provided additional redundant information, making
| possible unexpected data layouts that should not
| normally happen. It had too much expressive power, too
| much flexibility. It could express cases that one does
| not exp
27 matches
Mail list logo
