[Question] Future work? Newer ciphers?

[rmenessec]

I've been looking over the project after a long hiatus—I have an upcoming need to provide files securely, over the public Internet, with good performance—and it seems to me that there's something of an elephant in the room.

I don't specialize in cryptography personally (I just support lots of software that uses it), but it seems to me that most projects trying to advance the state of publicly deployed cryptography are rowing hard in the direction of AES-GCM for transit cryptography rather than CTR. Virtually all the defaults I'm looking at, from OpenSSH to Apache (any project) to Postfix to Chrome and Firefox, are weighted completely in favor of AES256-GCM-SHA256/384 at the high end, closely followed by ChaCha20-Poly1305. For example, I'm evaluating the Caddy project to replace Apache and nginx in some areas, and I'm seeing some agreement--and self-promotion--indicating that Caddy has selected the best cutting-edge defaults for HTTPS in general and HTTP/2 in particular. These are their cipher defaults in usage order from first to last.

Getting back to OpenSSH itself, these are the current cipher defaults, also in usage order:

chacha20-poly1305@openssh.com
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com

Clearly, they're targeting higher performance first; probably for the exact reasons that SSH-HPN exists. Still, the discussions I've found place OpenSSH AES256-GCM suites first for security rather than performance.

ECDHE/ECDH is also seeing much higher priority these days, as reflected by Caddy (and Apache, Chrome, Mozilla, and others); I don't know if the kex code concerns SSH-HPN in any way, or performance in general. In terms of actual keys, my testing shows vastly lower session setup lag and better performance overall from switching to ECDSA keys, simply comparing stock OpenSSH to stock OpenSSH, ECDSA vs. RSA keys.

I'm still not clear on the relative merits of the ChaCha20-Poly1305 suites, other than that they're supposed to be very well-suited either to ARM architecture in particular or simply low-power processing in general--or both--and still provide a very acceptable degree of security.

What I'm getting at is: my understanding is that the crown jewel of the HPN patchset--ignoring the 'none' cipher--is the AES-CTR multithreaded code. Actual best-practice deployment appears to be targeting AES-GCM for security instead of CTR in literally every application I can find that uses TLS to communicate or relies on OpenSSL--or GnuTLS or NSS, for that matter.

Would it be relatively simple to adopt the current AES-CTR threading approach to the upstream AES-GCM code? If not, is it otherwise feasible to target AES-GCM? Do you plan to? Same questions for the ChaCha20-Poly1305 suites.

Thanks in advance.

[rapier1]

So is late better than never? I am sorry for never replying. That said, we had no funding and it was difficult to get the time away from my other work to focus on performance issues. The good news is that we now have additional funding from the NSF. I wasn't planning on looking at GCM but I can take a look. As AES_GCM is a counter based cipher we may be able to do something with it but I need to dig into it more.

We are currently working on parallelizing the chacha20 cipher. I expect to have something by the end of the year assuming my other tasks don't get in the way. More information on our plans can be found at https://www.psc.edu/hpn-ssh/community-guide