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

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 majordomometzdowd.com

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 majordomometzdowd.com

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 majordomometzdowd.com

David Shaw <dshawjabberwocky.com> 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 majordomometzdowd.com

On Sat, Sep 16, 2006 at 05:35:27AM +1200, Peter Gutmann
wrote:
> David Shaw <dshawjabberwocky.com> 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 majordomometzdowd.com

On 9/15/06, David Shaw <dshawjabberwocky.com> 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 <taralxgmail.com>
"You can't prove anything."
    -- Gödel's Incompetence Theorem

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

David Shaw <dshawjabberwocky.com> 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 majordomometzdowd.com

     --
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 majordomometzdowd.com

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://ww
w.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.g
arlic.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
h
ttp://www.garlic.com/~lynn/subpubkey.html#certless

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

> 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 majordomometzdowd.com