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


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 obfuscation sh
offers, it's not clear that you couldn't sneak something through even if
the person skims it).
--
Enhance your calm, brother; it's just ones and zeroes.
Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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.  Basically, you have to keep them around so you can
| check the signature, but you can't delete them because you can't
| reconstruct the original tar file from an untarred copy because it's
| full of metadata that won't necessarily be replicated on your system.
| For example, uids and gids.  Unfortunately, cpio appears to be worse.
| From a tape backup standpoint, tar doesn't store enough (extended
| attributes, hard links, etc.) and so it appears to store both too much
| and too little at once.
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 cryptographic
- at least the last time I used it, many years ago.  The command was
created to use in patches to provide a quick verification that the file
being patched was the right one.)  I've always found it surprising
that no one seems to have developed similar tools for Unix - with the
Gnu libraries for portable access to object/ executable files, it could
be done relatively easily.

The general issue here is how to checksum the information, rather than
the raw data.  XML signatures have horrendous problems with this
because XML has many equivalent ways to say the same thing, and
there is enough information in an XML file for intermediate nodes to
be able to change representation without changing semantics - and for
various reasons, they do so.  (The XML guys try to deal with this by
defining a canonical representation for data, and sign *that*.
Unfortunately, there are two competing standards for the canonical
representation.)
-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 checksums computed weren't cryptographic
- at least the last time I used it, many years ago.  The command was
created to use in patches to provide a quick verification that the file
being patched was the right one.)  I've always found it surprising
that no one seems to have developed similar tools for Unix - with the
Gnu libraries for portable access to object/ executable files, it could
be done relatively easily.


The sum command has existed in Unixes since before VMS existed. 
Checksum has too many characters in the name ;-).


Greg.


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 computed weren't cryptographic
 - at least the last time I used it, many years ago.  The command was
 created to use in patches to provide a quick verification that the file
 being patched was the right one.)  I've always found it surprising
 that no one seems to have developed similar tools for Unix - with the
 Gnu libraries for portable access to object/ executable files, it could
 be done relatively easily.

This is incorrect.  Hundreds of people have developed such tools
and use them regularly.  I've never bothered to look for any
published versions, because my own tool works for me, but I'd be
surprised if there weren't any out there in the wild.

Greg


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 signatures on tar.gz files.
Basically, you have to keep them around so you can check the signature,
but you can't delete them because you can't reconstruct the original tar file
from an untarred copy because it's full of metadata that won't necessarily
be replicated on your system.  For example, uids and gids.  Unfortunately,
cpio appears to be worse.  From a tape backup standpoint, tar doesn't
store enough (extended attributes, hard links, etc.) and so it appears to
store both too much and too little at once.

It would be nice if there was a format other than shar which was deterministic
and only contained the contents of the files; no metadata.  Then we could sign
the code and nothing else.  From a security point of view, shar has obvious
problems :-)  Anyone know of a relevant tool?
--
Enhance your calm, brother; it's just ones and zeroes.
Unix guru for rent or hire -- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 that
it's incorrect that there was no chance of it being screwed 
up in the absence of ASN.1. But I'm happy to agree to
disagree at this point.

William

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 the same thing for (deterministic) encodings - mostly
because I wrote a decoder for PKCS#1 v1.5, realized it probably had
bugs I wouldn't figure out until too late, and this way the worst
thing that can happen is a valid signature is rejected due to having
some unexpected but legal encoding. Default deny and all that.

Anyway, it's a lot easier to write that way - my PSS verification code
is probably around twice the length of the PSS generation code, due to
the need to check every stupid little thing.

-Jack

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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
eliminated by this process.


FSTC originally created FSML for digitally signed xml encoded data ... which 
was then donated to w3c and became part of xml digital signature specification.

the issue for FSTC was e-checks ... where originator took fields from ACH 
transaction ... encoding them in XML, digitally signed the XML encoding, and then 
appended the signature to the original ACH transaction. the recipient received the ACH 
transaction ... duplicated the original XML encoding process, computed the hash ... and 
then compared it to the decoded signature (from the ACH transaction append field).

the original issue for FSML was that XML didn't have a bit-deterministic 
encoding process ... which could result in the originator and the recipient 
getting different results doing XML encoding of ACH transaction fields.

X9.59 financial transaction specified something similar
http://www.garlic.com/~lynn/x9.59.html#x959

which allowed originator and recipient to perform deterministic encoding of 
standard financial transaction (in manner similar to FSTC e-check process) ... 
where the signature was carried in standard electronic transaction append 
field. the base standard specified ASN.1 encoding ... but the fully constituted 
x9.59 fields included a version field ... the purpose of which included being 
able to specify an x9.59 version that used XML encoding (rather than ASN.1 
encoding).

the standard just specified all the fields and ordering for the encoding.

there were sample mappings between the fields in the standard and fields in 
various
existing financial transactions. if x9.59 called for fields that weren't part of
specific financial transaction ... then those fields needed to be carried in 
the transaction append/addenda, along with the digital signature (i.e. the 
digital signature was appended
to standard transaction in unencoded format, it wasn't required that the 
encoded format
being transmitted ... just that the encoded format could be reproduced in a deterministic manner). 


old write-up giving correspondence between x9.59 fields and some fields from 
some
common financial transaction formats (includes a proposed xml tagged encoding)
http://www.garlic.com/~lynn/8583flow.htm

part of the issue for the x9.59 specification was the requirement for a 
standard that preserved the integrity of the financial infrastructure for all 
retail payments (ALL, including point-of-sale).

A typical point-of-sale payment card transaction avgs. 60-80 bytes. By 
comparison, some of the PKI digital signature based specifications from the 
period had enormous payload bloat resulting in 4k-12k bytes ... aka increasing 
transaction payload size by two orders of magnitude (100 times).
http://www.garlic.com/~lynn/subpubkey.html#x959
http://www.garlic.com/~lynn/subpubkey.html#certless

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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
  optional parameters on a signature would cause that
  signature to fail validation.
 
  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.

That is correct.  OpenPGP passes the hash identification in the
OpenPGP data as well as encoded in ASN.1 for the PKCS-1 structure.
Since there is another source for the information, it is unnecessary
to generate or parse ASN.1.  In the case of GPG specifically (other
implementations may do the same, but I can't say for sure), all ASN.1
data is hardcoded opaque strings.

David

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 sure you've got the right arbitrary padding bits.

Anyway, the attack applies even if you throw away the
ASN.1 data. 

William

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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:
 *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 eliminated by this process.

 I don't think there's anything inherently wrong with
 ASN.1 DER in crypto applications.

If there are no options, you are not using ASN.1 DER.
You are using some random padding bytes that happen to
be equal to ASN.1 DER.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 mMZpx7gaL6S/5STlYWv0A0ZM+HqCZSD2m0ClWjxL
 4UR16e+x3Uv/VW8C0Swxx9XMPtH99PEBNIc6BzpkQ

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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
 qF2+GCfNPchHe4vzSkkYoOEjOI5i/kZtLIlyTUbX
 45tXJAuT/Tj9w0qpg0VFij8GrtY2JXG05fj6YE6M2

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 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
eliminated by this process.

I don't think there's anything inherently wrong with ASN.1 DER in
crypto applications.

--
Taral [EMAIL PROTECTED]
You can't prove anything.
   -- Gödel's Incompetence Theorem

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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
it's unambiguous.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 validation.

 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.

--digsig
 James A. Donald
 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
 KBZXRF1divvJGZ6Zm3lHv3qjnS9Bwhl22NfSlYK3
 4zPRSIE0Q6qUaTtmKPPoKOsPNzAtcdWuthGi5nNTi

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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
Thunderbird as well), my own cryptlib), but nothing from any of the commercial
vendors.  Maybe someone should convert this into a DRM attack so Microsoft
will fix it before 2007 :-).

(The real #*($#*( for me is that I wanted to turn off e=3 years ago, but when
I did it in a snapshot release some squawk piped up to say that they were
using e=3 and the standard said it was OK and I was being non-standards
compliant and so on and so forth, so in the end I had to leave it enabled.  I
did make it very easy to turn off with a single-character code change, but
that may explain why commercial vendors are going to be reluctant to rush out
a fix without a lot of prior impact assessment).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 OSS crypto apps (OpenSSL, gpg, Firefox

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.

David

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


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 handle the NULL vs.optional parameters ambiguity?

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 validation.

RFC-2440 actually gives the exact bytes to use for the ASN.1 stuff,
which nicely cuts down on ambiguity.

David

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]