Re: Accessing Point representation of Ed448 for ECDH implementation

Hi,

Thanks for the pointers. I'll respond in-line.

On Sun, 9 Jun 2019 15:22:29 +0700
Peter Dettman <[email protected]> wrote:

> Hi Danny,
> 
> Please refer to the core implementation class in
> org.bouncycastle.math.ec.rfc8032.Ed448.
> 
> IIUC, the generateECDH() method described in otrv4.md would just be a
> slight adaptation of these methods from Ed448:
> 
>     public static void generatePrivateKey(SecureRandom random, byte[]
> k) {
>         random.nextBytes(k);
>     }
> 
>     public static void generatePublicKey(byte[] sk, int skOff, byte[]
> pk, int pkOff)
>     {
>         Xof d = createXof();
>         byte[] h = new byte[SCALAR_BYTES * 2];
> 
>         d.update(sk, skOff, SECRET_KEY_SIZE);
>         d.doFinal(h, 0, h.length);
> 
>         byte[] s = new byte[SCALAR_BYTES];
>         pruneScalar(h, 0, s);
> 
>         scalarMultBaseEncoded(s, pk, pkOff);
>     }

Agree. I don't see a big problem there, either. That is, given my
limited knowledge. (I found the scalarMultBaseEncoded function before,
and I believe that's just the basepoint scalar multiplication, right?)

> where the 's' value from generatePublicKey has to be recovered as
> our_ecdh.secret and 'pk[pkOff..]' as our_ecdh.public .
> 
> So that would be easy to provide. Unfortunately, generating a shared
> secret is not going to be so easy, because BC currently only supports
> the X448 function (from RFC 7748), implemented on curve448 i.e. the
> Montgomery version of this curve (see
> org.bouncycastle.math.ec.rfc7748.X448).
> 
> There are maps between the curves which *might* allow some sort of
> hack, but the Montgomery X448 implementation is u-coordinate only,
> which probably throws a wrench in that idea.
> 
> X448 key generation is already delegated to Ed448 and X448 shared
> secret calculation is intended to eventually also be delegated, which
> would involve adding to Ed448 exactly the non-basepoint scalar
> multiplication that appears to be needed here; but we do not have it
> yet.

What kind of expectations does Bouncy Castle have for such a scalar
multiplication implementation? What kind of guarantees are required at
minimum?

I'm willing to invest some time into looking into the scalar
multiplication, but I have limited knowledge of such low-level
implementations. I could do a naive one and with help from the community
see if we can improve. Or alternative, if one knows of suitable
reference material, I can try diving into the more complicated
implementations.

Would that be a possibility?

Regards,
Danny