Taral wrote:
*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
This amounts to *not* using ASN.1 - treating the ASN.1
data as mere arbitrary padding bits, devoid of
information content.
That is correct, it has the advantage of being merely a byte string
that denotes a given hash.
Jon
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
On Sat, Sep 16, 2006 at 12:35:08PM +1000, James A. Donald wrote:
--
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
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
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.
Again, not quite right. You have to do a memcmp() and
make
James A. Donald [EMAIL PROTECTED] writes:
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
I wouldn't dispute any of the arguments made in the original or subsequent
posts on this topic pointing out that the programmatic interface to the
device opens a security hole. But I think it needs to be said that this is
only in the environment where trojans, etc., can infiltrate the machine.
--
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.
Taral wrote:
--
Whyte, William wrote:
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.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
Forwarded with permission.
Begin forwarded message:
Date: Fri, 15 Sep 2006 17:17:55 -0700
From: Robert Hulvey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Cfrg] Invitation to review Bluetooth Simple Pairing draft
specification
Hello,
My name is Robert Hulvey and I am a
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
On 9/15/06, Daniel Carosone [EMAIL PROTECTED] wrote:
But let's not also forget that these criticisms apply approximately
equally to smart card deployments with readers that lack a dedicated
pinpad and signing display.
This looks mildly interesting:
http://www.projectblackdog.com/product.html
I
13 matches
Mail list logo
