Date: Wed, 14 Jan 2015 08:43:05 +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: <54b601ec.0515980a.0c9c.47e1@mx.google.com> In-Reply-To: <20150114041708.GA3189@reks> References: <54b33bfa.e31b980a.3e5d.ffffc823@mx.google.com> <54B4AE55.9090205@platinum.linux.pl> <54b5d299.4914980a.61cd.43a6@mx.google.com> <20150114041708.GA3189@reks>
next in thread | previous in thread | raw e-mail | index | archive | help
> On (14/01/2015 05:21), 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. >=20 > 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. =20 >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. AES too slow for me, and options when someone magically going to read my = encrypted disk excluded. In my particular case. I think there will a lot of cases when you need the maximum speed of = encryption and all the other factors are not important or unlikely. For example, the value of the data may be too low to take the time to = decrypt, and the data can be very much and you want to write them down = quickly. =20 > > 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. >=20 > 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? > > These aspects of the application must necessarily be reflected in = the > documentation. > > > > > > There are objections to add ChaCha and XChaCha (without XTS) in GEOM > GELI? >=20 > I strongly object. Adam Nowacki already explained why XTS can not be used with ChaCha, I = realized my mistake. Now talking about ChaCha/XChaCha without(!!!) XTS.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54b601ec.0515980a.0c9c.47e1>