From owner-freebsd-geom@FreeBSD.ORG Thu Jan 15 00:29:50 2015 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8D515E9; Thu, 15 Jan 2015 00:29:50 +0000 (UTC) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (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 5DBE793D; Thu, 15 Jan 2015 00:29:50 +0000 (UTC) Received: by mail-lb0-f173.google.com with SMTP id z12so10795306lbi.4; Wed, 14 Jan 2015 16:29:48 -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=qP6OB4iPUbJ7AKacUtDRyoIZ4taz/x8ENNhTpPxXiW4=; b=VRIT4j5WCpdNkCddLZkHuiBlJ9/n8CQ3z+l2mV5xHy64fpG4j7alJrqSr5rfmuzMCa wa49GaeQUBTA3LC74Vtd/OjJtWCRuCgh12soMOG5FuCHBnxJOD/I2AOrJkitSX0St26V MwfTPZq3ErgG6Z0MttOoIfyEfb7tYy4EH/opRLy7poDgo3r3GzzGUrPz7bxaWGzqurpe TZrtHpr5bUPnseC8UX5N/o84zjUCLWgmo48rSsRCZpcXHhEPUCSjMX3ednhlw5rhEmJ9 rLPHJvFVteGRn1Nwevqj+C2YoM7Pblt0jkrFq9DaRXNaPdIr2gbqeNEPHpC6uR7grqvN m/Hw== X-Received: by 10.112.198.1 with SMTP id iy1mr1019739lbc.13.1421281788431; Wed, 14 Jan 2015 16:29:48 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:b007:2759:7397:9491]) by mx.google.com with ESMTPSA id e7sm3160379lbq.33.2015.01.14.16.29.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Jan 2015 16:29:47 -0800 (PST) Message-ID: <54b709fb.0739700a.2970.ffffa14a@mx.google.com> X-Google-Original-Message-ID: <000601d0305a$5db5f4a0$1921dde0$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Adam Nowacki'" , "'freebsd-geom'" References: <54b33bfa.e31b980a.3e5d.ffffc823@mx.google.com> <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> In-Reply-To: <54B6C6B7.4070407@platinum.linux.pl> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Date: Thu, 15 Jan 2015 03:29:44 +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: AdAwMnJtnO5xniq6RwaQFPotzQ32hwAIMuYA Content-Language: ru Cc: freebsd-hackers@freebsd.org 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: Thu, 15 Jan 2015 00:29:51 -0000 > >> 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.