Date: Fri, 16 Jan 2015 03:00:15 +0300 From: rozhuk.im@gmail.com To: "'Pawel Jakub Dawidek'" <pjd@FreeBSD.org> 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: <54b85491.4925980a.17c4.2b00@mx.google.com> In-Reply-To: <20150115150316.GB1190@garage.freebsd.pl> 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> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54b85491.4925980a.17c4.2b00>