From owner-freebsd-geom@FreeBSD.ORG Wed Jan 14 18:07:29 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 951E0AF9 for ; Wed, 14 Jan 2015 18:07:29 +0000 (UTC) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (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 584445EC for ; Wed, 14 Jan 2015 18:07:28 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id wp18so9388226obc.1 for ; Wed, 14 Jan 2015 10:07:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=eFwB8Ww8III+gq/p29kHkxM9QZL+dDv8JUjsnmMM4q0=; b=nFY66c9HCu6WZM+8/VtO5NrZCiPA6uqSxkmDk3r2atZHUk4/FrT+6xEf5QL8wGbTPi VP38ZOD+gVDfI1knuCBJc5LWgm4TuSbNjJL8uUd2Xvml8wIsjk3pulHyaQ9bT9iT/Xuf I2XUl14tF3O8iUq12XHpES45BMMr+vk1xHALZ9Y8HD5DH1F0O86Y4RNDh34kWT5KzCAj LmiCof8+RUrSvm935/O4E52SpvUUV5VYc3/EJLs2ofZmPN1sXqEMEs/AJ0EumM5E0IoV lUP7ITohRaYs15ODrvSuSksdONB/CENWTnwB0IwjlvJREeHPTA7P/HxegpMIqIwJp4bq psEg== X-Gm-Message-State: ALoCoQlyQ2eApQ04dYTlCwNq4ihY/AS+K8l20zz/VG/kfcePL1gmJwGKjAoh9mxu0xU49HbNOt0F X-Received: by 10.182.215.163 with SMTP id oj3mr3283409obc.49.1421258842439; Wed, 14 Jan 2015 10:07:22 -0800 (PST) MIME-Version: 1.0 Sender: a@carniajeu.com Received: by 10.202.212.71 with HTTP; Wed, 14 Jan 2015 10:07:02 -0800 (PST) X-Originating-IP: [46.53.218.193] In-Reply-To: <54b6ae4c.0905990a.6c9c.642e@mx.google.com> 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> <54b6ae4c.0905990a.6c9c.642e@mx.google.com> From: Alaksiej Date: Wed, 14 Jan 2015 21:07:02 +0300 X-Google-Sender-Auth: F2KcXXts0ugobisBfH6pn1Aisl4 Message-ID: Subject: Re: ChaCha8/12/20 and GEOM ELI tests To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Gleb Kurtsou , freebsd-geom , Adam Nowacki , freebsd-hackers@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 18:07:29 -0000 Excuse me, but if you think your physical medium is either 100% inaccessible to an adversary, or simply not worth a real attack, and the speed is the concern, then why do you want to use any encryption at all? Best, Alaksiej On Wed, Jan 14, 2015 at 8:58 PM, 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. > > > > > > > > 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. > > > > "various means of protection" is rather confusing. It's either > > acceptable for disk encryption or not. > > 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. > > > > 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=disk 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? > > > > 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 = SHA256(key, sector num) > ChaCha8-256 = 353804761 bytes/sec > ChaCha12-256 = 299028184 bytes/sec > ChaCha20-256 = 225262046 bytes/sec > XChaCha8-256 = 347179985 bytes/sec > XChaCha12-256 = 289285124 bytes/sec > XChaCha20-256 = 219787078 bytes/sec > > IV = sector num > ChaCha8-256 = 376476930 bytes/sec > ChaCha12-256 = 312266331 bytes/sec > ChaCha20-256 = 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. > > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" >