Date: Thu, 15 Jan 2015 16:03:17 +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: <20150115150316.GB1190@garage.freebsd.pl> In-Reply-To: <54b709fb.0739700a.2970.ffffa14a@mx.google.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. 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. 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. On Thu, Jan 15, 2015 at 03:29:44AM +0300, rozhuk.im@gmail.com wrote: > > >> Excuse me, but if you think your physical medium is either 100% > > >> inaccessible to an adversary, or simply not worth a real attack, and > > >> the speed is the concern, then why do you want to use any encryption > > >> at all? > > > > > > 100% is not available yet introduced GELI keys / mounted drive. > > > AES-XTS is good but too slow. > > > > FreeBSD supports AES-NI - hardware accelerated AES available in many > > Intel and AMD processors. I'm seeing speeds of 1GB/s on i5 2500K. > > Not all modern processors. > In ARM / MIPS do not have this accelerator. > > > > > ChaCha is already enough to cryptography was not a bottleneck. > > > > > > The case when the disks - local (SATA/SAS/IDE/USB), keys entered / > > disk is mounted and the attacker has access I do not see because AES- > > XTS does not help. > > > > A few scenarios that will break ChaCha encryption: > > - remapped bad sectors on spinning disks, > > - multiple copies of sectors on SSD due to wear leveling, > > Remaping done inside the drive for the OS sector number does not change. > If the sector number changes this would hurt not only the data encrypted in > any cryptographic algorithm Geom GELI but filesystems without encryption. > > > > - RAID with one of the drives dropping out due to bad cabling, bad > > sectors or other issues, > > This is the same affect file systems without encryption and any other > encryption schemes. An exception will be an encryption scheme where one key > to all sectors. > > > > - disk imaged at multiple points in time (for example powered-off > > laptop left unattended). > > Yes, but there are observations: > 1. It is not critical to encrypt the swap file and TMP by onetime key > > 2. To get the key stream and read the encrypted data must be long enough for > a long time to collect disk images and analyze them. > A little help to increase the safety of pre-filling the entire encrypted > disk with random data. > > 3. If this is probably better to use other encryption schemes. :) > In general, the attacker will require significant investment of time and > resources to carry out such an attack. > The owner of such valuable data will not likely make a choice in favor of > speed encryption. > > > And yet, for the paranoid. > At the moment, XTS implemented only for AES. > For AES there are timing attack, allowing the unprivileged process to obtain > the encryption key by analyzing the behavior of the system. > > Cache-timing attacks on AES: > http://cr.yp.to/antiforgery/cachetiming-20050414.pdf > https://cseweb.ucsd.edu/~kmowery/papers/aes-cache-timing.pdf > > Wait a minute! A fast, Cross-VM attack on AES: > https://eprint.iacr.org/2014/435.pdf > > A Cache Timing Attack on AES in Virtualization Environments: > http://fc12.ifca.ai/pre-proceedings/paper_70.pdf > > > So it may be that the attacker suddenly get an encryption key from the AES > as a whole, rather than trying to read the sectors. > Note that the sector is more difficult to read is not the privileged > process. > > ChaCha runs in constant time and is not subject to such attacks. > > > > > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" -- 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?20150115150316.GB1190>