On Mon, Jan 04, 2021 at 08:04:15AM +0000, Reshetova, Elena wrote:

quoted

quoted

2. The OCS ECC HW does not support the NIST P-192 curve. We were planning to
   add SW fallback for P-192 in the driver, but the Intel Crypto team
   (which, internally, has to approve any code involving cryptography)
   advised against it, because they consider P-192 weak. As a result, the
   driver is not passing crypto self-tests. Is there any possible solution
   to this? Is it reasonable to change the self-tests to only test the
   curves actually supported by the tested driver? (not fully sure how to do
   that).

An additional reason against the P-192 SW fallback is the fact that it can
potentially trigger unsafe behavior which is not even "visible" to the end user
of the ECC functionality. If I request (by my developer mistake) a P-192
weaker curve from ECC Keem Bay HW driver, it is much safer to return a
"not supported" error that proceed behind my back with a SW code
implementation making me believe that I am actually getting a HW-backed up
functionality (since I don't think there is a way for me to check that I am using
SW fallback).

Sorry, but if you break the Crypto API requirement then your driver
isn't getting merged.

But should not we think what behavior would make sense for good crypto drivers in future?
As cryptography moves forward (especially for the post quantum era), we will have
lengths for all existing algorithms increased (in addition to having a bunch of new ones), 
and we surely should not expect the new generation of HW drivers to implement
the old/weaker lengths, so why there the requirement to support them? It is not a
part of crypto API definition on what bit lengths should be supported, because it
cannot be part of API to begin with since it is always changing parameter (algorithms and attacks
develop all the time). 

Best Regards,
Elena.