From owner-freebsd-geom@FreeBSD.ORG Sat Jan 17 03:36:44 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BAD1054B; Sat, 17 Jan 2015 03:36:44 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CE98C22; Sat, 17 Jan 2015 03:36:44 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id u10so21203176lbd.13; Fri, 16 Jan 2015 19:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:reply-to:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=2iirWMuYglFNywDsavq0dA/4uH+mnIsx+DAk6QGOR7A=; b=VUGf09kdYWyWHrrITfHcNtlO27GwSVQF+nXMgUujxKC6AT3Y0emwsaMbVJKNSJa+NB ZtX3Hh245QiHA1TBrIF7y8GBq2WQs6DrsWCnKI89U8+jFhQ7/XBYcnFLDYy8cN16hlRp 3H5nAtf/MgAZMvkiJt9eHgOT5JQpd9KsG8eQMXk8TJFqicuww/RkAW4mq18X49PXMdDx J0D43j8d8gnig79PMaRX4y9ohW0icAjBYIOmzHaG+5Eq90q2LXRTcC2bt7by6zkv8IB5 BECjE/q3XYP8iLYuCLp8J7xTQDx1M59chwu7YS06hwpZv/QtZzTHRCbmvIdr5v+wwcJD Qygg== X-Received: by 10.152.8.225 with SMTP id u1mr18887079laa.21.1421465802304; Fri, 16 Jan 2015 19:36:42 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:e966:4081:140e:40fe]) by mx.google.com with ESMTPSA id ku11sm1850537lac.32.2015.01.16.19.36.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Jan 2015 19:36:41 -0800 (PST) Message-ID: <54b9d8c9.0bcc980a.4215.5779@mx.google.com> X-Google-Original-Message-ID: <003801d03206$ce9a36b0$6bcea410$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Pawel Jakub Dawidek'" References: <20150114041708.GA3189@reks> <54b601ec.0515980a.0c9c.47e1@mx.google.com> <20150114082019.GA3669@reks> <54b6ae4c.0905990a.6c9c.642e@mx.google.com> <54b6b91b.2aa3700a.3a6c.47b5@mx.google.com> <54B6C6B7.4070407@platinum.linux.pl> <54b709fb.0739700a.2970.ffffa14a@mx.google.com> <20150115150316.GB1190@garage.freebsd.pl> <54b85491.4925980a.17c4.2b00@mx.google.com> <20150116082104.GA1230@garage.freebsd.pl> In-Reply-To: <20150116082104.GA1230@garage.freebsd.pl> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Date: Sat, 17 Jan 2015 06:36:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAxZSXWZ6IrmADnR9qgPKNlGTIWpgAn2jKw Content-Language: ru Cc: freebsd-hackers@freebsd.org, 'freebsd-geom' , 'Adam Nowacki' X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2015 03:36:44 -0000 > > Options I have not so much. > > 1. Drink vodka and use slow AES-XTS :) 2. Use ChaCha GELI private > > patch 3. Write Geom node. > > 4. Look at GBDE. Already looked. Do not like it. > > Cipher = ChaCha/XChaCha > > Hash = Blake2 - https://blake2.net/ > > Key1 = key for cipher > > Key2 = key hor HMAC > > IV = HMAC(Key2, ('plain text data' + 'sector num')) = (8/24 bytes) > > > > IV stored on disk in two tables: main and back up > > 1 GB (4kb sector) require 2097152 / 6291456 bytes per IV table or > > 16777216 for full 512 bit hmac > > > > +: > > 1. optional data integrity verification (authentication) 2. > > cache-timing attack resistant 3. keys can be changed without > > transferring data to other media and minimal risk > > > > -: > > 1. very slow write: it is necessary to calculate the hmac and update > > two tables with IV data 2. slow reading: IV need to get from the > table > > (+ optional hmac calc) 3. the risk of damage IV table on disk > hardware > > problems 4. part of the disk is busy service data (IV tables) > > This would be very hard to implement correctly, because writing the > data and updating your tables are not atomic on disk. How do you handle > the case where you write new data, but your system crash or you have a > power outage before updating the table? > > I came into conclusion that data authentication doesn't belong in the > layer of disk encryption, because of lack of atomicity. GBDE has this > problem and GELI data authentication has similar problem. This problem > is mitigated by ZFS, which is transactional, copy-on-write file system > that never overwrites existing data. I personally use ZFS with SHA256 > checksum on top of GELI. That's why I wrote 2 tables and a very slow write: write IV in the main table, write the data in the sector, IV write back table. After entering key need to check both tables, even if they differ then try to decrypt the data from the sector using both IV thus determine which one is correct and update is not correct IV. It's all like me much less than private patch with ChaCha or slow AES-XTS. I try to make Threefish-XTS there any objections? PS: AMD 5350 AES-XTS-256 1 core = 38781004 bytes/sec 1 core AES-NI = 418601975 bytes/sec 4 core = 143620811 bytes/sec 4 core AES-NI = 652957361 bytes/sec ChaCha8-256-1-core = 243108762 bytes/sec ChaCha8-256-4-core = 544313467 bytes/sec ChaCha12-256-1-core = 197178668 bytes/sec ChaCha12-256-4-core = 480021949 bytes/sec