From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 04:16:03 2015 Return-Path: Delivered-To: freebsd-hackers@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 EE3C632B; Wed, 14 Jan 2015 04:16:02 +0000 (UTC) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (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 BDCF7E5E; Wed, 14 Jan 2015 04:16:02 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id g10so7372018pdj.6; Tue, 13 Jan 2015 20:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=uQOxL7nFniBWpyX10UG7fpVjyHgcA2QjtqD8rqj9JvE=; b=USpLqIiP2vRLCIk790VVhJfEbGOXnG1Jy9eFGxVDw6flD9x/vmxJ/6OTbN5Hv/dPoA QSQVYhGmNXPIzwlazrQPfMvXMZDKxFb8BOsFtMo8PDVwWLkUCLCHSEp+U4e4t/ihMTwF LtAMCwRWafjG3dHULXq0FuGFk+F2xMazD0kGAoPoylDi22TVVT3vGc4eRdKg2v2Q2iMF flZ7eqNzt0XDyFaFMxA5xTl1NwBugNgcOqeUni+Sc2pglJdP+JSJhusJJwXKxp2smfOt xGyauufy6AaKh7NDOvPBOqybyRiD4bhRQzpGTNB7hfG7O1qjnoGduoqotSxjZgT+gRSj gv7A== X-Received: by 10.66.228.200 with SMTP id sk8mr2523618pac.134.1421208962259; Tue, 13 Jan 2015 20:16:02 -0800 (PST) Received: from localhost (c-76-21-76-83.hsd1.ca.comcast.net. [76.21.76.83]) by mx.google.com with ESMTPSA id or4sm18542532pab.30.2015.01.13.20.16.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jan 2015 20:16:01 -0800 (PST) Sender: Gleb Kurtsou Date: Tue, 13 Jan 2015 20:17:08 -0800 From: Gleb Kurtsou To: rozhuk.im@gmail.com Subject: Re: ChaCha8/12/20 and GEOM ELI tests Message-ID: <20150114041708.GA3189@reks> Mail-Followup-To: rozhuk.im@gmail.com, 'Adam Nowacki' , freebsd-hackers@freebsd.org, freebsd-geom@FreeBSD.org References: <54b33bfa.e31b980a.3e5d.ffffc823@mx.google.com> <54B4AE55.9090205@platinum.linux.pl> <54b5d299.4914980a.61cd.43a6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54b5d299.4914980a.61cd.43a6@mx.google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-hackers@freebsd.org, freebsd-geom@FreeBSD.org, 'Adam Nowacki' X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2015 04:16:03 -0000 On (14/01/2015 05:21), rozhuk.im@gmail.com wrote: > > Maybe faster but a stream cipher is unusable for disk encryption - iv > > is derived from sector number and doesn't change. Being able to write a > > known plaintext and read resulting ciphertext allows you to recover the > > cipher stream and decrypt any past or future data stored on that > > sector. > > Depends on the capabilities of the attacker. > > To be able to continuously read encrypted sectors for data collection > is too much. I disagree. It's the most basic attack scenario. Assuming attacker was able to get access to encrypted disk once, odds are high it may happen again. > Ability to read encrypted sectors has a transmission network, for example when the container=disk is stored somewhere in the cloud. > > In many cases, the attacker gets Encrypted disk along with other equipment, often in the off state. > Without encryption keys and the ability to write / read through the GELI. > > I do not see any weaknesses stream ciphers in cases when the attacker is not able to access the disk when it is mounted in the GEOM GELI. > > Another possibility is the use of ChaCha (without XTS) - encryption > swap file: there every time a new key is generated, besides the speed > is particularly important. Stream cipher (or similarly functioning block cipher mode) should not be used for disk encryption. IMHO swap encryption hardly justifies adding insecure encryption mode to geli. Fast swap is certainly nice to have, but rather remains a snake oil, system will remain trashed due to swapping no matter how fast swap is. > These aspects of the application must necessarily be reflected in the documentation. > > > There are objections to add ChaCha and XChaCha (without XTS) in GEOM GELI? I strongly object. Having XTS mode for a stream cipher in the first place looks really fishy.. Originally encryption is defined as: T = AES-ENC(key2, i) (*) alpha_j PP = P (*) T CC = AES-ENC(key1, PP) C = CC (*) T In stream cipher case: T = CHACHA(key2, state2) (*) i (*) alpha_j PP = P (*) T CC = CHACHA(key1, state1) (*) PP C = CC (*) T CC = CHACHA(key1, state1) (*) P (*) T C = CC (*) T C = CHACHA(key1, state1) (*) P It doesn't depend on i, j or key2. state1 should be the same as well.