Date: Thu, 26 Jun 2014 13:20:01 +1000 From: Dewayne Geraghty <dewayne.geraghty@heuristicsystems.com.au> To: freebsd-security@FreeBSD.org Subject: Re: fast or slow crypto? Message-ID: <53AB9161.1000202@heuristicsystems.com.au> In-Reply-To: <20140626014430.GY1560@funkthat.com> References: <20140626012226.GX1560@funkthat.com> <20140626014430.GY1560@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53AB9161.1000202>