[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