4 ms·
It shouldn't be possible to manipulate the ASN.1. The answer to your first question should be no, to the second yes. See this brand-new paper which briefly dis
by ondhbcjg 4y ago
It shouldn't be possible to manipulate the ASN.1. The answer to your first question should be no, to the second yes.
See this brand-new paper which briefly discusses the desired property of "non-malleability": https://www.fstar-lang.org/papers/asn1star.pdf https://www.fstar-lang.org/papers/asn1star.pdf
"DER are designed to ensure that every value of a given ASN.1 type has a distinct, canonical wire format representation. That is, DER formats are intended to be unambiguous and non-malleable, in the sense that given a bit string b that encodes a value v, every parser will yield back o, whereas changing any bit in b either produces an invalid representation or yields a distinct value o' + v. These properties are particularly important in security applications, inasmuch as they depend on values u but apply cryptographic protection only on binary formats b."
- layer8 4y agoThis is incorrect. The properties of DER you cite do not prevent changing parts of an RSAPrivateKey structure (i.e. replacing o by an arbitrary o' is perfectly possible). The properties only prevent two different DER structures from representing the same value. It is possible to have an RSAPrivateKey structure where the privateExponent field is inconsistent with the exponent1/exponent2 fields, effectively representing two different private keys, and where one library uses the one and another uses the other. However, that just means that only one of the two would work with the given public key. That can be exploited only insofar as it will break interoperability depending on which library is used. In addition, an attacker would need access to the private key in order to create the inconsistent values, or would need to install a key creation software producing such inconsistent values, in which case the attacker probably can already do much worse.
- jesprenj 4y agoActually my question was poorly stated. I meant to ask what the parent comment understood, but the grandparent comment understood my question in a different way - on the ASN.1 level and not on the crypto level, like issues with different parsings of same weird XML documents.