Disable strict-DER conformance check that was introduced in a recent release?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Disable strict-DER conformance check that was introduced in a recent release?

Andreas Schildbach
I'm the maintainer of bitcoinj, a Java implementation of the Bitcoin
protocol.

We're in the process of upgrading our BouncyCastle/SpongyCastle
dependency to the latest version 1.56 and have tripped over the recently
introduced check for strict-DER conformance of ASN1 integers.

My first quesion: Is there some way to disable the strictness check?
Surely a lot of users need to deal with already existing signatures (or
other ints) which were created using the lax rules. In our case,
although I think bitcoinj as always created only strict-DER signatures
we have to deal with sigs created by old openssl implementations
(Bitcoin Core was using openssl).

If the strictness check can't be disabled and you don't want to add such
a feature in a future release, what is the best way to work around? We
have an open PR, if you want to take a peek:

https://github.com/bitcoinj/bitcoinj/pull/1390/files

It reads the two ints (for an ECDSA sig) "manually", converts them to
BigIntegers and uses the other ECDSASignature constructor, to work
around the check. Is this a good idea?



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disable strict-DER conformance check that was introduced in a recent release?

David Hook-3

Someone really needs to explain to me why people keep referring to DER when talking about this, there is only one correct way to encode an INTEGER or an ENUMERATED in ASN.1.

The rule now being enforced for INTEGER and ENUMERATED is stated in ISO/IEC 8825-1:2003 (E), Section 8.3, specifically 8.3.2 which says

8.3.2
If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet
and bit 8 of the second octet:
a) shall not all be ones; and
b) shall not all be zero.

There is a version of the standard available at:

https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

This has nothing to do with the DER rules of encoding.

If you download the latest beta from https://www.bouncycastle.org/betas you can now set the system property:

org.bouncycastle.asn1.allow_unsafe_integer

to true, and incorrectly formatted integers will parse (mostly, we've tried to capture the most common errors in it, but it doesn't allow the open door that was previously there).

Regards,

David

On 01/07/17 06:45, Andreas Schildbach wrote:
I'm the maintainer of bitcoinj, a Java implementation of the Bitcoin
protocol.

We're in the process of upgrading our BouncyCastle/SpongyCastle
dependency to the latest version 1.56 and have tripped over the recently
introduced check for strict-DER conformance of ASN1 integers.

My first quesion: Is there some way to disable the strictness check?
Surely a lot of users need to deal with already existing signatures (or
other ints) which were created using the lax rules. In our case,
although I think bitcoinj as always created only strict-DER signatures
we have to deal with sigs created by old openssl implementations
(Bitcoin Core was using openssl).

If the strictness check can't be disabled and you don't want to add such
a feature in a future release, what is the best way to work around? We
have an open PR, if you want to take a peek:

https://github.com/bitcoinj/bitcoinj/pull/1390/files

It reads the two ints (for an ECDSA sig) "manually", converts them to
BigIntegers and uses the other ECDSASignature constructor, to work
around the check. Is this a good idea?





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Disable strict-DER conformance check that was introduced in a recent release?

Andreas Schildbach
On 06/30/2017 11:17 PM, David Hook wrote:

> Someone really needs to explain to me why people keep referring to DER
> when talking about this, there is only one correct way to encode an
> INTEGER or an ENUMERATED in ASN.1.

Thanks for your explanation. The reason is perhaps that with Bitcoin
there is the notion of "strict DER", as opposed to the lax parsing of
OpenSSL pre-1.0.0p and pre-1.0.1k.


Loading...