1 files changed, 0 insertions, 102 deletions
diff --git a/src/libfreeswan/keyblobtoid.3 b/src/libfreeswan/keyblobtoid.3
deleted file mode 100644
index 8b5bfb0a2..000000000
--- a/src/libfreeswan/keyblobtoid.3
+++ /dev/null
@@ -1,102 +0,0 @@
-.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.