Date: Wed, 14 Jan 2015 21:07:02 +0300 From: Alaksiej <ac@belngo.info> To: Rozhuk.IM@gmail.com Cc: Gleb Kurtsou <gleb@freebsd.org>, freebsd-geom <freebsd-geom@freebsd.org>, Adam Nowacki <nowakpl@platinum.linux.pl>, freebsd-hackers@freebsd.org Subject: Re: ChaCha8/12/20 and GEOM ELI tests Message-ID: <CAHsZcQH1BTz0Yn%2BxsRFjBxizOLaR=40Rh%2B_3TEmt6Q2mALTOog@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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, <rozhuk.im@gmail.com> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHsZcQH1BTz0Yn%2BxsRFjBxizOLaR=40Rh%2B_3TEmt6Q2mALTOog>