openssh unix dev - Nov 2015 - Fwd: First steps to add an authenticated key agreement protocol (private branch).

Starting by following Damian Miller's commit
1e1242604eb0fd510fe93f81245c529237ffc513 I have been trying to understand
where precisely to include additional ciphers into my server and client
cipherlists for handshake (this commit is the start of ed25519 support).

I have looked at the diff of myproposal.h and also the 25519 implementation.

I do not see where the implementation is mapped to the canonical name
string so that it can be included in client code (ssh/sshd.c).

Does anyone have experience or a tutorial on the various areas of code that
link key exchange, EVP structs and other function pointer, and the
handshake process all together?

Best,
Ross

On Sat, 7 Nov 2015, Ross Snider wrote:
> Starting by following Damian Miller's commit
> 1e1242604eb0fd510fe93f81245c529237ffc513 I have been trying to
> understand where precisely to include additional ciphers into my
> server and client cipherlists for handshake (this commit is the start
> of ed25519 support).
>
> I have looked at the diff of myproposal.h and also the 25519
> implementation.
>
> I do not see where the implementation is mapped to the canonical name
> string so that it can be included in client code (ssh/sshd.c).
>
> Does anyone have experience or a tutorial on the various areas of code
> that link key exchange, EVP structs and other function pointer, and
> the handshake process all together?
What algorithms are you referring to?

If you mean ciphers, then the name/cipher mapping is done by the
ciphers[] array in ciphers.c.

If you mean key exchange algorithms, then it's more tricky.

The kexalgs[] array in kex.c handles name/number lookup. The client
and server need to implement handlers for each side of the key
exchange, these are setup in sshconnect2.c:ssh_kex2() (client) and
sshd.c:do_ssh2_kex() (server).

For each key exchange method, there is one file containing the
client side of the exchange, another for the server part and one for
shared stuff - usually the exchange hash. For curve25519, these are
kexc25519c.c, kexc25519s.c and kexc25519.c respectively.

An authenticated key exchange sounds like it might be fairly tricky
to implement. What are the keys and how are they managed? What's being
authenticated - server->client or both?

Also, if the AKE does do client->server authentication, then how does
it coexist with the existing authentication system? It would need to
work nicely with multiple authentication, etc.

-d

Thanks you Damien, this will help a lot.

Authenticated key exchange. Yes. It will be tricky. I am going to use a
library with a trusted implementation and just do the 'plumbing'.

The keys unfortunately are in a new format. I am going to start with a very
ugly solution (some base64 serialization) and do not know if I will ever
need to get more serious. If I iterate on this format and move towards
standardization or something, I'll definitely reach out.

Both directions, but the primary application is client->server.

The last question about playing nicely with existing auth is a good
question. I have no idea. I think I will 'hack it on' first and iterate
toward something better.

The name of the cipher is Yuan-Li IBE authenticated key agreement.

Best,
Ross