From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 05:43:11 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 A4719C5B; Wed, 14 Jan 2015 05:43:11 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 3B83B9B0; Wed, 14 Jan 2015 05:43:11 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so6241394lbi.2; Tue, 13 Jan 2015 21:43:09 -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=VL3zogd6IIJQCqzWvDQ0xP4E93l/WLJ2vd2SXm6nLsk=; b=WjiINAYC1SXt4oMe++fGZUzXWunfmn79z701spip7HFy1HkJO5nrM9xqJtu1+LU13q 2LA4sAzvrRzI9kp5elS+iqeX97t3z6MHsFKSzaZbJASwsc7uwbIeilxKRe/11LwmsHyw 3H7uUEjW6Ks2xN7AjRaf//D1uyzXVpaghOWgFRRTYYHwoJk9BEwtZbY4SI/LkTH58yeZ QEUyOTIZsH4iXSyUkXCxhRKYu/oDpalWBTo8JuIcDU//umVbbZ0Y2Ifw01+869ba4Tdr bclqz0+E7Ql04x4w2LAH/jsZnaeXWvosaKDh49yZwIODBHijceokpcIRvsk5ff5uP8ae 9ttA== X-Received: by 10.112.160.33 with SMTP id xh1mr2047293lbb.60.1421214189260; Tue, 13 Jan 2015 21:43:09 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:b007:2759:7397:9491]) by mx.google.com with ESMTPSA id r5sm1427772lae.34.2015.01.13.21.43.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Jan 2015 21:43:08 -0800 (PST) Message-ID: <54b601ec.0515980a.0c9c.47e1@mx.google.com> X-Google-Original-Message-ID: <028f01d02fbc$f98e6400$ecab2c00$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Gleb Kurtsou'" References: <54b33bfa.e31b980a.3e5d.ffffc823@mx.google.com> <54B4AE55.9090205@platinum.linux.pl> <54b5d299.4914980a.61cd.43a6@mx.google.com> <20150114041708.GA3189@reks> In-Reply-To: <20150114041708.GA3189@reks> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Date: Wed, 14 Jan 2015 08:43:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdAvsM8oThNDkVedQwqTv+5SFSD+pwACGN9Q Content-Language: ru 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 05:43:11 -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. >=20 > 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. =20 >From different types of threats, there are various means of protection. AES-XTC more universal solution, encryption ChaSha more specialized. Each solution has its pluses and minuses. AES too slow for me, and options when someone magically going to read my = encrypted disk excluded. In my particular case. I think there will a lot of cases when you need the maximum speed of = encryption and all the other factors are not important or unlikely. For example, the value of the data may be too low to take the time to = decrypt, and the data can be very much and you want to write them down = quickly. =20 > > Ability to read encrypted sectors has a transmission network, for > example when the container=3Ddisk 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. >=20 > 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. Can you describe what is weak encryption swap with ChaCha? > > 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? >=20 > I strongly object. Adam Nowacki already explained why XTS can not be used with ChaCha, I = realized my mistake. Now talking about ChaCha/XChaCha without(!!!) XTS.