From owner-freebsd-geom@FreeBSD.ORG Wed Jan 14 05:56:56 2015 Return-Path: Delivered-To: freebsd-geom@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 D36B6E69; Wed, 14 Jan 2015 05:56:56 +0000 (UTC) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (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 472D8AB4; Wed, 14 Jan 2015 05:56:56 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id u10so6185897lbd.13; Tue, 13 Jan 2015 21:56:54 -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=iinTKq9P0BNrvbo0UngKpgmoTvC9PwFYVrUmOXS/paw=; b=oU/hZLzxFWSZaT2fCdR+yNix4El7BwKxpMTJrCJCFD0jaqjEogUDhDt4XZCLsHg8V8 ibGORoegbrAUKZnAgeLONrEPJneGTd38BX5n8qlEi5pu/nPGp9+G51MWS267zInHc6+l imkAaZYjoz9aPrI8eVEMEvKVvuDMhXNZBewnYPzUWtWk7BqUB6IgSqpvWFkaA+HXeQyR zIWsfih84GrRT/Tj68v1WJqvWT91LN/zF/cIZZIqf4sa6oFaJJ1K6WUGMHl70HBENMWX jeBped2Sx60iFiYn5n5RIz6+igMbJcGbp4gMuLod8d3AZkEgCBsexUkpKBrZzO3kazdc 3qrg== X-Received: by 10.112.181.106 with SMTP id dv10mr2040384lbc.88.1421215014337; Tue, 13 Jan 2015 21:56:54 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:b007:2759:7397:9491]) by mx.google.com with ESMTPSA id o13sm1444094laa.16.2015.01.13.21.56.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 13 Jan 2015 21:56:53 -0800 (PST) Message-ID: <54b60525.2d08980a.437b.4760@mx.google.com> X-Google-Original-Message-ID: <029001d02fbe$e5700580$b0501080$@IM@gmail.com> From: rozhuk.im@gmail.com X-Google-Original-From: Reply-To: To: "'Alexey Ivanov'" , "'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> <29DB9466-3DF9-4191-9476-C46BF350848D@gmail.com> In-Reply-To: <29DB9466-3DF9-4191-9476-C46BF350848D@gmail.com> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Date: Wed, 14 Jan 2015 08:56:50 +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: AdAvuoxrjwn5higZTmycb/oOCeD3dAAAm+QA Content-Language: ru Cc: freebsd-hackers@freebsd.org, 'Adam Nowacki' , freebsd-geom@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: Wed, 14 Jan 2015 05:56:57 -0000 > >>> 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. > Agreed: > In day to day life if anyone had an ability to read content off > laptop=E2=80=99s hdd when it is hibernated - he would break the = encryption. > In server world if one has access to two HDDs from the same raid1 from > different points in time - he also will have the ability to decrypt > data. While the laptop is sleeping from the dump, you can get any encryption = keys the mounted disk, no matter what they are encrypted. With servers agree, but I specifically focus on the conditions of = application of ChaCha. > > 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. > Agreed again, if one really wants to add stream cipher he should then > securely generate random IV and write it to disk along with the data > (e.g. how g_eli_integrity.c does for HMAC, or even something simpler > since one does not have a requirement of storing IV on the same sector > as data) ChaCha perfectly suitable where speed is needed, but you can go to some = risks. I do not see the possibility of an attacker can decrypt ChaCha if he is = unable to read the encrypted data in a different time and compare them = with the plain text. ChaCha is not a silver bullet when encrypting drives, but its area of = application it has.