fast or slow crypto?

[Dewayne Geraghty]

Thank-you for engaging us John-Mark.  If you're referring to:

geli:
In our case, there are no-local users, and we provide customers with
jailed environments where the disks are stratified, so only those
elements that need encryption get it, and the algorithm is chosen
depending on the criticality of the data in concert with the client. 
For these fast would be fine.

Side-channel attacks should (and are) considered in our solution, should
there be a backdoor or other nefarious scenario via the application;
this is somewhat mitigated by tedious (monitoring, hacking, source
review) processes (notwithstanding coding obscurity).  So they shouldn't
be entirely discounted ;)

ipsec:
Less of an issue as some of the ikev2 clients (eg Windows, badly)
constrain the options.  And between FreeBSD machines aes-xts is adequate.

gssd:
Unfortunately we don't use nfs on client servers.
---
If the granularity of choice is via a global sysctl, then, in our
scenario fast with the knowledge that side-channel may occur is
preferable to slow and risking the loss of clients, who are always
benchmarking us, which we welcome, and hence FreeBSD.

My $0.02
Dewayne.