Date: Tue, 13 Jan 2015 21:25:36 -0800 From: Alexey Ivanov <savetherbtz@gmail.com> To: rozhuk.im@gmail.com, Gleb Kurtsou <gleb@freebsd.org> Cc: freebsd-hackers@freebsd.org, Adam Nowacki <nowakpl@platinum.linux.pl>, freebsd-geom@FreeBSD.org Subject: Re: ChaCha8/12/20 and GEOM ELI tests Message-ID: <29DB9466-3DF9-4191-9476-C46BF350848D@gmail.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
--Apple-Mail=_E97B72A1-5F74-45E8-A7F5-D4A9E766D7DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 13, 2015, at 8:17 PM, Gleb Kurtsou <gleb@freebsd.org> wrote: >=20 > 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. >>=20 >> Depends on the capabilities of the attacker. >>=20 >> 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. Agreed: In day to day life if anyone had an ability to read content off = laptop=E2=80=99s hdd when it is hibernated - he would break the = encryption. In server world if one has access to two HDDs from the same raid1 from = different points in time - he also will have the ability to decrypt = data. >=20 >=20 >> Ability to read encrypted sectors has a transmission network, for = example when the container=3Ddisk is stored somewhere in the cloud. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. Agreed again, if one really wants to add stream cipher he should then = securely generate random IV and write it to disk along with the data = (e.g. how g_eli_integrity.c does for HMAC, or even something simpler = since one does not have a requirement of storing IV on the same sector = as data) >=20 >=20 >> These aspects of the application must necessarily be reflected in the = documentation. >>=20 >>=20 >> There are objections to add ChaCha and XChaCha (without XTS) in GEOM = GELI? >=20 > I strongly object. Yep, though having ChaCha as a replacement for arc4 in both = userland[1][2] and kernel would be nice. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D182610 [2] http://marc.info/?l=3Dopenbsd-tech&m=3D141807224826859&w=3D2 >=20 > Having XTS mode for a stream cipher in the first place looks really = fishy.. >=20 > Originally encryption is defined as: > T =3D AES-ENC(key2, i) (*) alpha_j > PP =3D P (*) T > CC =3D AES-ENC(key1, PP) > C =3D CC (*) T >=20 > In stream cipher case: > T =3D CHACHA(key2, state2) (*) i (*) alpha_j > PP =3D P (*) T > CC =3D CHACHA(key1, state1) (*) PP > C =3D CC (*) T >=20 > CC =3D CHACHA(key1, state1) (*) P (*) T > C =3D CC (*) T >=20 > C =3D CHACHA(key1, state1) (*) P >=20 > It doesn't depend on i, j or key2. state1 should be the same as well. >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" --Apple-Mail=_E97B72A1-5F74-45E8-A7F5-D4A9E766D7DB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUtf3VAAoJECvXQw+IBr2abfcP/Ag+K0OOlD63DGyNcM00bQMs BX130Ek+km9tPCgRNTEVMWTgcSET0FHLv/UcdLmuQT7nzPk8bBgMUpL4cMfG+G/x w4e86yGF6ltpYTHDzUdxmjjUC2udzN7wUEesZg/DEOUJdSSEYFLXEvwSk/YxCo9J qnVKf9mbkBIyaIpfkb2i9uF3LE3KA4whpqhVMKV0RpiZ14uY6thj3SGw/l+X/64q 8fAKcWdkGleVyYiR72Hd+vpCMxqnBeVMzMGXd6RxpRZh0jdZvJ1RDOCk1t5Fuoly OdYzd31b8OUbGWxzCv6/6CVY4qPi6LaTAYWTu04M6rddvgFYfc1Yz6eSRaI4w8Bi 1gUi87OSHFG6EsUkpgXDMjhqKNKn484HKsFGtzO3AdGwaQNE0yrHDiePyk8Afych 0aOTVD8RzGGYdvimubuTD9jd6ud8LVXr+Pce62LYbX7RfGhUYiuKmx8siYRrnItO byeZDeBb/WMYh3AngDGF/aeG6yqbf9BALCvmMfUHohzPyQHOKIlt4iLZtigDNe7K dWyN/iNj0ZpEC9cwKyJVYItN2HhboonIsM/Fk8w1nGtrQWR080udweWHH4jMnint hr6CBdF1VyE7Di3+iCmGDZyy1njA1WqvLf3v+rJKhkvrVwVXAbWyHOvlgQ8vNfSz 1VJXu14iAlmxhNtsYAVT =WSPn -----END PGP SIGNATURE----- --Apple-Mail=_E97B72A1-5F74-45E8-A7F5-D4A9E766D7DB--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29DB9466-3DF9-4191-9476-C46BF350848D>