From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 18:27:25 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 9050DF5B; Wed, 14 Jan 2015 18:27:25 +0000 (UTC) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 06D45868; Wed, 14 Jan 2015 18:27:25 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so9438176lbv.0; Wed, 14 Jan 2015 10:27:23 -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=HYyGqleDKtNcRlh6H/2FZTSmOerIrQNjL8pbWVascOE=; b=PXFQ5YYhQaSZ+xcVZ3kgaUQJ2dem5fbvyx28haOtbnTS3D+AFSTgRoKFqdKBDhrHDr gnrS92VitLF52BVdybLlOYgDbtLqskMBsz1GgM0Q2zPBp4XCLehjDfbMkNA8LQyUFiEj HI6LEDE4QdQwrsnHv1a3+45DSe55xb7SkeVrpSfK3Eu+x+0GUQtK/ZWhe5fRtArC6oUK lzK9Bkx2ROaCBzm+tcwrob/SL9Rdk4+xYIygzlcyrH6Uu1VAiTaszeqZGNvYM76icknR D5dRcc/ektgl3g80nTrY14h05hoU4822Z1PLjgVuMkjvey4sryrQqbnZ1+TsMtObSLjg fWeA== X-Received: by 10.112.200.103 with SMTP id jr7mr5600017lbc.0.1421260043084; Wed, 14 Jan 2015 10:27:23 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:b007:2759:7397:9491]) by mx.google.com with ESMTPSA id mc17sm6131147lbb.1.2015.01.14.10.27.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Jan 2015 10:27:22 -0800 (PST) Message-ID: <54b6b50a.d17b700a.5b19.4bd3@mx.google.com> X-Google-Original-Message-ID: <02a601d03027$bcbbb3a0$36331ae0$@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> <54b5fbbe.4457700a.2456.6944@mx.google.com> <20150114084457.GA4099@reks> In-Reply-To: <20150114084457.GA4099@reks> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Date: Wed, 14 Jan 2015 21:27:20 +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: AdAv1jkG5Xl3HuGtSFayFxpfG2E9rgAUXkmw Content-Language: ru Cc: 'Kimmo Paasiala' , freebsd-geom@freebsd.org, 'Adam Nowacki' , 'FreeBSD Hackers' 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 18:27:25 -0000 > > > >> Depends on the capabilities of the attacker. > > > >> > > > >> To be able to continuously read encrypted sectors for data > > > collection is too much. > > > >> > > > > > > > When talking about disk encryption the first assumption is that=20 > > > the attacker always has this capability, even with so much power=20 > > > the attacker shouldn't be able to break the encryption scheme. If=20 > > > he > can > > > then the encryption scheme is not secure. > > > > > > Ift the attacker can learn anything about the unencrypted data or=20 > > > predict something about future encrypted or unencrypted blocks by=20 > > > analyzing the previous encrypted blocks the encryption scheme > should > > > be considered insecure. > > > > I consider the case when the disk can be obtained by physically an > attacker. > > All the rest of the disk directly connected to the computer. >=20 > Do you imply that scheme you propose will not provide support for=20 > network storage? What about HAST, iSCSI, ATA over Ethernet, Cinder or=20 > whatever else is fancy those days? >=20 > Documenting such limitation would make geli look terrible, not to=20 > mention confusing.. Provide, but insecure / less secure. :) > > If an attacker can read encrypted data directly to disk means that > the > > system is already compromised by an attacker, >=20 > Unless you don't have knowledge of attacker possessing such power :) God knows everything :) How to protect your data from God? :) > I would happily throw my encrypted disk away every time I find out it=20 > was tempered with offline. The good thing I never know whether is has=20 > happened (good way to save some money as well). >=20 > That is why assumption that attacker has access to encrypted disk=20 > should hold. ChaCha does not suit you. > In case of block device encryption overall situation is much worse. > Imagine you find out that your geli keys were compromised. There is no = > mechanism provided to switch to new encryption key while retaining=20 > access to old data and changing key for new data without creating full = > copy. Technically, you can change the encryption keys geli without creating a = complete copy, but if something happens in the process there is a risk = of losing some data. I think that's why it did not implement.