Date: Wed, 14 Jan 2015 20:58:33 +0300 From: rozhuk.im@gmail.com To: "'Gleb Kurtsou'" <gleb@freebsd.org> Cc: freebsd-hackers@freebsd.org, freebsd-geom@FreeBSD.org, 'Adam Nowacki' <nowakpl@platinum.linux.pl> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Message-ID: <54b6ae4c.0905990a.6c9c.642e@mx.google.com> In-Reply-To: <20150114082019.GA3669@reks> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54b6ae4c.0905990a.6c9c.642e>