On Fri, Sep 15, 2006 at 09:48:16AM -0400, David Shaw 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.
Botan do
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
--
David Wagner wrote:
> It seems to me that e=3 is a distraction. I think
> that these security holes have revealed some more
> fundamental issues here that are independent of the
> value of e you use.
>
> It seems to me that the problems can be attributed to
> two problems: (a) implementati
On Sat, Sep 16, 2006 at 11:40:55PM -0500, Travis H. wrote:
> This looks mildly interesting:
> http://www.projectblackdog.com/product.html
Yes, a friend lent me one of these to play with a while ago, they're
really quite cool. Lots of interesting possibilities - which was
entirely the point of the
> > Anyway, the attack applies even if you throw away the
> > ASN.1 data.
>
> If you ignore the ASN.1 data you expect the hash to be
> in a fixed byte position, so the attack does not apply.
It's correct that the attack doesn't apply if you expect
the hash to be in a fixed byte position. I woul
