[dm-crypt] cryptsetup alternate storage backend

[dm-crypt] cryptsetup alternate storage backend

[Benoît Canet]

Hello,

I am a QEMU block developper.

Since this thread : "https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03902.html"
I am wondering if QEMU could reuse libcryptsetup implementation of LUKS to
improve QCOW2's cryptography.

QEMU have it's own block layer and APIs so how hard would it be to make
libcryptsetup read and write the luks headers and slots into some buffers or how
hard would it be to write an abstration to access the QEMU block layer ?

(I did not find an obvious answer to these questions by having a glance at the
code.)

Best regards

Benoît

Re: [dm-crypt] cryptsetup alternate storage backend

[Milan Broz]

On 24.7.2013 17:09, Benoît Canet wrote:
> I am a QEMU block developper.
>
> Since this thread : "https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03902.html"
> I am wondering if QEMU could reuse libcryptsetup implementation of LUKS to
> improve QCOW2's cryptography.
>
> QEMU have it's own block layer and APIs so how hard would it be to make
> libcryptsetup read and write the luks headers and slots into some buffers or how
> hard would it be to write an abstration to access the QEMU block layer ?
>
> (I did not find an obvious answer to these questions by having a glance at the
> code.)

Hi,

there are two separate layers which create two separate problems
(Paolo mentioned it in thread above).

1) dm-crypt main "encryption engine" implemented in kernel which provides
the real transparent block device encryption.
It is highly configurable but it takes plain encryption key as parameter.

2) LUKS, as a simple key management tool, which only stores and unlocks strong
encryption key (through passphrase or keyfile).

You need to implement both. I do not want to comment if QEMU is going
to reimplement dmcrypt (or just some subset) inside its block code.
(TBH you do not need to implement much, AES-XTS with simple sector
number as IV for now will be enough.)

For LUKS - you can use LUKS container for sure but it will not be easy
with current libcryptsetup (in QEMU context).
(e.g. it now requires activation of temporary dmcrypt device for keyslots handling.
Once this requirement is removed, it is easy to do create some embedded wrapper
for any application.
But this internal dmcrypt dependence removal is not trivial. Anyway, I want to do it,
perhaps very soon. It will allow LUKS handling without root privilege as well.)

So we can provide better implementation (and API extension) here if there is
a potential user for it.
(My goal is to allow easy multiplatform use of metadata formats.
We can read truecrypt headers already and one day there will be LUKS2,
you will get this for free if you use libcryptsetup... :)

Do you have some better specification what do you need from libcryptsetup?
And do you need this code to be portable to other OS environment as well, correct?

Thanks,
Milan

Re: [dm-crypt] cryptsetup alternate storage backend

[Benoît Canet]

Hello,

We have some work to tackle before being able to implement dm-crypt in QEMU.
But it would like the following.

> Do you have some better specification what do you need from libcryptsetup?
I was thinking of a way to give libcryptsetup a structure containing some files
operation which would be implemented by QEMU.

something like
struct crypt_fops {
    .read
    .write
    .open
    .close
    .wipe
    .sync
}

The call would look like
cryptsetup_register_fops(struct crypt_fops *f);

This way other potentials users of libcryptsetup could implement their own fops
and link against it.

> And do you need this code to be portable to other OS environment as well, correct?
Yes QEMU is cross platform.

Best regards

Benoît