> From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Jeffrey Walton > Sent: Sunday, 20 April, 2014 04:42 > > RSA_print_fp eventually calls ASN1_bn_print (multiple times) with each > of the RSA parameters. ASN1_bn_print is shown below. > > A couple of questions: > > (1) why is the buffer 'buf' required for the function?
Because a big number may be too big to fit in the built-in buffer. > What is its size supposed to be? (I know 'BN_num_bytes(num)' is too small > from a > seg fault, but I don't know how large it needs to be). Big enough. No one has ever claimed the OpenSSL APIs are friendly. If you look at the code below, you'll see that it iterates through buf from 0 or 1 (because it may have incremented the "buf" pointer - per usual, this code is not designed for readability, despite the fact that readability is *critical* for reducing error rates in software) to n-1. n is either the return value from BN_bn2bin, or that value plus 1. Thus the maximum number of bytes used is the return value from BN_bn2bin plus 1. A quick look at BN_bn2bin shows that its return value is the return value of BN_num_bytes. That is actually a macro (defined in bn.h), but I think that answers your question. > (2) why is a non-empty string required for 'number'? Are you asking "why does the code behave as it does", or "why is it designed to require a non-empty string"? As for the former: > (If 'number' is NULL, then the function seg faults. On your platform, perhaps. The code below clearly passes number to one of the printf family of C library functions, where it is used as the argument corresponding to a %s format specifier. Passing a null pointer as the argument for a %s format specifier invokes Undefined Behavior; the implementation is allowed to do anything. Some will helpfully print something like "[null]" or treat it as an empty string. Others will trigger a failure mode. Some may produce nasal demons. > If 'number' is "" or empty, then the function fails. That seems unlikely, given the code, but I haven't bothered testing it. As to the latter question (why was the code designed that way): The OpenSSL APIs are not your friend. They aren't designed to be helpful, but to do whatever specific things need to be done for the functions OpenSSL provides. It's not how I would have designed them, but I haven't written an SSL/TLS implementation, and the OpenSSL developers have, so that's hardly a compelling critique. They do the work; they get to make the decisions. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
