On 2006-09-28, Leichter, Jerry wrote:
> VMS has for years had a simple CHECKSUM command, which had a variant,
> CHECKSUM/IMAGE, applicable only to executable image files. It knew
> enough about the syntax of executables to skip over irrelevant metadata
> like link date and time. (The checksums c
| > VMS has for years had a simple CHECKSUM command, which had a
| > variant, CHECKSUM/IMAGE, applicable only to executable image files.
| > It knew enough about the syntax of executables to skip over
| > irrelevant metadata like link date and time. (The checksums
| > computed weren't cryptographi
At 14:33 -0400 2006/09/28, Leichter, Jerry wrote:
|
VMS has for years had a simple CHECKSUM command, which had a variant,
CHECKSUM/IMAGE, applicable only to executable image files. It knew
enough about the syntax of executables to skip over irrelevant metadata
like link date and time. (The che
| > *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.
|
| You know, this sort of reminds me of a problem with signatures on
| tar.gz files. B
On 9/26/06, Richard Salz <[EMAIL PROTECTED]> wrote:
Really, what? There are things it doesn't do, but since it's only a
packaging format that's a good thing.
Though there are unshar tools, typically people run it as input to /bin/sh,
usually without reading through it (and given the level of o
> From a security point of view, shar has obvious
> problems :-)
Really, what? There are things it doesn't do, but since it's only a
packaging format that's a good thing.
/r$
--
STSM, Senior Security Architect
SOA Appliances
Application Integration Middleware
On 9/15/06, Taral <[EMAIL PROTECTED]> 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.
You know, this sort of reminds me of a problem with
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
> > 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
--
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
> > 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
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
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
--
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
> optional parameters on a signature would cause that
> signature to fai
David Shaw <[EMAIL PROTECTED]> writes:
>RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff, which
>nicely cuts down on ambiguity.
Ah, OK, and it uses the NULL-parameters interpretation (section 5.2.2), which
would actually be incorrect according to the current standards but at lea
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.
*That* is the Right Way
On Sat, Sep 16, 2006 at 05:35:27AM +1200, Peter Gutmann wrote:
> David Shaw <[EMAIL PROTECTED]> writes:
>
> >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.
>
> How d
David Shaw <[EMAIL PROTECTED]> writes:
>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.
How does it handle the NULL vs.optional parameters ambiguity?
Peter.
---
On Fri, Sep 15, 2006 at 08:49:31PM +1200, Peter Gutmann wrote:
> When I fired up Firefox a few minutes ago it told me that there was
> a new update available to fix security problems. I thought, "Hmm, I
> wonder what that would be...". It's interesting to note that we now
> have fixes for many o
21 matches
Mail list logo
