15

How, if at all, do SSH keys differ from asymmetric keys used for other purposes, e.g. email signing?

I'm prompted to ask this, in part, because on OS X, there are apps available to manage SSH keys (ssh-agent, SSHKeychain, etc) as well as apps designed to manage GPG keys (GPG Keychain Access, etc), and apparently ne'er the twain meet. However, I do not believe this is an OS X-specific issue.

Is this separation of concerns because the keys are of quite different kinds, or because they are stored in different places, or is it for some other reason or combination of reasons, e.g. historical reasons?

2 Answers2

16

  • SSH keys are just plain RSA, DSA, or ECDSA asymmetric key pairs. Such a keypair generated by OpenSSH can already be used by OpenSSL and most other programs.

    (The .pub file output by ssh-keygen is in OpenSSH-specific format, but that is irrelevant since the "private" file already contains both private and public keys.)

    Other SSH software may have their own storage formats, such as RFC 4716 or PuTTY's PPK, but they store the same RSA/DSA/ECDSA information.

  • X.509 (used by SSL, S/MIME) is slightly more complicated: the "private" key is still the same, but instead of a bare public-key file you have a "certificate" – an ASN.1 structure containing the public key, subject and issuer names, validity dates. In X.509 v3 certificates, extensions such as "key usage" and "alternate subject name" will be present. The entire certificate is signed by the issuer's key (or self-signed if there is no separate issuer).

    You can easily use an X.509 "private key" file for SSH – OpenSSH even uses the same format.

    You can create an X.509 certificate from a simple keypair and then self-sign it, or you can create a "certificate request" and submit it to be signed by a CA (certification authority).

    To display the information in an X.509 certificate, use:

     certtool -i < foo.pem
 certtool -i --inder < foo.crt

    openssl x509 -noout -text < foo.pem
 openssl x509 -noout -text -inform der < foo.crt

    (certtool is part of GnuTLS.)

  • OpenPGP (used by GPG) keys are the most complicated. What you call a "PGP key" or "PGP keypair" is a complex structure called an "OpenPGP certificate", containing:

    • one "primary key" – an asymmetric key pair, usually used for signing
    • one or more "user IDs" – textual labels, usually in the form of "Name <email@address>"
      • at least one of them is marked as "primary user ID"
      • for each user ID, a "self-signature" – signature by your own primary key
      • for each user ID, zero or more "signatures" by other users
      • the self-signature packets also contain your preferred algorithms (SHA-1, AES, etc.)
    • one or more "subkeys" – additional key pairs, the first is usually for encryption
      • for each subkey, a signature by the primary key
    • zero or more "photo IDs" – JPEG or PNG attachments containing your face
      • signed the same way as user IDs
    • zero or more X.509 certificates

    All keypairs have expiration dates and usage bits: sign data, certify (sign) keys, encrypt, authenticate to services. The primary key by default has "sign" and "certify" bits and the first subkey is to "encrypt". If you add an "authentication" subkey, you can use it through gpg-agent for SSH authentication.

    To see what your certificate contains:

     gpg --export joe@example.com | gpg -vv

    gpg --export joe@example.com | certtool --pgp-certificate-info

    (certtool is part of GnuTLS.)

X.509 certificates and their associated private keys come in several formats:

  • DER is a binary encoding of an ASN.1 structure of the certificate. Such files usually have .crt or .cer file name extensions (.der is less common but not unseen).

  • "PEM" format files contain the same DER-encoded data, but additionally encoded using Base64 and between "BEGIN THIS" and "END THAT" headers. A common filename extension is .pem, although both .crt and .cer are sometimes used here too (but never .der).

  • For private keys belonging to the certificates, "PEM" format is usually used – Base64 surrounded by headers "BEGIN PRIVATE KEY" (key in a PKCS#7 structure) or "BEGIN RSA (or DSA) PRIVATE KEY" (bare key, OpenSSL format). Sometimes the key is in a separate .key file, sometimes it's bundled with the certificate.

  • PKCS#12 and the slightly older PFX are encrypted containers storing both the certificate and the private key (often the issuer's certificate too). This format is used by most software when exporting or "backing up" certificates with private keys.

A less confusing situation is in OpenPGP: all data follows the same binary format, and is optionally "armored" (encoded with Radix64 and between PEM-like headers).

Community
  • 1
grawity
  • 501,077
2

Stored in different places and in different formats (the formats used by PGP, GnuPG, ssh, and several different X.509 formats, among others, are quite different). It is possible to transcode between them to some extent by mixing and matching the right options to ssh-keygen, pgp, gpg/gpg2, openssl, etc.; but in general it's not worth the effort. Also, different key formats support different amounts of information, with ssh carrying the least extra information and X.509 PEM and DER formats carrying the most. Additionally, the OSX Keychain is simply encrypted key/value storage, so a different mechanism is generally needed by each application to convert between the program's native key + metadata format and something that can be stored in the Keychain. (Similar concerns apply to the KDE wallet and GNOME keychain.)

geekosaur
  • 12,091