On 2013-10-01 14:36, Bill Stewart wrote:
It's the data representations that map them into binary strings that
are a
wretched hive of scum and villainy, particularly because you can't
depend on a
bit string being able to map back into any well-defined ASN.1 object
or even any limited size of ASN.1 object that won't smash your stack
or heap.
The industry's been bitten before by a widely available open source
library
that turned out to be vulnerable to maliciously crafted binary strings
that could be passed around as SNMP traps or other ASN.1-using messages.
Similarly, PGP's most serious security bugs were related to
variable-length binary representations that were trying to steal bits
to maximize data compression at the risk of ambiguity.
Scrounging a few bits here and there just isn't worth it.
This is an inherent problem, not with ASN.1, but with any data
representation that can represent arbitrary data.
The decoder should only be able to decode the data structure it expects,
that its caller knows how to interpret, and intends to interpret.
Anything else should fail immediately. Thus our decoder should have
been compiled from, a data description, rather than being a general
purpose decoder.
Thus sender and receiver should have to agree on the data structure for
any communication to take place, which almost automatically gives us a
highly compressed format.
Conversely, any highly compressed format will tend to require and assume
a known data structure.
The problem is that we do not want, and should not have, the capacity to
send a program an arbitrary data structure, for no one can write a
program that can respond appropriately to an arbitrary data structure.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
