[Cryptography] Encodings for crypto

Theodore Ts'o tytso at mit.edu
Mon Feb 17 16:46:56 EST 2014


On Mon, Feb 17, 2014 at 01:42:30PM -0500, Phillip Hallam-Baker wrote:
> 
> I think we can do better:
> 
> https://tools.ietf.org/html/draft-hallambaker-jsonbcd-01

Have you looked at RFC 7049?  Paul Hoffman pointed me to it off-list,
like your I-D, it's closely aligned to the JSON model.  There is also
an Apache 2.0 licensed implementation available:

https://code.google.com/p/cbor/

> 1) Read in the bytes, abort if there are too many
> 
> 2) Authenticate the bytes (Nope, I don't believe in canonicalization.)
> 
> 3) Parse the data structure to internal representation, discarding all data
> that is not understood.
> 
> 4) Validate the data for consistency (if possible)
> 
> 5) Pass to the security sensitive module to process.

Sure, as long as people don't assume that (2) doesn't obviate the need
for (4).  Fuzz testing is a really good idea for any input data which
is from a potentially untrusted source.

> Doing authentication at the byte level before parsing is robust and
> insulates the code from parser errors. It is also a good defense against
> injection errors if we enforce a rule that every command is independently
> authenticated and validated.

No, it does **not** insulate the code from parser errors.  It just
means that assuming the attacker hasn't scrubbed your logs after
carrying out a stack overflow attack, you might be able to figure out
from the authenticated identity who was able to carry out an attack
against your parser.  :-)

					- Ted



More information about the cryptography mailing list