EC weirdness

[Adam Petcher]

On 7/19/2018 3:36 PM, Michael StJohns wrote:

> On 7/16/2018 4:42 PM, Adam Petcher wrote:
>> Though it has the additional benefit...
>
> Actually...
>> The implementation may also need...
>
> Nope...

I think that you interpreted my statements a bit more specifically that 
I intended. I was speaking in more general terms about ECC libraries in 
the JDK and elsewhere, because they are all motivated by the same 
forces. You may wan to read what I wrote again so you will more easily 
understand my position below.

>
> In the scheme, G' is secret.  This is basically the EC version of 
> https://en.wikipedia.org/wiki/SPEKE.
<snip>
> I may do a bit more archeology and see whether there are actual 
> dependencies on the build in curve data (e.g. PKCS11).  If not, I may 
> try and provide a patch refactoring out that limitation and doing a 
> more thorough separation of the math from the packaging.
>
I've been seeing a lot of interest in PAKE lately, so it may be 
worthwhile for us to do some work to support common PAKE schemes, 
especially if this support can be provided on top of existing DH 
implementations with small modifications. Though I think SPEKE can be 
implemented in other ways, and I'm still not convinced that this example 
provides enough motivation to support arbitrary base points.

Here are some other approaches you may want to consider:

1) Use three-party Diffie-Hellman. You can view the password as some 
other party for whom nobody knows the private key, but authorized 
parties know the public key. I think this accomplishes the same thing, 
and I find it more agreeable than supporting arbitrary base points in 
KeyPairGenerator. In pseudocode:

PublicKey passwordKey = Hash(password)...
KeyPairGenerator kpg = ...
KeyAgreement ka = ...
KeyPair myPair = ka.generateKeyPair();
ka.init(myPair.getPrivate());
Key keyToBob = ka.doPhase(passwordKey, false);
Key keyFromBob = exchangeWithBob(keyToBob);
ka.doPhase(keyFromBob, true);
byte[] sharedSecret = ka.generateSecret()

Of course, you run into the problem that many DH implementations in the 
JDK only support two-party DH. You could start by seeing if this works 
with the "DiffieHellman" service. Adding support for multi-party DH 
would be trivial for X25519/X448, but may be harder for the older ECC 
implementation.

2) If you are willing to use the JDK 11 early access build, and use an 
internal API, then you can do what you want using X25519/X448 and the 
XECOperations class. It doesn't really allow arbitrary base points, but 
you can freely do scalar-point multiplications. I'm assuming this isn't 
what you want, but let me know if you want more details on how to use 
this class.

3) If there is sufficient demand for it (and someone who is willing to 
implement it), we might want to consider adding a crypto service for 
some standard PAKE scheme.