From owner-freebsd-geom@FreeBSD.ORG Fri Jan 16 00:00:21 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 504B9429; Fri, 16 Jan 2015 00:00:21 +0000 (UTC) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (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 D71F93E7; Fri, 16 Jan 2015 00:00:20 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id hv19so16389655lab.0; Thu, 15 Jan 2015 16:00:19 -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=OT7elAebrdJnXGFb7+knLSTrpkxXuYG7pN3DUyPHMk4=; b=i4TcRX8pcGNSLjBibwl4P25iqAo+9GciVaKFzSLFsX4XmH4JSv1agBDCP/kJ7z8xWH xdrZNSnNkZouWNpBHobJ/OjIyHGJacYVoZbCs9/Tu6n5DkgadMa1buN94HbR+jAEYANP lBATHLROnFFLHJt22owy6HAnCBC4YpEiD/RyoYJg1eHQ1CUyE3+/R0zfUF94hnMBITfw ArMtf46Sy0IfpiKuE7q8gA8pxoP/uccVSnzJm5u+bve3Ko0+o1NPK2q0lp5bpmvC+asn Jm09KTtEWHeULXNbs5fef3rnvXhKm+Lyh4wkZVf7BYK9Z72KU1yeQLRMj9IABeF9Y8KG mugA== X-Received: by 10.113.7.163 with SMTP id dd3mr12749655lbd.96.1421366419044; Thu, 15 Jan 2015 16:00:19 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:e966:4081:140e:40fe]) by mx.google.com with ESMTPSA id w9sm990597laj.13.2015.01.15.16.00.16 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 15 Jan 2015 16:00:17 -0800 (PST) Message-ID: <54b85491.4925980a.17c4.2b00@mx.google.com> X-Google-Original-Message-ID: <001601d0311f$698deb00$3ca9c100$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Pawel Jakub Dawidek'" References: <54B4AE55.9090205@platinum.linux.pl> <54b5d299.4914980a.61cd.43a6@mx.google.com> <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> In-Reply-To: <20150115150316.GB1190@garage.freebsd.pl> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Date: Fri, 16 Jan 2015 03:00:15 +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: AdAw1C/82uLB0fl4TM2tPUP37KTA4AAFlFpw 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: Fri, 16 Jan 2015 00:00:21 -0000 > I'm very happy that you have spent the time to play with GELI code and > I hope you will continue to work on it, but this particular change > won't be accepted as part of GELI, please accept that even if you don't > fully agree. Stream ciphers are not compatible with GELI design. Hopefully ChaCha gets into /dev/crypto. > Using chacha might be a better fit for GBDE, where encryption keys are > generated and stored for every write, so there should be no risk with > reusing a key stream. This of course also require further analysis. > > If you would like to spend some more time with GELI, I'd suggest for > starters to preparing a patch that removes support for MD5, SHA1 and > RIPEMD160. Options I have not so much. 1. Drink vodka and use slow AES-XTS :) 2. Use ChaCha GELI private patch 3. Write Geom node. 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) ChaCha20 + blake2 will still be faster than AES-XTS, about half as much. It takes time, but I was happy with all ChaCha in geli. Even if implement, there is no guarantee that gets into the mainline. I'll think about Geom node with ChaCha, again and weigh all pros and cons, and now I have disks that need encrypt and fill in for 20 days lie idle.