Correct method to generate a Curve25519 keypair

[Alexander Lyon]

You are correct that it is not required, but when you don't specify it, it adds in anyways. I have successfully managed to get curve25519 diffie-hellman to work, which you can observe here:

https://code.videolan.org/GSoC2018/arlyon/vlc/blob/airplay-auth/modules/stream_out/airplay/airplay.c#L911 

You could also look at TestCurveDH for an example usage from a hex string

https://code.videolan.org/GSoC2018/arlyon/vlc/blob/airplay-auth/modules/stream_out/airplay/airplay.c#L2058 

Which successfully passes given the test vectors from RFC7748

https://tools.ietf.org/html/rfc7748#section-5.2

Please note that gcrypt expects the private key in gcry_pk_encrypt to be "backwards" (compared to the RFC) during diffie-hellman which is usually okay because it is stored "backwards" in the sexp. However, to accept the test vectors as they are presented in the specification, it was necessary to have the function accept it the "right" way, which is why the buffer is reversed in the function. gcry_pk_encrypt will output a value "s" which needs to be decompressed and then reversed to give the "correct" shared key.

Alex

> On 18 Jul 2018, at 08:33, Stef Bon <stefbon at gmail.com> wrote:
> 
> 
> 
> Op vr 29 jun. 2018 om 05:09 schreef Alexander Lyon <arlyon at me.com>:
> djb-tweak and comp are necessary to generate the key. I have not found out how to make it work without those flags. In fact, changing comp (compressed) to nocomp causes the program to crash.
> 
> 
> the flag "comp" is not required. See in the tests/t-cv25519.c line +-  176.
> 
> Futher hwo do you create the shared secret k. This is described in https://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt 4.3 Shared secret generation.
> It goes via scalar multiplication of the "other side's public key and the local private key scalar".
> Both are available, but scalar multiplaction of q_s and d_c?
> 
> Stef
> 
>