103 lines
2.9 KiB
Groff
103 lines
2.9 KiB
Groff
.TH IPSEC_KEYBLOBTOID 3 "25 March 2002"
|
|
.SH NAME
|
|
ipsec keyblobtoid, splitkeytoid \- generate key IDs from RSA keys
|
|
.SH SYNOPSIS
|
|
.B "#include <freeswan.h>
|
|
.sp
|
|
.B "size_t keyblobtoid(const unsigned char *blob,"
|
|
.ti +1c
|
|
.B "size_t bloblen, char *dst, size_t dstlen);"
|
|
.br
|
|
.B "size_t splitkeytoid(const unsigned char *e, size_t elen,"
|
|
.ti +1c
|
|
.B "const unsigned char *m, size_t mlen, char *dst,
|
|
.ti +1c
|
|
.B "size_t dstlen);"
|
|
.SH DESCRIPTION
|
|
.I Keyblobtoid
|
|
and
|
|
.I splitkeytoid
|
|
generate
|
|
key IDs
|
|
from RSA keys,
|
|
for use in messages and reporting,
|
|
writing the result to
|
|
.IR dst .
|
|
A
|
|
.I key ID
|
|
is a short ASCII string identifying a key;
|
|
currently it is just the first nine characters of the base64
|
|
encoding of the RFC 2537/3110 ``byte blob'' representation of the key.
|
|
(Beware that no finite key ID can be collision-proof:
|
|
there is always some small chance of two random keys having the
|
|
same ID.)
|
|
.PP
|
|
.I Keyblobtoid
|
|
generates a key ID from a key which is already in the form of an
|
|
RFC 2537/3110 binary key
|
|
.I blob
|
|
(encoded exponent length, exponent, modulus).
|
|
.PP
|
|
.I Splitkeytoid
|
|
generates a key ID from a key given in the form of a separate
|
|
(binary) exponent
|
|
.I e
|
|
and modulus
|
|
.IR m .
|
|
.PP
|
|
The
|
|
.I dstlen
|
|
parameter of either
|
|
specifies the size of the
|
|
.I dst
|
|
parameter;
|
|
under no circumstances are more than
|
|
.I dstlen
|
|
bytes written to
|
|
.IR dst .
|
|
A result which will not fit is truncated.
|
|
.I Dstlen
|
|
can be zero, in which case
|
|
.I dst
|
|
need not be valid and no result is written,
|
|
but the return value is unaffected;
|
|
in all other cases, the (possibly truncated) result is NUL-terminated.
|
|
The
|
|
.I freeswan.h
|
|
header file defines a constant
|
|
.B KEYID_BUF
|
|
which is the size of a buffer large enough for worst-case results.
|
|
.PP
|
|
Both functions return
|
|
.B 0
|
|
for a failure, and otherwise
|
|
always return the size of buffer which would
|
|
be needed to
|
|
accommodate the full conversion result, including terminating NUL;
|
|
it is the caller's responsibility to check this against the size of
|
|
the provided buffer to determine whether truncation has occurred.
|
|
.P
|
|
With keys generated by
|
|
.IR ipsec_rsasigkey (3),
|
|
the first two base64 digits are always the same,
|
|
and the third carries only about one bit of information.
|
|
It's worse with keys using longer fixed exponents,
|
|
e.g. the 24-bit exponent that's common in X.509 certificates.
|
|
However, being able to relate key IDs to the full
|
|
base64 text form of keys by eye is sufficiently useful that this
|
|
waste of space seems justifiable.
|
|
The choice of nine digits is a compromise between bulk and
|
|
probability of collision.
|
|
.SH SEE ALSO
|
|
RFC 3110,
|
|
\fIRSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)\fR,
|
|
Eastlake, 2001
|
|
(superseding the older but better-known RFC 2537).
|
|
.SH DIAGNOSTICS
|
|
Fatal errors are:
|
|
key too short to supply enough bits to construct a complete key ID
|
|
(almost certainly indicating a garbage key);
|
|
exponent too long for its length to be representable.
|
|
.SH HISTORY
|
|
Written for the FreeS/WAN project by Henry Spencer.
|