Skip to contentSkip to conversation

cryptsetup alternate storage backend

dm-crypt Benoît Canet 2 participants 3 messages Jul 24, 2013 – Jul 29, 2013

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 6 lines · Benoît Canet

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.

Quoted 6 lines

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

#2 lore raw

Hello,

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

Quoted 1 line

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.

Quoted 1 line

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