[Cryptography] encoding formats should not be committee'ized

Jerry Leichter leichter at lrw.com
Mon Sep 30 23:50:10 EDT 2013

On Sep 30, 2013, at 8:10 PM, James A. Donald wrote:
> We have a complie to generate C code from ASN.1 code
> Google has a compiler to generate C code from protobufs source
> The ASN.1 compiler is open source.  Google's compiler is not.
http://code.google.com/p/protobuf/source/checkout.  BSD 3-clause license.

> Further, google is unhappy that too-clever-code gives too-clever programmers too much power, and has prohibited its employees from ever doing something like protobufs again.
I have no idea what this means.  I can tell you with certainty that all kinds of clever code is being developed and deployed within Google (though I can't give you any details, of course).  Some of it may eventually get described in the open literature; some of it may be open-sourced.

Personally, I have no deep objections to ASN.1 - though much of its complexity has been proved unnecessary by the usage of other, much simpler, approaches, like protobufs.  Still, once you have compiler for it, it doesn't really matter all that much either way.  For crypto algorithms, you're unlikely to want or need the more obscure corners.

Do keep in mind, however, that having just a way to generate C from ASN.1 no longer covers much of the necessary space, as there are now many popular languages that are no C-like.  Some are easy to bind to C libraries (e.g., Python); others are much more difficult (e.g., Java).  For ease of use, you really want generators that produce code well integrated into the target language, no some barely functional glued-together thing.

                                                        -- Jerry

More information about the cryptography mailing list