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.
BER and DER can express an arbitrary data structure - and thus can crash
the program receiving the data, probably causing it to execute
transmitted data as code.
The same, however, is true of every overly general line format. Incoming
data should be parsed as the expected and bounded size data structure,
thus we need something that can generate parsing code from a description
of the data at compile time. We need compile time descriptions of the
data, not run time descriptions, because the program that uses the
incoming data will unavoidably rely on compile time description of the data.
PER, however cannot receive unexpected data structures.
Thus all data should be transmitted as PER, or by a format with the
properties of PER.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
