[openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

[Loic Etienne via RT]

1) Openssl works correctly (no crash, correct detection), as far as I can judge. By error-prone I mean, very defensively, that I (or others) could make a mistake, or that future versions of openssl could not work exactly the same way.


2) I would agree with your argumentation. But some customers want this anti-feature (no aes-ni), arguing that exactly those instruction are not trustworthy. And the customer is always right.


There are already two similar options (which inspired the suggested no-hw-aes): no-hw, no-engines. But none of them excludes aes instructions, which is a bit misleading. Perhaps the documentation could be more explicit about that.


no-asm is a possibility, indeed. At the price of the bit-slicing aes implementation and perhaps of some performance. A trade-off.


But I understand that openssl cannot consider each and every wish. Such a no-hw-aes configuration option may be useful (at least for selling) to many other people, or not. Up to your judgment.


Thanks for your attention anyway.


________________________________
From: Andy Polyakov via RT <rt at openssl.org>
Sent: Friday, June 17, 2016 2:46:41 PM
To: Loic Etienne
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is
> hidden, I still have to try over environment variables, which are not
> as flexible for arm as for x86).
>
>
> Anyway, it would be helpful to exclude hardware aes instructions at
> compile-time:
>
> 1) Runtime checking is error prone (openssl and code using openssl
> evolve)

How is it error-prone? Or more specifically have you ever ran into
situation when it was *detected* incorrectly so that it resulted in
application *crash*?

> 2) Proving to a customer (or convincing myself) that no such
> instructions will ever be used is much easier if such instructions
> are not even compiled

Then why just aes instructions? There is a number of code-paths that are
selected at run-time that are dependent on processor capability
detection. If aes instructions are considered "too fancy", there is no
reason to consider *any* alternative code path as less "fancy".

> I guess that some of the already existing no-xxx configuration
> options have been introduced for similar reasons.

no-asm.

I'd argue that this ticket can be closed.


--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4570
Please log in as guest with password guest if prompted