2
$\begingroup$

wikipedia says about the keys itself:

The public key consists of the modulus n and the public (or encryption) exponent e. The private key consists of the modulus n and the private (or decryption) exponent d, which must be kept secret.

I know, that public keys look like that in the wild:

-----BEGIN RSA PUBLIC KEY----- MIIBCgKCAQEA+xGZ/wcz9ugFpP07Nspo6U17l0YhFiFpxxU4pTk3Lifz9R3zsIsu ERwta7+fWIfxOo208ett/jhskiVodSEt3QBGh4XBipyWopKwZ93HHaDVZAALi/2A +xTBtWdEo7XGUujKDvC2/aZKukfjpOiUI8AhLAfjmlcD/UZ1QPh0mHsglRNCmpCw mwSXA9VNmhz+PiB+Dml4WWnKW/VHo2ujTXxq7+efMU4H2fny3Se3KYOsFPFGZ1TN QSYlFuShWrHPtiLmUdPoP6CV2mML1tk+l7DIIqXrQhLUKDACeM5roMx0kLhUWB8P +0uj1CNlNN4JRZlC7xFfqiMbFRU9Z4N6YwIDAQAB

-----END RSA PUBLIC KEY-----

or sth like:

   Subject Public Key Info:
       Public Key Algorithm: rsaEncryption
       RSA Public Key: (1024 bit)
           Modulus (1024 bit):
               00:b4:31:98:0a:c4:bc:62:c1:88:aa:dc:b0:c8:bb:
               33:35:19:d5:0c:64:b9:3d:41:b2:96:fc:f3:31:e1:
               66:36:d0:8e:56:12:44:ba:75:eb:e8:1c:9c:5b:66:
               70:33:52:14:c9:ec:4f:91:51:70:39:de:53:85:17:
               16:94:6e:ee:f4:d5:6f:d5:ca:b3:47:5e:1b:0c:7b:
               c5:cc:2b:6b:c1:90:c3:16:31:0d:bf:7a:c7:47:77:
               8f:a0:21:c7:4c:d0:16:65:00:c1:0f:d7:b8:80:e3:
               d2:75:6b:c1:ea:9e:5c:5c:ea:7d:c1:a1:10:bc:b8:
               e8:35:1c:9e:27:52:7e:41:8f

=> My question is, how are those numbers $n$ and $e$ transformed to a keyfile like above?

EDIT: Additionally, i was specifically wondering how the numbers are calculated into a keyfile. I mean, if I had a single really big number, i can imagine the number is easily converted into one of your encoding. But the public key is a combination of $n$ and $e$, and i don't know which combination.

Improve this question
$\endgroup$
1
  • $\begingroup$ That PEM format is used ONLY by OpenSSL, and not by default. It is more common to use an X.509 certificate (your second example) or at least the SubjectPublicKeyInfo part, with PEM type PUBLIC KEY rather than RSA PUBLIC KEY; that combines the actual key with an 'AlgorithmIdentifier' which is the part displayed in your example as Public Key Algorithm: rsaEncryption. And other schemes don't use ASN.1 at all: OpenSSH uses a single-line base64 of an XDR-style format, and PGP uses either binary or base64 of its own PGP-packet format. $\endgroup$
    – dave_thompson_085
    Commented Mar 13, 2016 at 7:32

1 Answer 1

Reset to default
3
$\begingroup$

There are two concepts that are relevant for your question: Base64 encoding and ASN.1 DER encoding.

So, to deal with the most immediate concern, take n and e as the representation of the RSA values stored in a byte array.

Base 64

Given that cryptographic algorithms usually deal with purely binary data (keys, ciphertexts, random values), their representation can lead to communication issues. The most evident: you can't send the key as a string (e.g. via email) because it can be misinterpreted and even reformatted. What is just a random byte of a key could be an EOL character, and parsing can be jeopardized.

Base64 aims to solve all that family of issues by encoding the data using only 64 printable characters. I will not detail here the encoding rules, but, at a cost of roughly 30% of communication overhead, you get rid of encoding issues dependent on the platform. A base 64 string will have only letters, numbers and the symbols "+", "/" and "=".

ASN.1 DER

The Distinguished Encoded Rules define the encoding of certain data types with the format TLV: Type Length Value. Some of the types can be classical (BOOLEAN, INTEGER), some can be understandable (BIT STRING, OCTET STRING, UTF8String, UTCTIme), some are rather specific (OBJECT IDENTIFIER, SEQUENCE, SET) and some are constructions that build over existing data types to build upon.

Unless you're very interested in the details of how it works, I would suggest to avoid the details about the encoding of each data type and use a parser instead. The encoding rules are a bit dark and contribute little to nothing to the understanding of what's built on top. You can, however, Base64-decode the public key you posted and pass the result to a tool like dumpasn1 to see how nested the structure can get.

What you're seeing

Given all the background, I can finally reply to your question. The first key you got is a PEM encoding: a ASN.1 DER structure subsequently Base-64. I have seen the structure below as an equivalent and functional text representation of the same data, but I can't seem to find the right name for that encoding.

UPDATE: It seems I published an incomplete version of my answer. Particularly, I did not include the link to the RFC 3280, which contains the definition of the DER encoding of a RSA public key (page 15). Thanks to @dave_thompson_085 for bringing it up and the useful additional links:

Improve this answer
$\endgroup$
4
  • $\begingroup$ sorry for the confusion. Although your answer addressed part of my question, i meant initially how the two numbers $n$ and $e$ of the public key are combined, so that we can convert it into your mentioned encodings. Anyway, thanks for your answer :) $\endgroup$
    – uuu
    Commented Mar 12, 2016 at 11:32
  • $\begingroup$ Take a look to the IETF link in my response. It's full of nested definitions, but at the end it just stores the data as two ASN.1 DER INTEGER objects (along with a lot of other data, but regarding your point, that's it). Technically, if you didn't care for compatibility nor encoding issues, if you had n=3233n=3233 and e=17e=17 (toy Wikipedia example), you could store them in a comma separated text file as "3233,17". That's it. No weird operations nor darker secrets beyond encoding. $\endgroup$
    – Sergio A. Figueroa
    Commented Mar 12, 2016 at 11:33
  • 1
    $\begingroup$ I don't see any IETF link(s) in your answer. The canonical reference for PEM is tools.ietf.org/html/rfc1421 specifically 4.3.2.4 for the external encoding. AFAICT IETF relies on CCITT/ITU-T standards for ASN.1 and DER, but en.wikipedia.org/wiki/Abstract_Syntax_Notation_One and in more detail en.wikipedia.org/wiki/X.690#BER_encoding are good. RSAPublicKey specifically is in PKCS#1 originally from RSA but more conveniently available as tools.ietf.org/html/rfc3447#appendix-A.1 . $\endgroup$
    – dave_thompson_085
    Commented Mar 13, 2016 at 7:18
  • $\begingroup$ Thank you for your remark. I added your links to the body of the answer. $\endgroup$
    – Sergio A. Figueroa
    Commented Mar 13, 2016 at 11:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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