[Cryptography] Is ASN.1 still the thing?

[Phillip Hallam-Baker]

On Sun, Nov 19, 2017 at 7:12 PM, Howard Chu <hyc at symas.com> wrote:
> Phillip Hallam-Baker wrote:
>>
>> On Sat, Nov 18, 2017 at 2:57 PM, Bill Frantz <frantz at pwpconsult.com>
>> wrote:
>>>
>>> On 11/17/17 at 1:02 PM, nico at cryptonector.com (Nico Williams) wrote:
>>>
>>>> For security protocols this should be a non-issue though: we don't use
>>>> real numbers.  But someone said they were advised to stay away from
>>>> ASN.1 because of this issue when designing SPKI -- that's just nonsense
>>>> :/
>>>
>>>
>>>
>>> It may be nonsense, but Carl Ellison was severely burned by this issue on
>>> a
>>> project before we started developing the SPKI spec. That experience,
>>> along
>>> with the large number of security flaws in ASN.1 implementations, made
>>> him
>>> hate ASN.1. Since he was a principle author of SPKI, we followed his wish
>>> to
>>> avoid ASN.1 like the plague. That's the history.
>>
>>
>> ASN.1 DER is unsafe and ASN.1 BER can be unsafe.
>>
>> The issue is simple: Some people are unable to write secure code. If
>> you use an encoding that makes it more likely such people will write
>> an incorrect implementation that leads to buffer overrun errors then
>> that is your fault.
>>
>> Specifically, the issues that occur are of the form
>>
>> LengthA:{LengthB:{Data}, LenghtC:{Data}}
>>
>> It turns out that in many implementations of IPv6, ASN.1, JPEG, etc,
>> it is possible to cause a buffer overrun by creating such as structure
>> with LengthB > LengthA.
>>
>> Checking to get this right is time consuming and difficult to get
>> right. A crap ASN.1 decoder can be done in a week, a really good one
>> with every possible corner case is enormous and might take a year. So
>> just don't use ASN.1 it is utterly awful.
>
>
> Sorry this is just stupid. Reliable BER/DER decoding has been a solved
> problem for a couple of decades by now.
>
> Enormous?
>
> libraries/liblber> size .libs/liblber.so
>    text    data     bss     dec     hex filename
>   54202    1680     136   56018    dad2 .libs/liblber.so

Well it isn't managed code for a start. So I would have to have
someone audit it. And that is serious money to do it right.

The issue is not whether the code is reliable, it is whether it
responds correctly and securely when presented with a malicious input.
And unless the code is written in a language that has built in bounds
checking, I cannot trust it no matter how much it has been used
because these issues keep being uncovered decades after code was
shipped.

I have written four ASN.1 decoders or encoders over the years. I am
very familiar with the scheme and that is why I simply don't use it
for any new work.