Alon Bar-Lev wrote: > Jari Ruusu wrote: > > (1) Keyctl userland-to-kernel interface is based on strings, and encrypted > > loops want hashed binary data. Not compatible without extra tricks. > > I am under the impression that it can hold binary data. You > can pipe data to it. I've tried it and it works. Keyctl does strlen() on the key string. Null bytes won't work. > > (2) Userspace utilities make no attempt to overwrite secret key material > > after they are done with it. Serious newbie goofs. > > Well... If this was the only problem, I would have worked > with the author to fix it to your satisfaction :) It would need a user space program to be written anyway. The keys need to be hashed, in userspace. Doing that in kernel would be insane. > > (3) Significant amounts of loop would need to be rewritten because ioctl() > > and request_key() interfaces are so different, yet the benefits would be > > almost zero. > > I am under the impression that it should be quite easy. I've > looked at the eCryptfs code: I quickly read the code and it looked like that request_key() may sleep. Code paths were this request_key() would be inserted, may not sleep for any significant amount of time. It holds locks. Locking re-write -> not funny. There are many missing bits: For example, where do offset= and sizelimit= options come from if they are not in /etc/fstab and parsed by mount and losetup. -- Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD - Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
