--
David Wagner wrote:
> It seems to me that e=3 is a distraction.  I think
> that these security holes have revealed some more
> fundamental issues here that are independent of the
> value of e you use.
>
> It seems to me that the problems can be attributed to
> two problems: (a) implementation bugs (failures to
> implement the spec faithfully); and (b) ad hoc
> signatures schemes that have never been adequately
> validated. In more detail:
>
>   (a) Any implementation that doesn't check whether
>   there is extra junk left over after the hash digest
>   isn't implementing the PKCS#1.5 standard correctly.
>   That's a bug in the implementation.  Of course, as
>   we know, if you use buggy implementations that fail
>   to implement the specification faithfully, all bets
>   are off
>
>   (b) The discussion of "parameter fields" in PKCS#1.5
>   signatures illustrates a second, orthogonal problem.
>   If your implementation supports appending additional
>   parameter fields of some general structure, then you
>   have not implemented conventional PKCS#1.5
>   signatures as they are usually understood; instead,
>   you have implemented some extension.  That raises a
>   natural question: Why should we think that the
>   extended scheme is still secure?

When a protocol is successful, pretty soon it comes in a
large number of variants, all of which have to coexist -
the original version, several upgraded versions,
different interpretations of the spec, buggy
interpretations of the spec and Microsoft style "embrace
and extend" interpretations of the spec designed to
deliberately hamstring interoperability.

Therefore one generally makes provisions for future
expansion - for additional fields in a record,
additional types of records.   ASN.1, S-expressions, and
XML permit essentially limitless future fields.  That is
dangerously great flexibility.  On the other hand, TCP
format turned out to permit too little flexibility.

GPG's concept of "records" seems to me are reasonable
way of providing future expansion, without requiring the
programmer to handle potentially limitless future
expansion of every possible bit of organized data, a
task at which the programmer is likely to fail.

In general, a communication should tell what program and
version the communication is coming from, so that future
programs can say "oh, I am talking to someone old
fashioned, so must talk in the old fashioned dialect."
(Though for conciseness, this probably should not be in
human readable form, but in some cryptic set of bytes
that are agreed to stand for some particular program.)
It should also be able to specify that it is like some
other program, some program that became a de facto
standard that everyone has to be able to interoperate
with, saying "If you don't recognize me, assume I am
this other program, and it will work well enough".  The
communication should also identify that it is in accord
with some particular standards document (again, probably
with a cryptic set of bytes rather than a verbose url),
so that the recipient knows that this communication
version 1.0 format, or version 1.1, or the emergency
fixed version of version 1.1, though if the standards
document was good enough, which it seldom is, it would
not be necessary for the program to identify itself, or
to reference particular concrete implementations.

But still, we likely need programs that only understand
1.0 format to have some success when they receive 1.1
format, and this is where the expandability of ASN.1 and
the rest is useful - and dangerous.

I would suggest that communication occurs in records
that correspond to database records and to C++ objects,
and that some records be defined with provision for
future expansion, and other records not so defined,
according to the judgment of the people defining the
original protocol.  With ASN.1, XML, and S-expressions,
*everything* has provision for future expansion, which I
suggest is dangerously excessive.

If the 1.0 protocol contains an error, they find that
the 1.1 protocol needs some more fields in the record,
and no provision has been made for future expansion,
then they either define a new type of record replacing
the old, (thereby guaranteeing that 1.0 programs will
fail to interoperate when this new record is used) or
define an additional record supplementing the old, which
the 1.0 programs will ignore, handling only the records
they recognize.

Coming back to the case at hand, we should have had a
signature record that only allowed a one particular kind
of hash, and nothing but the hash, and no future
expansion, then when people realized that was a problem,
that unforeseen new hashes would need to be introduced
over time, they should have then introduced an
incompatible signature record that defined the hash
type, and the hash, and allowed for no future expansion.



    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     /zedskWwjM7YJCe3zo2C7y0GDwUQjP+BN9ayEeww
     4Y0kilizvKF0KpOu7fT86djxwW1ghxrvqfCKm1sKc

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

Reply via email to