1IPSEC_KEYBLOBTOID(3) Library Functions Manual IPSEC_KEYBLOBTOID(3)
2
6 ipsec keyblobtoid, splitkeytoid - generate key IDs from RSA keys
7
9 #include <freeswan.h>
10 size_t keyblobtoid(const unsigned char *blob,
12 size_t bloblen, char *dst, size_t dstlen);
13 size_t splitkeytoid(const unsigned char *e, size_t elen,
14 const unsigned char *m, size_t mlen, char *dst,
15 size_t dstlen);
16
18 Keyblobtoid and splitkeytoid generate key IDs from RSA keys, for use in
19 messages and reporting, writing the result to dst. A key ID is a short
20 ASCII string identifying a key; currently it is just the first nine
21 characters of the base64 encoding of the RFC 2537/3110 ``byte blob''
22 representation of the key. (Beware that no finite key ID can be colli‐
23 sion-proof: there is always some small chance of two random keys having
24 the same ID.)
25 Keyblobtoid generates a key ID from a key which is already in the form
27 of an RFC 2537/3110 binary key blob (encoded exponent length, exponent,
28 modulus).
29 Splitkeytoid generates a key ID from a key given in the form of a sepa‐
31 rate (binary) exponent e and modulus m.
32 The dstlen parameter of either specifies the size of the dst parameter;
34 under no circumstances are more than dstlen bytes written to dst. A
35 result which will not fit is truncated. Dstlen can be zero, in which
36 case dst need not be valid and no result is written, but the return
37 value is unaffected; in all other cases, the (possibly truncated)
38 result is NUL-terminated. The freeswan.h header file defines a con‐
39 stant KEYID_BUF which is the size of a buffer large enough for worst-
40 case results.
41 Both functions return 0 for a failure, and otherwise always return the
43 size of buffer which would be needed to accommodate the full conversion
44 result, including terminating NUL; it is the caller's responsibility to
45 check this against the size of the provided buffer to determine whether
46 truncation has occurred.
47 With keys generated by ipsec_rsasigkey(3), the first two base64 digits
49 are always the same, and the third carries only about one bit of infor‐
50 mation. It's worse with keys using longer fixed exponents, e.g. the
51 24-bit exponent that's common in X.509 certificates. However, being
52 able to relate key IDs to the full base64 text form of keys by eye is
53 sufficiently useful that this waste of space seems justifiable. The
54 choice of nine digits is a compromise between bulk and probability of
55 collision.
56
58 RFC 3110, RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS),
59 Eastlake, 2001 (superseding the older but better-known RFC 2537).
60
62 Fatal errors are: key too short to supply enough bits to construct a
63 complete key ID (almost certainly indicating a garbage key); exponent
64 too long for its length to be representable.
65
67 Written for the FreeS/WAN project by Henry Spencer.
68 25 March 2002 IPSEC_KEYBLOBTOID(3)