From owner-freebsd-questions@FreeBSD.ORG Thu Jul 26 00:51:00 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BADDA1065670 for ; Thu, 26 Jul 2012 00:51:00 +0000 (UTC) (envelope-from bonomi@mail.r-bonomi.com) Received: from mail.r-bonomi.com (mx-out.r-bonomi.com [204.87.227.120]) by mx1.freebsd.org (Postfix) with ESMTP id 6B7458FC12 for ; Thu, 26 Jul 2012 00:51:00 +0000 (UTC) Received: (from bonomi@localhost) by mail.r-bonomi.com (8.14.4/rdb1) id q6Q0qdss086796 for freebsd-questions@freebsd.org; Wed, 25 Jul 2012 19:52:39 -0500 (CDT) Date: Wed, 25 Jul 2012 19:52:39 -0500 (CDT) From: Robert Bonomi Message-Id: <201207260052.q6Q0qdss086796@mail.r-bonomi.com> To: freebsd-questions@freebsd.org In-Reply-To: Subject: Re: geli - selecting cipher X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 00:51:00 -0000 > From owner-freebsd-questions@freebsd.org Wed Jul 25 14:00:27 2012 > Date: Wed, 25 Jul 2012 20:57:30 +0200 (CEST) > From: Wojciech Puchar > To: freebsd-questions@freebsd.org > Subject: geli - selecting cipher > > i need high speed disk encryption (many disks running in parallel, lots of > data movement). i have processor with AES-NI. > > geli give 150MB/s performance (tested from/to md ramdisk) using default > and recommended AES-XTS > > and ca 400MB/s read and 700MB/s write using AES-CBC. > > I'm not cryptography expert, is CBC somehow "less secure", and if so is it > really a problem? If you "don't know" what strength encryption you need, and/or the difference between the methods, you need to hire a data-security professional to examine your situation and make recommendations appropriate for _your_ needs. 'CBC' -- [C]ypher [B]lock [C]hainig -- is well-suited for strictly -sequential- data access. Try reading the blocks of a large (say 10gB) file in *reverse* order and see what kind of performance you get.