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/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
| *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.
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
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
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
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
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
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
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
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
--
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
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
--
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
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
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 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
19 matches
Mail list logo
