Jamie Yukes wrote:
> I wish to take advantage of the distributed PKI found in SSH from my SSL
> applications. Does anybody know the format SSH stores their keys
> in?
In an undocumented format which can and probably will change in the
future. May the source be with you.
There has been some discussions about a utility which exports SSH2
keys to a documented, very simple and more frozen format. The
preliminary specification for this interchangeable key format is
included below. Comments are welcome, especially if they don't suggest
any complications to the format :-)
I guess this ssh2 key export utility could be implemented rather
quickly if there is enough interest. No promises, though.
-----------------8<----------cut here----------8<-----------------
Interchangeable Public Key Format
Timo J. Rinne, Tero Kivinen
May 13, 1999
This document describes a file format that is used to transfer keys of
common public key cryptosystems between different applications.
______________________________________________________________________
Table of Contents
1. Background
2. File Format
3. Key Format
4. Key Type Identifiers
5. Security Considerations
6. Address of Authors
______________________________________________________________________
1. Background
Public key cryptography has many practical security applications in
today's computer systems and networks. Even though there are many
different applications usig public key cryptography, only a few
different public key algorithms are used by these applications.
In some situations it is handy to be able to convert keys from one
system to another. This is important in interoperability testing and
in situations where user do not want to trust key generation mechanism
of some system and want to generate keys for it with a different
system.
To achieve this, we present a simple interchangeable file format that
can be used when keys need to be transferred from one system to
another.
2. File Format
One file can contain one or several keys. Each key is stored on one
or several text lines of the file. Each line is terminated either by
LF character (ASCII value 10) or CR-LF character pair (ASCII values 13
and 10). These newlines can appear in any position within the key and
they are ignored before the key string is parsed.
The key is terminated by empty line (i.e. two LF characters or two CR-
LF pairs). Other empty lines are not allowed within the file. The
last key in the file can also be terminated with end-of-file (EOF).
3. Key Format
Keys are presented as printable ASCII strings. Key string contains
three parts separated by excatly one SPACE character (ASCII value 32).
The first part of the key string is the key type identifier string.
Key type identifier unambiguously defines the public key algorithm>
this key represents and also the type of the key. Key type identifier
string contains only printable 7-bit ASCII characters (ASCII values
33-126).
The second part of the key string is one or several multiple precision
integers separated by excatly one SPACE character (ASCII value 32).
Multiple precision integers are printed in base-10 (decimal) values
without any leading zeroes. If the value of the multiple precision
integer is positive, it is not prefixed. If the value of the multiple
precision integer is negative, it is prefixed by ``-'' character
(ASCII value 45).
The third part of the key is key comment. Key comment is a free form
printable string that can contain also white space. The first
character of the key comment string is the character after the SPACE
character (ASCII value 32) after the last multiple precision integer
of the key. Key comment continues to the end of key string (end of
line).
Key comment part is optional and if no key comment is present, no
SPACE character (ASCII value 32) is needed after the last multiple
precision integer of the key.
4. Key Type Identifiers
Key type identifier unambiguously defines the public key algorithm and
the type of the key. Key type identifiers are basically strings of
free form, but certain guidelines are to be followed when new key type
identifiers are defined.
1) Key type identifier should begin with public key algorithm name
written in lower case ascii characters.
2) Public key algorithm name should be followed by character ``-''
(ASCII value 45).
3) If key type is a private key type, word ``private'' followed by
character ``-'' (ASCII value 45) should appear next in the key type
identifier.
4) Key identifier string should end with the customary abbreviations
of the multiple precision integers forming the key. Abbreviations
should appear in the same order corresponding multiple precision
integers appear in the key string.
Legal key type identifiers are given in the table below.
key number multiple precision integers
identifier of MPIs in the order of appearance
--------------------------------------------------------------------
rsa-ne 2 RSA public modulus N
RSA public exponent E
rsa-private-ned 3 RSA public modulus N
RSA public exponent E
RSA private exponent D
rsa-private-nedpqu 6 RSA public modulus N
RSA public exponent E
RSA private exponent D
RSA secret prime value P
RSA secret prime value Q (P < Q)
RSA parameter U (multiplicative
inverse of P, mod Q)
dsa-pqgy 4 DSA prime P
DSA group order Q
DSA group generator G
DSA public key value Y
dsa-private-pqgyx 4 DSA prime P
DSA group order Q
DSA group generator G
DSA public key value Y
DSA private exponent X
elgamal-pgy 3 Elgamal prime P
Elgamal group generator G
Elgamal public key value Y
elgamal-private-pgyx 3 Elgamal prime P
Elgamal group generator G
Elgamal public key value Y
Elgamal private exponent X
--------------------------------------------------------------------
key number multiple precision integers
identifier of MPIs in the order of appearance
5. Security Considerations
Key export format described in this document is totally insecure as
itself. Keys are not encrypted and if private keys are exported in
this format, it should be done only in secure environment. This
format should only be used when keys need to be transferred from one
system to another so that these systems have different internal key
storage format.
6. Address of Authors
Timo J. Rinne
SSH Communications Security Ltd.
Tekniikantie 12
FIN-02150 ESPOO
Finland
E-mail: [EMAIL PROTECTED]
Tero Kivinen
SSH Communications Security Ltd.
Tekniikantie 12
FIN-02150 ESPOO
Finland
E-mail: [EMAIL PROTECTED]
-----------------8<----------cut here----------8<-----------------
Tomi Kause <[EMAIL PROTECTED]> mob. +358-50-5911 385
SSH Communications Security http://www.ssh.fi/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
