Re: A note on vendor reaction speed to the e=3 problem

2006-09-28 Thread Richard Salz
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-28 Thread Travis H.
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-28 Thread Leichter, Jerry
| *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.

Re: A note on vendor reaction speed to the e=3 problem

2006-09-28 Thread Greg Rose
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-28 Thread Greg Black
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-25 Thread Travis H.
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

RE: A note on vendor reaction speed to the e=3 problem

2006-09-18 Thread Whyte, William
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-18 Thread Jack Lloyd
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-17 Thread Anne Lynn Wheeler
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-17 Thread Jon Callas
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-17 Thread David Shaw
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

RE: A note on vendor reaction speed to the e=3 problem

2006-09-17 Thread Whyte, William
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-17 Thread James A. Donald
-- 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:

Re: A note on vendor reaction speed to the e=3 problem

2006-09-17 Thread James A. Donald
-- 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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-16 Thread Taral
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

Re: A note on vendor reaction speed to the e=3 problem

2006-09-16 Thread Peter Gutmann
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 least

Re: A note on vendor reaction speed to the e=3 problem

2006-09-16 Thread James A. Donald
-- 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 fail

A note on vendor reaction speed to the e=3 problem

2006-09-15 Thread Peter Gutmann
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 of the OSS crypto apps (OpenSSL, gpg, Firefox (via NSS, so probably

Re: A note on vendor reaction speed to the e=3 problem

2006-09-15 Thread David Shaw
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 of the

Re: A note on vendor reaction speed to the e=3 problem

2006-09-15 Thread Peter Gutmann
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.

Re: A note on vendor reaction speed to the e=3 problem

2006-09-15 Thread David Shaw
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 does it