Re: Accessing Point representation of Ed448 for ECDH implementation

Peter Dettman <[email protected]> Sun, 9 Jun 2019 15:22:29 +0700
Newsgroups gmane.comp.encryption.bouncy-castle.devel
Message-ID <[email protected]>
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);
    }

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.

Regards,
Pete Dettman


On 8/6/19 10:12 pm, Danny van Heumen wrote:
> Hi all,
> 
> First of all, I'm new to the list, so any pointers are welcome.
> 
> I'm currently a happy user of Bouncy Castle for its Ed448
> (RFC8032) implementation. I use this for the otr4j implementation
> (https://github.com/otr4j/otr4j) of OTRv4.
> 
> OTRv4 also specifies an ECDH key type, based on Ed448 Point
> representation. (See
> https://github.com/otrv4/otrv4/blob/master/otrv4.md#generating-ecdh-and-dh-keys.)
> However, it requires a Point multiplication operation. AFAICT, Bouncy
> Castle does not expose its internally used Point type and no methods
> are exposed to perform scalar multiplication on a Point.
> 
> Am I missing something? If not, are there any plans/intentions to
> expose the point representation? If not, are there any recommendations
> you can give me on how I can best tackle this?
> 
> I currently use an amateurisch custom-made Ed448 Point implementation
> which serves to prove that the code functionally works, but I would
> like to get rid of it ASAP.
> 
> Let me know if you need any more information.
> 
> Kind regards,
> Danny
> 
>