I recall sitting in a packed room with over a hundred devs at the 2004 Ottawa Linux Symposium while the topic of the number of filesystem bits was being discussed (link: https://www.linux.com/news/ottawa-linux-symposium-day-2/). I recall people throwing out questions as to why we weren't just jumping to 128 or 256 bits, and at one point someone blurted out something about 1024 bits. Someone then made a comment about the number of atoms in the universe, everyone chuckled, and the discussion moved on. I sensed the feeling in the room was that any talk of 128 bits or more was simply ridiculous. Mind you this was for storage.
Fast-forward 18 years, and it's fascinating to me to see people now seriously floating the proposal to support 256-bit pointers.
The difference between "number of atoms in the universe" and "number of possible states of a system" are vastly different. The latter is a combinatorial problem, and if you're trying to to track the possible combinations of 100 variables that can take on 10 states each, you've got 10^100 combinations and are already beyond atoms in the universe (10^80). You can never enumerate them all, but the ability to work on large subspaces would be a help.
Hi! Author of fs-crypt dropping in from the interwebs.
I also created eCryptfs, which was Ubuntu's original home directory encryption technology, with lots of additional distro integration work by Dustin Kirkland. Unfortunately I had to make some compromises when going with the stackable model, and that caused some problems.
I took the lessons I learned from that first attempt and created fs-crypt as a sort of atonement. I think I got a lot more right on my second attempt at file-base encryption in Linux. At least, it's good enough to be the technology that now encrypts Android storage.
The problem with Linux supporting stuff forever is that some things really need to be retired once a better solution has come along. However so long as there are eCryptfs users out there, I don't think it's going to ever go away at this point.
I did the security review of the GCE serial port back when it first came into existence. We probably know each other. The tech industry really is tiny.
Yeah I just checked and you’re both listed as authors on the design doc (as am I, amusingly, though I really don’t remember doing anything particularly useful or significant for it).
Author of eCryptfs and EXT4 encryption chiming in.
"Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact.
That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn't encrypted. Which isn't to say that's a good tradeoff -- it's just the nature of the beast.
Because of performance and functionality issues (file name length, possibility of page cache inconsistency) eCryptfs shouldn't be used for anything any more.
Fast-forward 18 years, and it's fascinating to me to see people now seriously floating the proposal to support 256-bit pointers.