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
[-- Attachment #1 --] > On Jan 13, 2015, at 8:17 PM, Gleb Kurtsou <gleb@freebsd.org> wrote: > > 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. > > 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’s 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. > > >> 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. 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) > > >> 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? > > 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=182610 [2] http://marc.info/?l=openbsd-tech&m=141807224826859&w=2 > > Having XTS mode for a stream cipher in the first place looks really fishy.. > > Originally encryption is defined as: > T = AES-ENC(key2, i) (*) alpha_j > PP = P (*) T > CC = AES-ENC(key1, PP) > C = CC (*) T > > In stream cipher case: > T = CHACHA(key2, state2) (*) i (*) alpha_j > PP = P (*) T > CC = CHACHA(key1, state1) (*) PP > C = CC (*) T > > CC = CHACHA(key1, state1) (*) P (*) T > C = CC (*) T > > C = CHACHA(key1, state1) (*) P > > It doesn't depend on i, j or key2. state1 should be the same as well. > > _______________________________________________ > 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" [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29DB9466-3DF9-4191-9476-C46BF350848D>