[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Loop-AES and kernel access key retention
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/