Newer SSL ciphers?

[mntbighker]

I'm looking for the best way to update CentOS6 openSSL to include the newer, faster ciphers. Or if this is even practical. I'm hoping to speed up our rsync backups with something like aes128-gcm.

http://blog.famzah.net/2015/06/26/opens ... date-2015/

I don't suppose there is an RPM somewhere? I would have thought EPEL would have something.

[TrevorH]

It's not practical. Your best bet is to make sure your machine supports aes-ni on the processor and make sure that you use a cipher that enables use of the hardware.

[aks]

Why do you need that specific algorithm? Are you forcing clients to use it?

[mntbighker]

It's not practical. Your best bet is to make sure your machine supports aes-ni on the processor and make sure that you use a cipher that enables use of the hardware.

Opteron on the server end and Xeon on the client end. Both say aes in cpuinfo. How would I determine which SSH cipher would use the hardware accel? It's a standard CentOS6 openssh*. I don't know if I was half asleep last night but there are a bunch of GCM ciphers there.

[mntbighker]

Why do you need that specific algorithm? Are you forcing clients to use it?

I was hoping to force the fastest one for rsync backups. Recent versions removed all the old "fast" ones like ARCFOUR and Blowfish. Given the benchmarks it looks like the GCM ones are faster now anyway.

[TrevorH]

https://rhn.redhat.com/errata/RHEA-2012-0065.html and https://access.redhat.com/documentation ... ngine.html

[mntbighker]

https://rhn.redhat.com/errata/RHEA-2012-0065.html and https://access.redhat.com/documentation ... ngine.html

Cool, so aes-128-ctr is the first on the list in my sshd_config, and it appears to be the fastest too, by far. The question is, how do you determine if hardware accel is being used by rsync/ssh? The CPU on both ends support it.