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
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
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
--
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
--
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
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.
"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
> > 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() a
> > > > 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.
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 i
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
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
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
elimina
13 matches
Mail list logo
