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 would say
--
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) implementation
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
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 does
