Usefull encrypted storage require you to provide password (or something) for mounting said storage... and then there's this problem of automaticaly dismounting it when you're idle or log off...
Well, I figured... we've already got such mechanism ( as far as encrypting and keys go ) from faboulous gentoo folks, and it's called keychain, this provides key management identical to what we need for encrypted storage (your keys are encrypted, you provide the key at the start of the session, the key is deleted at the end of session according to your preferences).
The thing here to notice, is that such setup already is in place, while encrypted storage is something that is relatively hard to set up, the problem of when your keys should expire sometimes is handled, sometimes not...anyhoo, it would be nice if such key management would be kept in one, well-defined and researched place.
Or would it?
The fastest approach I see is to just use ssh-mounted filestytem via lufs, this way implementation on client-side would be trivial, now, the problem would be that the data would not really be encrypted... But, here where perl enters, and things start getting interesting, what if instead real ssh server, there sits this dummy server that takes keys from ssh session and uses them to encrypt/decrypt data from disk?
This idea needs polishing (like, is this even good idea to try and intregrate storage of keys for ssh-access and for encrypted data, I couldn't find anything seriously wrong with this concept), but at this point I'm wondering about test implementation, I looked at Net::SSH, and IPC::Session, and it seems like such feat would require significant digging in sshd internal... thus would not be the fastest approach afterall
Another approach would be to just extract keys from keychain agents, and use them for encryption... but that wouldn't work to well with existing setups because keys would get extracted once, and then the storage would be accessible until reboot... and that's not what I want.
Of course there are ways to solve it - for example, write daemon for lufs, and let it require keys for every filesystem operation... this would be disastrous from performance point of view, but that wouldn't be a priority in encrypted filesystem where implementation language is perl (and where hooks from lufs are used)
|
|---|