size_t keyblobtoid(const unsigned char *blob,
size_t bloblen, char *dst, size_t dstlen);
size_t splitkeytoid(const unsigned char *e, size_t elen,
const unsigned char *m, size_t mlen, char *dst,
size_t dstlen);
Keyblobtoid generates a key ID from a key which is already in the form of an RFC 2537/3110 binary key blob (encoded exponent length, exponent, modulus).
Splitkeytoid generates a key ID from a key given in the form of a separate (binary) exponent e and modulus m.
The dstlen parameter of either specifies the size of the dst parameter; under no circumstances are more than dstlen bytes written to dst. A result which will not fit is truncated. Dstlen can be zero, in which case 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 freeswan.h header file defines a constant KEYID_BUF which is the size of a buffer large enough for worst-case results.
Both functions return 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. With keys generated by 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.