[openssl-dev] Intent of the private_ wrappers

[Steve Schefter]

On 3/10/2015 8:03 PM, Dr. Stephen Henson wrote:
> On Fri, Mar 06, 2015, Steve Schefter wrote:
>
>> Hi.
>>
>> I am compiling OpenSSL with the FIPS options and seeing a build
>> error. My question is more about the intent than the problem.
>>
>> One example:  When apps/speed.c is compiled with FIPS enabled,
>> OPENSSL_FIPS is defined and DES_set_key_unchecked gets defined to be
>> private_DES_set_key_unchecked.
>>
>> The use of the private_ function means that fips_cipher_abort is not called.
>>
>> Am I correct that the intent is to allow the OpenSSl-provided apps
>> to use the low level APIs (like DES) while user applications linking
>> with libcrypto.so can not?
>>
>> The problem is that the OpenSSL-provided apps also link with that
>> library and the private_ functions are not global (they are not in
>> openssl.ld).  So the OpenSSL-provided apps fail to link.  In the
>> above example, apps/speed.c can't find
>> private_DES_set_key_unchecked().
>>
>> Or am I not understanding the intent?
>>
>
> Which OS and version of OpenSSL are you using?

I am using 1.0.1j on Linux.  I've not tried to build 1.0.2, but I see 
the same use of the private_ wrappers in that code too.

> The intent of the private_ wrappers is to block the accidental use of low
> level APIs in appllications in FIPS mode. In FIPS mode you can only use EVP:
> so if an application did use low level APIs it would not be compliant.

Okay, so that is mostly what I thought I understood.  Except for the 
"accidental" part.  I thought it was to block access altogether.

Unfortunately, the use of the private_ wrappers doesn't work on Linux, 
or at least with my Linux.  If I run "nm" on libcrtypto, the private_ 
functions have a lower case t for the symbol type, meaning that they are 
within the local text (code) section.  They are not global.  So when it 
tries to build the OpenSSL-provided applications, the linker can't find 
the private_ functions.  This results in errors like, "apps/speed.c: 
undefined reference to private_AES_set_encrypt_key".

It would be possible to resolve this by adding the private_ wrappers to 
openssl.ld which would make them global within the library and not 
local.  But I'm not sure if their use should be more discouraged than 
that implies.

Regards,
	Steve