From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 17:58:40 2015 Return-Path: Delivered-To: freebsd-hackers@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 E5E243D5; Wed, 14 Jan 2015 17:58:39 +0000 (UTC) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::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 3808E2D3; Wed, 14 Jan 2015 17:58:39 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id gq15so9528137lab.4; Wed, 14 Jan 2015 09:58:37 -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=aGXqeB/y+2qGafeOfRLg2okfKjb1u8r5XpPstzGmoPU=; b=qdJZnMnbD3r9yApWmXa0cHH8hQFVaG0uM92wdAIpyRBJMJ13pbcwdmRsQx7FMfoM3K PkSPhlpBiaqdiBh6hFye/Ko7L8tY8oPTemSxC6QPAiVMFf0hazGb4nj5zb4eC9KAkPQO qRJIibdRTJyucfPKFzuTybbYs4XuZtOU9QvPkqD6brr0bBoh8xwOMGZvpJozKTaK7wsG /ic4ISWZJgOJmwv8TwXEOx0sDR6bMHB+Kqo1aD+NT02lBXqFe/jV9m5sSOx0+rIiO7zS EJ4WcTvkLylOp3ExcsfFthAKpaeOkz7Zc7owzCKHqJ6m7dnevAqRh2LL86yrRIIFTt9a MzVw== X-Received: by 10.152.44.167 with SMTP id f7mr5386219lam.92.1421258317214; Wed, 14 Jan 2015 09:58:37 -0800 (PST) Received: from rimwks1w7x64 ([2001:470:1f15:8e:b007:2759:7397:9491]) by mx.google.com with ESMTPSA id ci9sm1966982lad.21.2015.01.14.09.58.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Jan 2015 09:58:36 -0800 (PST) Message-ID: <54b6ae4c.0905990a.6c9c.642e@mx.google.com> X-Google-Original-Message-ID: <029e01d03023$b7c56520$27502f60$@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> <54b601ec.0515980a.0c9c.47e1@mx.google.com> <20150114082019.GA3669@reks> In-Reply-To: <20150114082019.GA3669@reks> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Date: Wed, 14 Jan 2015 20:58:33 +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: AdAv0siqUUBsp0hPTjWoxAcK7FDFgwASmyEA 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 17:58:40 -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. > > > > 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. >=20 > "various means of protection" is rather confusing. It's either > acceptable for disk encryption or not. =20 This is acceptable for disk encryption in certain conditions: need speed = and have the assurance that an attacker does not have access to the data = flow while the disk is mounted. > > AES too slow for me, and options when someone magically going to = read > my encrypted disk excluded. > > In my particular case. >=20 > It's widely accepted threat model (as was also mentioned elsewhere). = So > it's rather your particular use case that has magic vibe to it. In my case, home use, my data is not so important to arrange a targeted = attack on the home server. Moreover, in the case of targeted attack, there is often much easier = ways to get the unencrypted data than analyzing encrypted disk sectors. I need to encrypt the case if the server can steal or take by force. So I think that for me personally for my purposes ChaCha is more = appropriate than AES-XTS. I am sure many other users will also be happy to get a faster encryption = in exchange for the possibility of targeted attacks unlikely. > > > > 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. > > > > > > 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? >=20 > Stream cipher, as is, is not acceptable for disk encryption. I think = we > all agree on that. Stream cipher disks acceptable in certain cases. > It remains secure as soon as the same key stream is not used twice. > By writing data to the same sector one breaks this requirement. > > I'm not objecting that there is a possibility of building swap > encryption on top of stream cipher, but that is likely not to be > trivial and would require careful design review. Although I don't see > how block device "encrypted" with stream cipher can be secure under > assumption that attacker has access to the disk. It all has no value if the attacker has no way to get multiple copies of = the same sector with different data. > BTW You may want to get rid of SHA in g_eli_crypto_ivgen() for ChaCha > in pursue for yet higher performance. IV =3D SHA256(key, sector num) ChaCha8-256 =3D 353804761 bytes/sec ChaCha12-256 =3D 299028184 bytes/sec ChaCha20-256 =3D 225262046 bytes/sec XChaCha8-256 =3D 347179985 bytes/sec XChaCha12-256 =3D 289285124 bytes/sec XChaCha20-256 =3D 219787078 bytes/sec IV =3D sector num ChaCha8-256 =3D 376476930 bytes/sec ChaCha12-256 =3D 312266331 bytes/sec ChaCha20-256 =3D 233636775 bytes/sec XChaCha has a 192-bit IV, so I would prefer to get IV from the hash. > As far as I remember Salsa20 has this nice property of letting one > start encryption from arbitrary offset in the stream, I assumed that > you are using the same in ChaCha for geli. Although having looked at > the code it is not that obvious what is going on. There is a method to > set iv being used, but not to change counter (stream offset). Is that > intentional? Do we reset key for each geli sector to be encrypted? chacha_iv_set() does not reset key. xchacha_set_key_iv_rounds() require key and IV. chacha_counter_set() - set block counter. chacha_key_set() - copy key and constant to chacha context.