Thanks for the pointer, I have been meaning to do just that. Here is mine:

You mean like Moody's or Standard and Poor's? Oh, wait...

Larger sensors will always have a noise and sensitivity advantage to smaller sensors: larger surface area == more photon gathering ability. Also, I'm surprised they cite a four-stop improvement; I thought we were within that range of the quantum limit with current sensors already.

If you are randomly generating your passwords and they are of a decent length then you don't really need to do anything. If your passwords contain lower-case letters only (not recommended), but are eight characters long then your million authentication attempts would represent only a 0.0005% chance of success. If you passwords contain numbers and upper-case characters too, then the likelihood is 1000 times less.

Yes. See http://www.openbsd.org/cgi-bin/man.cgi?query=softraid&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

Most of the speed gains for high bandwidth x delay networks have been realised in stock OpenSSH already. HPN still does better on very fast long distance networks though.

You do realise that we implemented quite a few speedups for high bandwidth x delay networks already. The remaining "HPN" patches make marginal difference for most networks, other than the patch to allow deactivation of encryption that we refuse to merge at all.

Faster still (and a better cipher):

ssh -o Compression=no -o Ciphers=arcfour256 -o MACs=umac64@openssh.com ...

The umac-64 MAC is only supported by OpenSSH AFAIK (though the spec is available to anyone else who wants to). It is faster and has a better security guarantee than HMAC-MD5 (and is way faster than HMAC-SHA1).

Quite right, and we have no intention of incorporating x.509 support. X.509 parsing and verification exposes a large amount of attack surface and all of it is, by necessity, pre-authentication too (the type which, if buggy, allows worms). Read Peter Gurmann's X.509 style guide and see if you ever want to go near this horror again. We have actually written our own minimal RSA verification code to avoid the sort of ASN.1 parsing that is necessary to deal with X.509, and it has saved us from at least seven bugs - some probably exploitable for authentication bypass or remote code execution.

Yep, we are a _secure_ shell and we take a mildly patriarchal attitude to adding options that can lead to insecure use of OpenSSH. Note that the actual bottleneck in most cases is not the crypto anyway (at least when using arcfour256 as your cipher) but the MAC, and you wouldn't want to switch that off. We do have a very fast MAC though: umac-64

File a bug, we'll fix it.

Thanks :)

Nope. Not without 3rd party patches anyway.

Use arcfour256 as your cipher and umac-64@openssh.com as your MAC (ssh -oCiphers=arcfour256 -oMACs=umac-64@openssh.com ...). Between these, CPU is usually not the bottleneck anymore.

We don't support the none cipher because "secure networks" often aren't, and there are already tools that are insecure and go fast.

You are doing it wrong; permanently failing on recoverable EINTR and EAGAIN errors. See here for how to do it right.