From owner-freebsd-geom@FreeBSD.ORG Wed Jan 14 08:43:52 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 0C905E72; Wed, 14 Jan 2015 08:43:52 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::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 C7255DBB; Wed, 14 Jan 2015 08:43:51 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id ft15so8579762pdb.4; Wed, 14 Jan 2015 00:43:51 -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=yoz/1e1S/3kpIPEi7IupduhcYFDnsMd1Qv+/D3/Il+0=; b=DWtA4+sRpSzpHZKKyxnEQw8iq7NnnX4MHPDn5mue7ftWKAYbJjZY+/pUG62Gv5dqJd GL1FJ4kuqe8BMCdXaLG0y+WsuhInywzxH/uCg9sp0I8YKSQIjdA0l4W2muaqaKItyxBN 3RkS6FntONBcDvJAXxWqHeSFzbsR3nciEOWi0K3QK1xIiPhh8i2GDJf9Iq1+yxDxVKHg CRWZXolZPhkYs0OJSW7qCd/6qAnPMD7KYu/gFAmP5GFx+X+7ZZsop+gvYrsUkC8Q6wAB fNIafXuBMkigVArq7gQUebCWnfBzt0wwTUO30Qs2Q5Sn2g/h4Z0ou1CeIYHmsTc2wlpp T2OA== X-Received: by 10.70.31.197 with SMTP id c5mr3873477pdi.93.1421225031418; Wed, 14 Jan 2015 00:43:51 -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 ma7sm19097669pdb.53.2015.01.14.00.43.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Jan 2015 00:43:50 -0800 (PST) Sender: Gleb Kurtsou Date: Wed, 14 Jan 2015 00:44:57 -0800 From: Gleb Kurtsou To: rozhuk.im@gmail.com Subject: Re: ChaCha8/12/20 and GEOM ELI tests Message-ID: <20150114084457.GA4099@reks> Mail-Followup-To: rozhuk.im@gmail.com, 'Kimmo Paasiala' , 'FreeBSD Hackers' , freebsd-geom@freebsd.org, 'Adam Nowacki' 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54b5fbbe.4457700a.2456.6944@mx.google.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: 'Kimmo Paasiala' , freebsd-geom@freebsd.org, 'Adam Nowacki' , 'FreeBSD Hackers' 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: Wed, 14 Jan 2015 08:43:52 -0000 On (14/01/2015 08:16), rozhuk.im@gmail.com wrote: > > >> 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 the > > attacker always has this capability, even with so much power the > > attacker shouldn't be able to break the encryption scheme. If he can > > then the encryption scheme is not secure. > > > > Ift the attacker can learn anything about the unencrypted data or > > predict something about future encrypted or unencrypted blocks by > > 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. Do you imply that scheme you propose will not provide support for network storage? What about HAST, iSCSI, ATA over Ethernet, Cinder or whatever else is fancy those days? Documenting such limitation would make geli look terrible, not to mention confusing.. > If an attacker can read encrypted data directly to disk means that the > system is already compromised by an attacker, Unless you don't have knowledge of attacker possessing such power :) I would happily throw my encrypted disk away every time I find out it was tempered with offline. The good thing I never know whether is has happened (good way to save some money as well). That is why assumption that attacker has access to encrypted disk should hold. 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 access to old data and changing key for new data without creating full copy. > and probably in this > case can read the data from the disk and through read() already > decrypted and get the key from the kernel memory.