I was actually going to file a ticket somewhere and never got around to
it...

In BoringSSL, we've instead gone the route of removing BN_FLG_CONSTTIME
altogether. Rather call sites which need a particular function call that
function directly. I think this is much less error-prone (as the various
problems here show). Of course, OpenSSL can't fully get rid of
BN_FLG_CONSTTIME until 1.2.0, but it could arrange for the library to no
longer rely on it internally.

In a crypto library, "modular exponentiation" is not a complete API
contract. Rather, you need contracts like "modular exponentiation with
secret fully-reduced base and public exponent" or "modular exponentiation
with secret fully-reduced base and secret exponent publicly bounded by
such-and-such". Cast in that light, I think it becomes much clearer that
they should be separate functions. You could even imagine embedding secrecy
into the type (either for safety or to take advantage of some future
compiler annotations), in which case separate functions is necessary.

This also aligns with the guidelines here:
https://github.com/HACS-workshop/spectre-mitigations/blob/master/crypto_guidelines.md#2-avoid-indirect-branches-in-constant-time-code

On Mon, Apr 16, 2018 at 1:09 PM Salz, Rich <rs...@akamai.com> wrote:

> I think this is a great idea, but that it is way too late for this
> release.  We really should be concentrating on testing and fixes, and open
> PR's and other release criteria.  Ideally the release goes out in a month
> (IETF RFC editor willing)
>
> _______________________________________________
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to