From owner-freebsd-security@FreeBSD.ORG Thu Jun 26 03:20:20 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 30978D7A for ; Thu, 26 Jun 2014 03:20:20 +0000 (UTC) Received: from nschwmtas04p.mx.bigpond.com (nschwmtas04p.mx.bigpond.com [61.9.189.146]) by mx1.freebsd.org (Postfix) with ESMTP id BC996250C for ; Thu, 26 Jun 2014 03:20:19 +0000 (UTC) Received: from nschwcmgw08p ([61.9.190.168]) by nschwmtas04p.mx.bigpond.com with ESMTP id <20140626032011.OEUD8665.nschwmtas04p.mx.bigpond.com@nschwcmgw08p> for ; Thu, 26 Jun 2014 03:20:11 +0000 Received: from hermes.heuristicsystems.com.au ([121.210.107.100]) by nschwcmgw08p with BigPond Outbound id JrLB1o00p29zwdD01rLBDk; Thu, 26 Jun 2014 03:20:11 +0000 X-Authority-Analysis: v=2.0 cv=F6HVh9dN c=1 sm=1 a=SEJ2iDwVkb98DYvesvueMw==:17 a=JipEcVzqA9wA:10 a=8nJEP1OIZ-IA:10 a=GHIR_BbyAAAA:8 a=7g03L6PLeuXXRPqoltEA:9 a=wPNLvfGTeEIA:10 a=SEJ2iDwVkb98DYvesvueMw==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id s5Q3K1df011002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Jun 2014 13:20:03 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <53AB9161.1000202@heuristicsystems.com.au> Date: Thu, 26 Jun 2014 13:20:01 +1000 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org Subject: Re: fast or slow crypto? References: <20140626012226.GX1560@funkthat.com> <20140626014430.GY1560@funkthat.com> In-Reply-To: <20140626014430.GY1560@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 03:20:20 -0000 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.