Not currently on the radar.

this is predicated on doing some perf analysis to make sure it doesn't actually make connection setup worse.  all of which i leave to Grant :).

I can collect data that will show if this helps or hurts performance. Should be able to get started on that this week.  If it hurts, we can close this as "WAI". :)

I'm going to piggyback on this bug since I have some CLs for changing the host keys over, too:
https://chromium-review.googlesource.com/c/538000/
https://chrome-internal-review.googlesource.com/c/401209/

I suspect I am likely measuring this wrong...seems like the "known_host" key needs to be and not the "id" that I use here:

host=root@100.107.3.47 ; time for run in {1..100} ; do ssh -i ~/.ssh/id_ed25519 $host /bin/true; done
real    0m3.185s
user    0m0.484s
sys     0m0.164s


time for run in {1..100} ; do ssh $host /bin/true; done
real    0m2.677s
user    0m0.420s
sys     0m0.188s


time for run in {1..100} ; do ssh -i ~/.ssh/id_ed25519 $host /bin/true; done
real    0m2.683s
user    0m0.428s
sys     0m0.192s

time for run in {1..100} ; do ssh $host /bin/true; done
real    0m2.676s
user    0m0.452s
sys     0m0.196s


The id_ed25519 used above was generated with:
     ssh-keygen -b 2048 -t ed25519

and then scp'd the id_ed25519.pub to $host:/root/.ssh/ so ssh above would work.

I've renamed those files to "id_ed25519-2048".
100.107.3.47 = "kevin" (rk3399 chipset) connected via 100mbit link.

I will rerun this with 512-bit key and using r8152 driver over USB GigE link ("Fenvi" dongle).

Sorry - comment #6 is wrong: 100.107.3.47 is gale ("Google Wifi", ipq4019 with 4 cores @ 700Mhz but full Gige link)

the file on the remote side must be /root/.ssh/authorized_keys, not /root/.ssh/id_xxxx

oh! Doh! I forgot to do that....I pushed the .pub file in order to make it easy to "cat foo.pub >> authorized_keys".

I verified /root/.ssh/authorized_keys contained .pub sections for three keys: ChromeOS test key, my ed25519-512 and my ed25519-2048.  All the times are "within the noise" for any given host regardless key type.

100.107.3.227 == kevin (RK3399)

$ host=root@100.107.3.227 ; time for run in {1..10} ; do ssh $host /bin/true; done

real    0m20.050s
user    0m0.168s
sys     0m0.040s

$ host=root@100.107.3.227 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-512 $host /bin/true; done
real    0m20.046s
user    0m0.164s
sys     0m0.044s

$ host=root@100.107.3.227 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-512 $host /bin/true; done
real    0m19.974s
user    0m0.188s
sys     0m0.020s


$ host=root@100.107.3.227 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-512 $host /bin/true; done
real    0m20.098s
user    0m0.184s
sys     0m0.024s


$ host=root@100.107.3.227 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-2048 $host /bin/true; done
real    0m19.990s
user    0m0.144s
sys     0m0.064s


$ host=root@100.107.3.227 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-2048 $host /bin/true; done
real    0m20.003s
user    0m0.180s
sys     0m0.028s


and to a panther (celeron 1.4Ghz) machine (100.107.2.230)

$ host=root@100.107.2.230 ; time for run in {1..10} ; do ssh $host /bin/true; done
real    0m0.160s
user    0m0.044s
sys     0m0.012s

$ host=root@100.107.2.230 ; time for run in {1..10} ; do ssh $host /bin/true; done
real    0m19.182s
user    0m0.164s
sys     0m0.044s

$ host=root@100.107.2.230 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-512 $host /bin/true; done
real    0m19.151s
user    0m0.172s
sys     0m0.036s

$ host=root@100.107.2.230 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-512 $host /bin/true; done
real    0m19.182s
user    0m0.188s
sys     0m0.020s

$ host=root@100.107.2.230 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-2048 $host /bin/true; done
real    0m19.191s
user    0m0.156s
sys     0m0.052s

$ host=root@100.107.2.230 ; time for run in {1..10} ; do ssh -i ~/.ssh/id_ed25519-2048 $host /bin/true; done
real    0m19.187s
user    0m0.164s
sys     0m0.040s

ok, if runtime performance of rsa-vs-ed25519 for initial auth isn't significant, we can punt on this as it might be a bit of a yak shave to make sure everything is in sync

BTW, I just noticed the first result (real 0.160s for 10 iterations) for panther in comment #10 was with an existing master connection open. The second result for panther (19.182s) is 10x bringing up the master connection.

Well, I've only proven ed25519 won't hurt autotest performance of opening a master SSH connection. I have not proven anything else. If there are other reasons (e.g. client side CPU utilization for data transfer), it might still be worth changing.

In general, due to the wide variance in performance between clients (from the same workstation), my impression is we should be looking at CPU utilization on the client, not the server to determine any benefits.  Especially ARM vs x86 platforms.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/868e94e5d95497f7b712d10e872c73bb795ad003

commit 868e94e5d95497f7b712d10e872c73bb795ad003
Author: Stephen Barber <smbarber@chromium.org>
Date: Mon Jul 10 22:27:26 2017

chromeos-sshd-init: generate and use ed25519 key

ecdsa and ed25519 were dropped when the key generating script was moved
out of the upstart conf and into sshd-pre. But that's okay, because
we can just use rsa and ed25519. Defaulting to ed25519 will hopefully get
us a bit of speed during connection setup, and rsa will serve as a
fallback.

Also update sshd_config to allow ed25519, replacing dsa.

BUG= chromium:734786 
TEST=ssh to DUT; see ed25519 host key used

Change-Id: I55f26ee3f8ebb8ed13651f0322627d7b89e480b6
Reviewed-on: https://chromium-review.googlesource.com/538000
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>

[rename] https://crrev.com/868e94e5d95497f7b712d10e872c73bb795ad003/chromeos-base/chromeos-sshd-init/chromeos-sshd-init-0.0.1-r7.ebuild
[rename] https://crrev.com/868e94e5d95497f7b712d10e872c73bb795ad003/chromeos-base/chromeos-base/chromeos-base-0-r138.ebuild
[modify] https://crrev.com/868e94e5d95497f7b712d10e872c73bb795ad003/chromeos-base/chromeos-base/files/sshd_config
[modify] https://crrev.com/868e94e5d95497f7b712d10e872c73bb795ad003/chromeos-base/chromeos-sshd-init/files/sshd-pre

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chromeos/overlays/project-cheets-private/+/bc5cffd8ed517636960761a3c3a61410dc46d18a

commit bc5cffd8ed517636960761a3c3a61410dc46d18a
Author: Stephen Barber <smbarber@chromium.org>
Date: Tue Jul 11 03:43:25 2017

I believe smbarber's change "fixes" this issue. reassigning to him for credit and marking fixed.