Re: Loop-AES and kernel access key retention

[Alon Bar-Lev <alon.barlev@xxxxxxxxx>]

Jari Ruusu wrote:
> Alon Bar-Lev wrote:
>> I've just went through some of the eCryptfs code and I've
>> noticed they are using the kernel access key retention to
>> move keys from user space into kernel. It looks quite clean
>> implementation so that it does not require any patch to
>> util-linux.

Thank you for your reply!

> (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.

> (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 :)

> (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:

---

#include <linux/key.h>
<snip>
#define KEY_PAYLOAD_DATA(key) \
        (((struct user_key_payload*)key->payload.data)->data)
#define KEY_PAYLOAD_LEN(key) \
        (((struct user_key_payload*)key->payload.data)->datalen)
<snip>
        auth_tok_key = request_key(&key_type_user,

mount_crypt_stat->global_auth_tok_sig,
                                   NULL);
        if (!auth_tok_key || IS_ERR(auth_tok_key)) {
                ecryptfs_printk(KERN_ERR, "Could not find
key with "
                                "description: [%s]\n",

mount_crypt_stat->global_auth_tok_sig);
                process_request_key_err(PTR_ERR(auth_tok_key));
                rc = -EINVAL;
                goto out;
        }
        auth_tok = (struct ecryptfs_auth_tok
*)KEY_PAYLOAD_DATA(auth_tok_key);

---

> (4) Mainline linux motto is: "there is no stable API" which usually
>     translates to "don't bother writing code to this API". I have seen too
>     may interfaces change/break under my feet that I am reluctant to add
>     another dependency to another possibly wildly changing API.

OK. It was just an idea... I thought it is simple enough to
support it. But I understand your position.

Best Regards,
Alon Bar-Lev.


-
Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/