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.
