On 2/10/13 00:43 AM, James A. Donald wrote:
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.
Right. I see the encoding choice as both integral to any proposal, and
a very strong design decision.
I would fail any proposal that used some form of external library like
ASN.1, XML, JSON, YAML, pb, Thrift, etc, that was clearly not suited for
purpose of security. I would give a thumbs-up to any proposal that
created its own tight custom definition.
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.
This is why I like not using a decoder. My requirement is that I read
exactly what I expect, check it for both syntax & semantics, and move
on. There should be no intervening "lazy compilation" steps to stop the
coder seeing the entire picture.
Another problem with decoders is that you need a language. So that
makes two languages - the primary one and the layout. Oops. Have you
noticed how these languages start off simple and get more and more
complicated, as they try and do what the primary could already do?
The end result is no savings in coding, split sanity & semantics
checking, added complexity and less security. For every element you
need to read, you need a line of code either way you do it, so it may as
well be in the primary language, and then you get the security and the
full checking capability, for free.
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.
Right. To solve this, we would generally know what is to come, and we
would signal that the exact expected thing is coming.
Following-data-identification is the one problem I've not seen an
elegant solution to. Tagging is something that lends itself to some
form of hierarchical or centralised solution. I use a centralised file
with numbers and classes, but there are many possibilities.
If I was to do it, for TLS2, I'd have a single table containing the
mapping of all things. It would be like (off the top of my head):
1 compactInt
2 byteArray
3 bigInt
4 booleans
20 secret key packet
21 hash
22 private key packet
23 public key packet
24 hmac
40 Hello
41 Hiya
42 Go4It
43 DataPacket
44 Teardown
I don't like it, but I've never come across a better solution.
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
