Date: Fri, 16 Jan 2015 09:21:04 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: rozhuk.im@gmail.com Cc: freebsd-hackers@freebsd.org, 'freebsd-geom' <freebsd-geom@freebsd.org>, 'Adam Nowacki' <nowakpl@platinum.linux.pl> Subject: Re: ChaCha8/12/20 and GEOM ELI tests Message-ID: <20150116082104.GA1230@garage.freebsd.pl> In-Reply-To: <54b85491.4925980a.17c4.2b00@mx.google.com> References: <20150114041708.GA3189@reks> <54b601ec.0515980a.0c9c.47e1@mx.google.com> <20150114082019.GA3669@reks> <54b6ae4c.0905990a.6c9c.642e@mx.google.com> <CAHsZcQH1BTz0Yn%2BxsRFjBxizOLaR=40Rh%2B_3TEmt6Q2mALTOog@mail.gmail.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 16, 2015 at 03:00:15AM +0300, rozhuk.im@gmail.com wrote: > > 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. 4. Look at GBDE. > 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. > 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. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150116082104.GA1230>