[openssl-dev] Intent of the private_ wrappers

[Dr. Stephen Henson]

On Tue, Mar 10, 2015, Steve Schefter wrote:

> On 3/10/2015 8:03 PM, Dr. Stephen Henson wrote:
> >On Fri, Mar 06, 2015, Steve Schefter wrote:
> >
> >
> >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.
> 

Well in the case of 1.0.1 the private_ functions call the "normal" algorithms
in OpenSSL itself: i.e. not the validated ones at all. The low level functions
in the fips module being fips_* but as I said an application which calls the
low level APIs is not compliant.

> >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.
> 

Well if the application is to be compliant it cannot use the low level APIs at
all. That's why the block is for accidental usage. If an application decides
to ignore than and bypass the blocking and use the private_* wrappers it's
free to do so with all the non-compliant consequences. 

I just built OpenSSL 1.0.1 from source using the normal build procedure on
Ubuntu Linux 14.04.2 and it *did* make the private_* symbols global in
libcrypto.so for example:

00000000000e2180 T private_AES_set_decrypt_key
00000000000e1eb0 T private_AES_set_encrypt_key

So I'm not sure why they're not global in your case.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org