Having a DSA/ECDSA signature which is supposed to be DER encoded as an ASN.1 sequence of $r$ and $s$ (as described in the RFC), and being given some bytes which are "some valid DER encoded ASN.1" || "some extra bytes" – is the correct behavior to error out, or would it be more correct to proceed to attempt to verify just the DER encoded portion of the input (since it's self-delimiting)?

Specifically, I would like to know if there are any implications in relation to cryptographic security.

  • $\begingroup$ Well, what does the RFC say? $\endgroup$
    – pg1989
    Dec 1, 2014 at 17:28
  • 1
    $\begingroup$ So you're asking "Should I accept an ASN.1 with trailing junk? And is this dangerous?" $\endgroup$ Dec 2, 2014 at 11:30

3 Answers 3


It depends. If the entire input itself is within a DER encoded structure, then I would bug out. There is nothing defined for BER, CER or DER that would allow padding of structures within constructed values.

If the input is just followed by additional data or junk bytes then it is up to the protocol or otherwise your discretion if you want to accept the data. There is little harm in proceeding as long as the additional data is not treated as trusted data; discarding the untrusted data is the best option.

For some protocols it has some merit to allow additional data. I've personally seen the following security related reasons to add additional data:

  • zero padding for wrapped keys where the keys are wrapped using CBC (PKCS#11 compliant HSM's often use this)
  • smart cards where the size of each file (transparent EF's) is predetermined

In those cases the value of the length bytes of the first BER TLV structure (or out of band information) determines the actual size of the data. As the signature verification can only succeed if the data size is correct, the data length encoding does not have to be part of the signature itself.

It is recommended to make sure that new protocols do not have to handle spurious bytes. There are instances where spurious information is really dangerous, such as XML digital signatures where an attacker may repeat certain tags or ID's. Beware that the data you use is the data you signed; it should not be possible for an attacker to change the location of the data.

  • $\begingroup$ Sorry, have to agree with thera that there is no explicit standard for handling this, it is up to the protocol. So no clear yes/no answer is possible. Beware that you don't make your verification routines (too) generic; different protocols, different choices. Some duplicate code is OK if the protocols are only identical by chance. $\endgroup$
    – Maarten Bodewes
    Dec 2, 2014 at 14:19

I don't think there's an exact "correct" behaviour in this case. It would be up to the implementation to decide, since the spec is only concerned about the DER encoded portion.

If your implementation parses the input as it moves along only, and doesn't concern itself with the overall size, then it would work fine.

Having said that, I believe the best practice is always to verify input boundaries, and in this case, that would mean the trailing extra bytes should get caught. If they have no business being there, then they shouldn't.

There can be security or crypto implications if there's a bug in the parsing of the input.


Actually you're verifying the encoded part, and take a look at thoose "extra bytes". If they're an arbitrary/optional fields - it's ok to verify just an encoded part because the true purpose of verifying is check the encoding : they're complementary operations, and they alone are referenced to each other. The question you've risen is actually "Are the extra bytes safe/valid/acceptable". And the only answer lays in your data format description. If they're an optional fields - yes, it's ok, just discard them IF THEY APPEARANCE IS REPRODUCEABLE WITH YOUR ENCODING PART. If not, even if they are valid optional fields you're not adding - flag it as error even if your verification process is OK.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.