[Arm-dev] Fwd: Re: Does openssl pick low level interface or high level interface to do encrypt?

Fri Aug 11 12:08:51 UTC 2017
Robert Moskowitz <rgm at htt-consult.com>

How does OpenSSL work on ARM?

Do any arms have hardware crypto?

thanks


-------- Forwarded Message --------
Subject: 	Re: [openssl-users] Does openssl pick low level interface or 
high level interface to do encrypt?
Date: 	Thu, 10 Aug 2017 15:16:09 +0000
From: 	Salz, Rich via openssl-users <openssl-users at openssl.org>
Reply-To: 	Salz, Rich <rsalz at akamai.com>, openssl-users at openssl.org
To: 	openssl-users at openssl.org <openssl-users at openssl.org>



What OpenSSL does is not necessarily obvious.  The INSTALL document 
talks about the no-asm configuration option. Details about what the 
assembler code does in terms of optimization are only available by 
reading the source code comments in the various Perl files that generate 
the assembler, mostly.

On x86, the assembly code uses the CPUID instruction (see the 
OPENSSL_ia32cap.pod manpage) to determine if various instructions (AES, 
SSE, MMX, etc) are available and will use them if so.  For other 
processors, similar tests are performed if at all possible.

I have added this to the FAQ

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz at jabber.at Twitter: RichSalz

*From:*- JinsongJi [mailto:jjsbear at hotmail.com]
*Sent:* Wednesday, August 09, 2017 9:09 AM
*To:* openssl-users at openssl.org
*Subject:* [openssl-users] Does openssl pick low level interface or high 
level interface to do encrypt?

Hi,

For one simple operation: openssl enc -aes-256-cbc -salt -in foo.txt 
-out foo.enc

Does openssl pick classic implementation or AES-NI implementation to do 
this encrypt?

Does any user/application always pick classic implementation for AES 
operation regardless of AES-NI improves speed much?

Is there any document about this interface selection?

Thanks,

Jinsong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/arm-dev/attachments/20170811/eca64715/attachment-0005.html>