Browser vendors use ASN.1 encoding for RSA certificates in the TLS protocol. RSA public keys are just a number, so why do we need encode them to something else? That increases the risk of security problems.


Think about this, say my public key is

9821347676528476512348612390874073765227653408545634205496835 (note this is not a valid public key, just randomish typing).

What does that mean? Big or little endian? Hex or decimal? Specifically for RSA, where is $e$, where is $N$? What is this public key authorized to do (encrypt, sign, etc)? Who has signed this key? To whom is the key linked?

While a public RSA key is "just a number" there are a lot of reasons to encode the key in a standard way so that every computer everywhere knows how to understand it, what it is authorized to do, who it belongs to, etc.

  • $\begingroup$ what is big or little endian ? we can always use hex as an standard no need to say. for e and N we can send a text file and let put first line be e second be N. public key authorized to encrypt clien't session key and send it to service provider (just think about it what is SSL for ...). i don't see any reason to send something like javascript which make security problem for user and sadly nobody will block SSL on their side... $\endgroup$ – roger Feb 20 '13 at 18:06
  • 1
    $\begingroup$ @roger, but there is a need to say exactly how things are encoded. For example if I say the answer is 10 what does that mean? If it is in decimal, then it is ten; if it is hex, it is sixteen; binary, two; octal, eight; and so on. Even just saying e is on one line, N is on the next, that is an encoding. Sure if public keys are only ever used to encrypt client session key's fine, but public keys are also used to validate digital signatures, etc. $\endgroup$ – mikeazo Feb 20 '13 at 18:12
  • $\begingroup$ ♦ we can use hex always there is no problem with just using hex as an standard. and for using a text file that first line is e second line is N thats really safe its not an encoding. the reason i hate ASN.1 is that there is already exploits that use ASN.1 to remote code execution! for what we mostly use is just Encrypt for browser SSL. the signature is not very important for us $\endgroup$ – roger Feb 20 '13 at 18:33
  • $\begingroup$ @roger ASN.1 does not allow for arbitrary code execution, it's just a way (which is already used in many other standards!) to unambiguously code data, like a sequence of big integers (as we need to do, among other things). The parsing library can be bad and have bugs, but it's not the encoding that is the problem. Data is just data... And javascript has nothing to do with it. (I don't understand that remark at all) $\endgroup$ – Henno Brandsma Feb 20 '13 at 19:04
  • 1
    $\begingroup$ There are exploits that target buggy implementations of ASN.1, but not ASN.1 itself. In the same way, there are also exploits for XML implementations, but that does not mean that XML is bad. There could be also exploits for you custom hex encoding, no matter how simple. $\endgroup$ – SquareRootOfTwentyThree Feb 27 '13 at 18:53

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.