Date: Wed, 14 Jan 2015 05:21:10 +0300 From: rozhuk.im@gmail.com To: "'Adam Nowacki'" <nowakpl@platinum.linux.pl>, <freebsd-hackers@freebsd.org>, <freebsd-geom@FreeBSD.org> Subject: RE: ChaCha8/12/20 and GEOM ELI tests Message-ID: <54b5d299.4914980a.61cd.43a6@mx.google.com> In-Reply-To: <54B4AE55.9090205@platinum.linux.pl> References: <54b33bfa.e31b980a.3e5d.ffffc823@mx.google.com> <54B4AE55.9090205@platinum.linux.pl>
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. 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. 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54b5d299.4914980a.61cd.43a6>