EC weirdness

[Michael StJohns]

On 7/16/2018 4:42 PM, Adam Petcher wrote:
> I think the reason for the hard-coded curves is largely historical, 
> and I don't know of a security-related reason for it (other than the 
> prevention of insecure parameters). Though it has the additional 
> benefit that it simplifies the interface a lot, because the 
> implementation for a curve is not completely determined by the domain 
> parameters. 

Actually - they are.  An ECGenParameterSpec  (basically a named curve) 
is turned into an ECParameterSpec  (the actual curve and G stuff) which 
is turned into an AlgorithmSpecification of type (SunEC, EC) which 
strangely tries to do a reverse lookup of the parameter spec to get a 
name for the curve.   (That's not exactly it, but its close in spirit).

> The implementation may also need to know which optimized finite field 
> implementation, precomputed tables, etc to use. Looking up all of 
> these things at once can be a lot simpler than trying to specify them 
> over an interface.

Nope - that's not it.  The underlying C code mostly uses generic bignum 
operations on the curve parameters rather than pre-computed things.

My guess is that there were some dependencies on named curves in the EC 
library and the EC related stuff in the PKCS11 library.

>
> I'm trying to figure out if your problem motivates support for 
> arbitrary base points, or if there is another way to get what you 
> want. Is the base point a secret in your scheme? Either way, can you 
> implement your scheme using KeyAgreement (e.g. using the "base point" 
> as the public key and a random integer as the private key)? What if 
> ECDH KeyAgreement supported three-party Diffie-Hellman, or you extract 
> a point from generateSecret()? Would that help?

In the scheme, G' is secret.  This is basically the EC version of 
https://en.wikipedia.org/wiki/SPEKE.  Two key pairs generated on P-256' 
(e.g. same curve params, but with G'), can use ECDH to get to the same 
shared secret.   If your key pair wasn't generated with G', then you 
can't get to the same secret with someone who's key pair was.

This is sort of an IOT experiment - I don't want to have to do an 
explicit authorization via a certificate binding a public key.  I can 
generate a group G', and have all the various devices generate a key 
pair using that G'.   The ability to get a pairwise shared secret with 
another device proves the membership in the group to that other device 
and vice versa.

The problem with using ECDH is that generic ECDH operations throw away 
the Y coordinate.  I can do xG' -> X'  using the SunEC ECDH, but what I 
actually get as a result is the scalar X'.x.

I've been trying to avoid using external libraries, but I'll probably 
end up using the BC point math stuff to make this work.

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.

Later, Mike


>
> On 7/13/2018 9:30 PM, Michael StJohns wrote:
>> Hi -
>>
>> Every so often I run into some rather strange things in the way the 
>> Sun EC classes were built.  Most recently, I was trying to use the 
>> SunEC provider to do a PACE like protocol.  Basically, the idea was 
>> to be able to generate public key points on the P-256 curve, but with 
>> a different base point G (knowledge of G' or having a public key 
>> generated from G' would allow you to do a valid ECDH operation, keys 
>> with disjoint points would not).
>>
>> I was able to generate a normal key pair using ECGenParameterSpec 
>> with a name, so I grabbed the ECParameterSpec from the public key, 
>> made a copy of most of the stuff (curve, cofactor), but substituted 
>> the public point W from the key pair I'd just generated, and passed 
>> that in as G to the new parameter spec.  I tried to initialize the 
>> KPG with my *almost* P-256 spec, and it failed with "unsupported curve".
>>
>> Looking into the code and tracing through 
>> sun.crypto.ec.ECKeyPairGenerator to the native code, I'm once again 
>> surprised that all of the curves are hard coded into the C native 
>> code, rather than being passed in as data from the Java code.
>>
>> Is there a good security reason for hard coding the curves at the C 
>> level that I'm missing?
>>
>> This comes under the heading of unexpected behavior rather than a bug 
>> per se I think.   Although - I'd *really* like to be able to pass a 
>> valid ECParameterSpec in to the generation process and get whatever 
>> keys are appropriate for that curve and base point.
>>
>> Later, Mike
>>
>>
>>
>>
>