Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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.
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:
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.
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.
