[Cryptography] Is ASN.1 still the thing?

Nico Williams nico at cryptonector.com
Mon Nov 13 21:30:17 EST 2017


On Mon, Nov 13, 2017 at 01:11:39PM +1000, James A. Donald wrote:
> Do JSON, Yaml, or protobuff allow representing data format in ways that give
> a unique and well defined checksum, that will not be affected by endianess
> or compiler options?

Protocol buffers is remarkably similar to... ASN.1 w/ DER rules.  Makes
one wonder why even bother building a new thing that's not new at all :(

But then, there's been nothing new since S-expressions...  And nothing
new since ASN.1, and nothing new since BER/PER/XER.  And yet there's
always one more of these wheel reinvention events around the corner.

The big problem with ASN.1 for many, many years was the lack of access
to the standard, and the lack of tools.  If you want to reinvent this
wheel because of that _now_, well, please don't: you'll be building
tools that don't exist for your wheel, when you could be using off-the-
shelf ones, or building new ones, for ASN.1/whatever.

> Cryptographers specify data formats are in ASN.1 because that way you can
> get a unique hash or checksum of the data, regardless of which compiler you
> are using, and whether your machine is big endian or little endian.

Well, no, ASN.1 itself does not do that.  DER (and CER) -- encoding
rules for ASN.1 -- do, but not all encoding rules do.

In any case, we've learned not to depend on canonical encodings, so
canonical encodings are neither here nor there.  We just don't build
protocols/applications that require repeatable canonical encodings.

If you ever see a proposal that would need canonical encodings, well,
you can inform its authors of just how wrong they are (unless there's
something truly new and they aren't).

(You'll notice that we said no to canonical JSON.  It's just one huge,
low-reward rathole.)

> But these days everyone seems to be using JSON to represent data in transit,
> because that is the language of the web and of node.js, or YAML, which is
> JSON polished up to support more kinds of data and to actually be genuinely
> human readable, or protobuff, because people who write in C++ despise the
> horrible inefficiency of translating data to and from ascii representation.

It's perfectly possible to produce JER -- JSON Encoding Rules for ASN.1.
I'm sure someone's done it...  I'd rather nothing think about YER
though.

The big problem with JSON is the need to quote/dequote strings, and lack
of streaming support.  Binary JSON encodings (CBOR, ...) take care of
this.

> ASN.1 provides canonical format so that you can hash it or checksum it,
> ultra efficient binary format for C and C++ purists, and supposedly human
> readable format, though its human readable format is not particularly human
> readable.  You are a lot better off with YAML if, as in ini files, you want
> human readability.

I wouldn't say that DER is particularly efficient.  I mean, it's not,
because it's got all this tagging redundancy, and the variable length
encoding of lengths + definite-length encoding of everything is a nasty
complication.

If you want efficiency, PER is probably your ticket.  You might want a
four-byte aligned variant of PER, aka XDR (seriously, XDR is very close
to that!).

As for human readability... I'd rather use encodings that can be
formatted nicely and which have powerful tooling.  XML has XSLT/XPath --
yeah, XML is super verbose, but XSLT is super convenient.  JSON has jq,
which is as much pithier than XSLT as JSON is than XML (more, actually,
but I may be biased, being a jq maintainer).  But JSON is horrible as
UI, much more so than XML.  I don't really think YAML is right either.

Personally I'd go with SQLite3 (SQL) for application configuration.
This removes the need for any kind of human readable/authorable document
format, and still gives you the power of a declarative programming
language to deal with configuration.  Win-win.

But now we're far, far afield from crypto :(

Nico
-- 


More information about the cryptography mailing list