Just to close the loop with the list. I thought the tempfs idea was good and that took me down learning about that. Which ended up with me actually running into some docs on using luks and dm-crypt to do an encrypted volume via /etc/fstab and /etc/crypttab, which seemed like a plenty good enough solution for what I wanted, so that's what I'm currently pursuing. In all the documentation for the cryptsetup stuff, they use '/dev/urandom' as the "key file" for things like temporary partitions and swap encryption. I'm not sure if that would work with ecryptfs as well, but just thought I'd throw it out there. --Eric On Tue, Dec 10, 2013 at 10:34 PM, Michael Chang <m9chang@xxxxxxxxxxxx> wrote: > What if you create the key in a file stored on tmpfs? Then it > shouldn't leave RAM, right? > > On Tue, Dec 10, 2013 at 7:46 PM, Eric Tschetter <echeddar@xxxxxxxxx> wrote: >> Hello all, >> >> I apologize if this is an easy question, but I've been Googling around >> for an answer with no luck and the man pages aren't helping, so I'm >> asking here. If this is documented somewhere, feel free to just point >> me there. >> >> For context, I want to setup an ecryptfs volume with an ephemeral key. >> I do *not* want the key stored anywhere. I want to never, ever be >> able to access the data again upon restart. I actually want to be >> forced to start over from nothing upon restart. >> >> From looking at the options for starting up ecryptfs, it looks like >> they all either require the key to be in a file or available in the >> history/ps/etc.: >> >> passphrase_passwd=(passphrase) >> passphrase_passwd_file=(filename) >> passphrase_passwd_fd=(file descriptor) >> passphrase_salt=(hex value) >> openssl_keyfile=(filename) >> openssl_passwd_file=(filename) >> openssl_passwd_fd=(file descriptor) >> openssl_passwd=(password) >> >> I'd rather not even store the key in a file and then remove the file, >> because technically that file might get persisted to disk and remain >> there after the delete. The only thing I can think of is that maybe >> there is something magical you can do with file descriptors to get it >> to store the key in memory, have a file descriptor point to that >> memory location and then destroy the fd and memory. >> >> I'm unfortunately not that well-versed in how this would work though, >> so before diving down that potential rabbit hole was hoping to get >> some guidance from people on this list. >> >> All help is appreciated. >> >> --Eric >> -- >> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > -- > Thanks, > > Michael Chang > 4B Software Engineering (Class of 2014) > University of Waterloo -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
