[Cryptography] [FORGED] Re: Is ASN.1 still the thing?

[Chu Ka-cheong]

On Wed, Nov 15, 2017 at 6:00 AM, Nico Williams <nico at cryptonector.com> wrote:
>
> DER sucks because it's a definite-length encoding with variable-sized
> lengths, which means that before you can encode your data structure you
> must compute the encoded size, or alternatively that you must traverse
> the structure in post-order to encode it from the end and realloc
> buffers as you go.  Either way sucks, though if you have a compiler and
> run-time then the only thing you'll observe is that encoding is
> not-online (though decoding is).
>
> BER doesn't have this problem in that you can choose either indefinite-
> length encoding or to not minimize the encodings of lengths.  And if you
> choose indefinite-length encoding then BER is online for encoding.
>
> PER is as good as it gets, even today, with the only tunable of interest
> being its alignment (which is 1-octet, but it would probably be faster
> with 4-octet alignment).
>
> The only downside to PER -- the reason we don't use it universally -- is
> that you really do need tools that can compile a complete ASN.1 module,
> and these did not exist for a long time, not as open source code
> anyways.  Of course, the situation is better now, but it's too late.
> Though it's never too late to say NO to new encodings.
>

When protobuf first released, it's main feature is the
interoperability between different iterations of the same protocol.

Consider you have a message like this at the beginning?

struct People {
  name: String
  address: String
}

With ASN.1 you would probably encode it as a SEQUENCE. However, how
would you specify it if you know you will likely add new fields to it
in a V2 release maybe a week later?

struct People {
  name: String
  address: String
  first_name: String
  last_name: String
}

If the fields are added to the SEQUENCE, V1 and V2 of the same program
will not be able to talk to each other. You may define a new message
type and use tagging and union type to allow them to coexist, but what
if you need to do it frequently in a 2 weeks release cycle?

Why bother if protobuf can handle it without boilerplate?

message People
  string name = 1;
  string address = 2;
}

You just need to new fields to the message with unique id. V2 will
still be able to read message from V1 without manual conversion.

Some may say the protocol should be well designed and it shouldn't be
changed arbitrarily. It may be true for a internet protocol, but it is
not the case for the communications between different systems within
the same company, which is the primary use case for protobuf and those
newer encoding schemes.