Problem - Kevin Tafuro

if (!(buf = next = (unsigned char *)malloc(*len))) return 0;
i2d_RSAPublicKey(rsa, &next); /* If we use buf here, return buf; becomes wrong */
return buf;
}
For each basic function in the i2d API, there are two additional functions—implemented
as macros—that output to a FILE object or an OpenSSL BIO object, which is
the library’s generic IO abstraction. * The name of the base function is suffixed with _fp
or _bio as appropriate, and the second argument changes to a FILE or a BIO pointer as
appropriate.
The d2i API converts DER-encoded data to an internal OpenSSLrepresentation. The
functions in this API take three arguments. The first is a pointer to a pointer to the
appropriate OpenSSLobject (for example, an RSA ** instead of the expected RSA *).
The second is a pointer to a pointer to the buffer storing the representation (i.e., a
char ** instead of a char *). The third is the input length of the buffer (a long int).
The first two arguments are pointers to pointers because OpenSSL“advances” your
pointer just as it does in the i2d API.
The return value is a pointer to the object written. However, if the object cannot be
decoded successfully (i.e., if there’s an error in the encoded data stream), a NULL
value will be returned. The first argument may be a NULL value, in which case an
object of the appropriate type is allocated and returned.
Here’s an example of converting an RSA public key from DER format to OpenSSL’s
internal representation:
#include
/* Note that the pointer to the buffer gets copied in. Therefore, when
* d2i_… changes its value, those changes aren't reflected in the caller's copy
* of the pointer.
*/
RSA *DER_decode_RSA_public(unsigned char *buf, long len) {
return d2i_RSAPublicKey(0, &buf, len);
}
As with the i2d interface, all of the functions have macros that allow you to pass in a
FILE or an OpenSSL BIO object, this time so that you may use one as the input
source. Those macros take only two arguments, where the base function takes three.
The first argument is the BIO or FILE pointer from which to read. The second argument
is a pointer to a pointer to the output object (for example, an RSA **). Again,
you can pass in a NULL value for this argument. The len argument is omitted; the
library figures it out for itself. It could have figured it out for itself in the base API,
* There are three exceptions to this rule, having to do with the OpenSSLEVP interface. We don’t discuss (or
even list) the functions here, because we don’t cover the OpenSSLEVP interface (it’s not a very good abstraction
of anything in our opinion). If you do want to look at this interface, it’s covered in the book Network
Security with OpenSSL.
354 | Chapter 7: Public Key Cryptography
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.