Why the exponent 3 error happened:

[Steven M. Bellovin]

On Thu, 14 Sep 2006 17:21:28 -0400, Victor Duchovni
<Victor.Duchovni at MorganStanley.com> wrote:

> 
> If so, I fear we are learning the wrong lesson, which while valid in
> other contexts is not pertinent here. TLS must be flexible enough to
> accommodate new algorithms, this means that the data structures being
> exchanged are malleable, and that implementations must validate strict
> adherence to a specifically defined form for the agreed algorithm,
> but the ability to express other forms cannot be designed out.
> 
> This, in my view, has little to do with ASN.1, XML, or other encoding
> frameworks. Thorough input validation is not yet routinely and
> consistently practiced by most software developers. Software is almost
> invariably written to parse formats observed in practice correctly, and is
> then promptly declared to "work". The skepticism necessary to continually
> question the implicit assumption that the input is well-formed is perhaps
> not compatible with being a well-socialized human. The attackers who ask
> the right questions to break systems and the few developers who write
> truly defensive code are definitely well off the middle of the bell-curve.
> 
> It is not just PKCS#1 or X.509v3 that presents opportunities for crafting
> "interesting" messages. MIME, HTTP, HTML, XML, ... all exhibit similar
> pitfalls. Loosely speaking, this looks like a variant of Goedel's theorem,
> if the protocol is expressive enough it can express problematic assertions.
> 
> We can fine-tune some protocols to remove stupid needless complexity, but
> enough complexity will remain to make the required implementation disciple
> beyond the reach of most software developers (at least as trained today,
> but it is not likely possible to design a training program that will
> a preponderance all strong defensive programmers).

A software testing expert once asked me why even good test groups didn't
find more of the software holes.  I told her it was because the spec said
things like "must accept input up to 4096 bytes" rather than "must accept
input up to 4096 bytes and must detect and reject longer input strings".
I think we're seeing the same thing here -- the spec didn't say "must
reject", so people who coded to the spec fell victim.

As for the "not compatible with a well-socialized human" -- well, maybe --
I don't think normal people describe themselves as "paranoid by
profession"....


		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com