Conceptual feedback on new ECC JEP

[Adam Petcher]

On 9/19/2018 1:37 PM, Bernd Eckenfels wrote:
> Hello,
>
> I think I missed it, but where is the conversion on BigInteger 
> branching on key material? Isn’t this only branching on effective 
> constant values?
>
> Or are you concerned about Spectre-type problems?

This is not for Spectre (etc.) issues, which effectively dump all memory 
contents, so there is nothing we can do to prevent it at this level. The 
proposed implementation defends against cache attacks like 
Flush+Reload[1], as well as timing attacks.

Imagine an EC private key (i.e. a scalar) is stored in a fixed-length 
little-endian byte array in the key implementation class. I can perform 
the required EC operations directly on this byte array without branching 
on any part of its value. Now if I want to convert this key to an 
ECPrivateKeySpec using the KeyFactory, I need to convert this scalar to 
a BigInteger, which uses a variable-length representation. This 
conversion necessarily branches on the value of the private key, which 
we are trying to avoid.

Branching on any non-secret value (including algorithm parameters and 
constants) is fine, but in the example above, we would be branching on 
the valud of the private key.

[1] https://eprint.iacr.org/2013/448.pdf

>
> Besides that I totally agree on the idea of having a more secure 
> implementation which can be activated by simply switching provider 
> priorities.
>
> Gruss
> Bernd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180919/510f886d/attachment.htm>