On 09/06/10 20:38, Gleb Kurtsou wrote: > Hello, > > I would like to ask for feedback on a kernel level stacked cryptographic > filesystem. It has started as Summer Of Code'2009 project and matured a > lot since then. I've recently added support for sparse files and > switched to XTS encryption mode. I've tried it and so far it works :) > 3. Mount pefs filesystem: > # pefs mount ~/Private ~/Private I see you've used the same example in the man page. Maybe it would be better for educational purposes to use two separate directories, e.g. ~/Private and ~/Decrypted to avoid confusion by new users (of course not all examples need to use this). > 6. Example how to save your key in keychain database. This is probably in line with what rwatson said (and would be covered by the same document): can you describe what keychains actually do? > 7. You can setup pam_pefs (not compiled by default) to add key to home > directory and authenticate against keychain database on login, e.g. by > adding the following line to /etc/pam.d/system before pam_unix.so: > > auth sufficient pam_pefs.so try_first_pass So, this would bypass passwd and let the user in if his password authenticates against the "keychain database" in his home directory? Will it automagically pefs-mount his home directory? > * Uses modern cryptographic algorithms: AES and Camellia in XTS mode, > PKCS#5v2 and HKDF for key generation. I do have an request: since you are already using kernel crypto support, it would be simple to just throw Blowfish in :) If for nothing else, consider it a gift to those who are fond of Blowfish's large key sizes (upto 448 bits). Actually, it would probably be seen as a reflection of consistency to implement the same algorithms that geli(8) implements. geli doesn't implement XTS yet - if your XTS code proves to be stable it would be a good thing to include it as standard and then use it from geli. I see you've copied SHA2 code to the pefs code. What is wrong with just using the kernel's SHA2 implementation?Received on Tue Sep 07 2010 - 12:27:32 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:07 UTC