All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: "Benoît Canet" <benoit.canet@irqsave.net>,
	kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] QCOW2 cryptography and secure key handling
Date: Tue, 23 Jul 2013 16:40:03 +0100	[thread overview]
Message-ID: <20130723154003.GH2477@redhat.com> (raw)
In-Reply-To: <20130723152247.GC14190@stefanha-thinkpad.redhat.com>

On Tue, Jul 23, 2013 at 05:22:47PM +0200, Stefan Hajnoczi wrote:
> On Tue, Jul 23, 2013 at 04:40:34PM +0200, Benoît Canet wrote:
> > > More generally, QCow2's current encryption support is woefully inadequate
> > > from a design POV. If we wanted better encryption built-in to QEMU it is
> > > best to just deprecate the current encryption support and define a new
> > > qcow2 extension based around something like the LUKS data format. Using
> > > the LUKS data format precisely would be good from a data portability
> > > POV, since then you can easily switch your images between LUKS encrypted
> > > block device & qcow2-with-luks image file, without needing to re-encrypt
> > > the data.
> > 
> > I read the LUKS specification and undestood enough part of it to understand the
> > potentials benefits (stronger encryption key, multiple user keys, possibility to
> > change users keys).
> > 
> > Kevin & Stefan: What do you think about implementing LUKS in QCOW2 ?
> 
> Using standard or proven approachs in crypto is a good thing.  I haven't
> looked at qcow2 encryption in the past because fairly few people
> actually use it.
> 
> One use-case I have heard about is qcow2 files over NFS.  The network
> and the storage system should not see guest data.  Only the host and the
> VM should see the data.

Yep, that is the core usecase. You are securing the system such that
only the VM host administrator/processes can compromise the data. It
is protected against malicious storage and/or network administrators.

> A big win with LUKS is that you can change the passphrase without
> re-encrypting the data.

Other benefits of LUKs are

 - Strong encryption key, even if the passphrase itself is weak
 - Support for multiple passphrases
 - Support for arbitrary different encryption algorithms / settings
 - Ability to detect whether the passphrase is correct or not rather
   than just decrypting to produce garbage

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

      parent reply	other threads:[~2013-07-23 16:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23 12:47 [Qemu-devel] QCOW2 cryptography and secure key handling Benoît Canet
2013-07-23 13:00 ` Daniel P. Berrange
2013-07-23 13:21   ` Benoît Canet
2013-07-23 14:40   ` Benoît Canet
2013-07-23 15:22     ` Stefan Hajnoczi
2013-07-23 15:38       ` Kevin Wolf
2013-07-23 15:57         ` Daniel P. Berrange
2013-07-24 13:07           ` Benoît Canet
2013-07-24 15:30           ` Paolo Bonzini
2013-07-24 15:33             ` Daniel P. Berrange
2013-07-24 15:40               ` Paolo Bonzini
2013-07-24 15:46                 ` Daniel P. Berrange
2013-07-29 11:21             ` Markus Armbruster
2013-07-29 11:25               ` Kevin Wolf
2013-07-29 11:32                 ` Daniel P. Berrange
2013-07-29 16:07                   ` Benoît Canet
2013-07-31 15:33               ` Benoît Canet
2013-07-31 15:27             ` Benoît Canet
2013-07-31 17:52               ` Laszlo Ersek
2013-07-31 18:31                 ` Laszlo Ersek
2013-07-23 15:40       ` Daniel P. Berrange [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130723154003.GH2477@redhat.com \
    --to=berrange@redhat.com \
    --cc=benoit.canet@irqsave.net \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.