encryption

encryption

[Henry Noack]

Hello you guys,


it is possible to decrypt a kvm volume only by using the command line 
after starting it?


Best regards
Henry

Re: encryption

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]

On Mon, Feb 16, 2015 at 06:19:04PM +0100, Henry Noack wrote:
> it is possible to decrypt a kvm volume only by using the command line after
> starting it?

Encryption can be done at 3 levels:

1. Inside the guest.  Just like you do on a physical machine with LUKS
   (dm-crypt), ecryptfs, TrueCrypt, etc.

2. In QEMU with qcow2, although this feature is not widely used and not
   up to modern disk encryption standards.

3. On the host using LUKS (dm-crypt), ecryptfs, TrueCrypt, etc or on the
   storage appliance.

It depends what you are trying to achieve.

Keep in mind that encrypting the disk image does not stop the host from
seeing inside the guest.  The host is always trusted, today's
virtualization technology has this limitation.

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: encryption

[Markus Armbruster]

Stefan Hajnoczi <stefanha@gmail.com> writes:

> On Mon, Feb 16, 2015 at 06:19:04PM +0100, Henry Noack wrote:
>> it is possible to decrypt a kvm volume only by using the command line after
>> starting it?
>
> Encryption can be done at 3 levels:
[...]
> 2. In QEMU with qcow2, although this feature is not widely used and not
>    up to modern disk encryption standards.

Quoting the fine manual:

          The use of encryption in qcow and qcow2 images is considered
          to be flawed by modern cryptography standards, suffering from
          a number of design problems:

             − The AES-CBC cipher is used with predictable
               initialization vectors based on the sector number.  This
               makes it vulnerable to chosen plaintext attacks which can
               reveal the existence of encrypted data.
             − The user passphrase is directly used as the encryption
               key.  A poorly chosen or short passphrase will compromise
               the security of the encryption.
             − In the event of the passphrase being compromised there is
               no way to change the passphrase to protect data in any
               qcow images.  The files must be cloned, using a different
               encryption passphrase in the new file.  The original file
               must then be securely erased using a program like shred,
               though even this is ineffective with many modern storage
               technologies.

          Use of qcow / qcow2 encryption is thus strongly discouraged.
          Users are recommended to use an alternative encryption
          technology such as the Linux dm-crypt / LUKS system.

[...]

Re: Encryption

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Thu, Dec 13, 2012 at 09:23:05AM -0800, merc1984@f-m.fm wrote:
> 
> On Thu, Dec 13, 2012, at 1:17, Sander wrote:
> Forbids? That is just plain wrong.
> I have one btrfs filesystem on top of two encrypted devices. Works just
> fine.
> 
> That's dynamite Sander.
> 
> But I am not going to contravene the instructions, then have problems,
> only to come back here and have fingers wagged in my face telling me
> this is all EXPERIMENTAL!

   Well, I'm afraid that applies to the information on the wiki, too
-- that's also experimental, to a degree. The notes on the wiki about
behaviour of encryption layers weren't added by any of the core
developers. Nobody's published concrete tests *either* way yet, and
those comments are one person's opinion, as far as I'm aware (and note
that they don't actually quote sources, results, or even personal
experience).

   YMMV.

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
        --- Great oxymorons of the world, no. 2: Common Sense ---        

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: Encryption

[merc1984]

On Thu, Dec 13, 2012, at 1:17, Sander wrote:
Forbids? That is just plain wrong.
I have one btrfs filesystem on top of two encrypted devices. Works just
fine.

That's dynamite Sander.

But I am not going to contravene the instructions, then have problems,
only to come back here and have fingers wagged in my face telling me
this is all EXPERIMENTAL!

-- 
http://www.fastmail.fm - Send your email first class

Re: Encryption

[Sander]

merc1984@f-m.fm wrote (ao):
> Oh pardon me, it's BTRFS RAID that's a no-go, which is just as critical
> to me as I have a 4 disk 8TB array.
> The FAQ goeth on to Say:
> -----------------------------------------------------------
> This pretty much forbids you to use btrfs' cool RAID features if you
> need encryption.

Forbids? That is just plain wrong.

I have one btrfs filesystem on top of two encrypted devices. Works just
fine.

	Sander

Re: Encryption

[cwillu]

On Wed, Dec 12, 2012 at 2:06 PM,  <merc1984@f-m.fm> wrote:
> On Wed, Dec 12, 2012, at 10:48, cwillu wrote:
>> Sayeth the FAQ:
>
> Oh pardon me, it's BTRFS RAID that's a no-go, which is just as critical
> to me as I have a 4 disk 8TB array.
> The FAQ goeth on to Say:
> -----------------------------------------------------------
> This pretty much forbids you to use btrfs' cool RAID features if you
> need encryption. Using a RAID implementation on top of several encrypted
> disks is much slower than using encryption on top of a RAID device. So
> the RAID implementation must be on a lower layer than the encryption,
> which is not possible using btrfs' RAID support.
>  -----------------------------------------------------------
>
> You saw that I need RAID above.  Were you just trying to criticize my
> memory of the FAQ cwillu?

It's not asking for trouble, it's just asking for poor performance,
and I suspect even that will depend greatly on the workload.

Snapshots still have nothing to do with it:  you could have btrfs
(with snapshots) on dm-crypt on mdraid.  Btrfs would just lose the
ability to try alternate mirrors and similar; snapshots would still
work just fine.

Re: Encryption

[merc1984]

On Wed, Dec 12, 2012, at 10:48, cwillu wrote:
> Sayeth the FAQ:

Oh pardon me, it's BTRFS RAID that's a no-go, which is just as critical
to me as I have a 4 disk 8TB array.
The FAQ goeth on to Say:
-----------------------------------------------------------
This pretty much forbids you to use btrfs' cool RAID features if you
need encryption. Using a RAID implementation on top of several encrypted
disks is much slower than using encryption on top of a RAID device. So
the RAID implementation must be on a lower layer than the encryption,
which is not possible using btrfs' RAID support.
 -----------------------------------------------------------

You saw that I need RAID above.  Were you just trying to criticize my
memory of the FAQ cwillu?


-- 
http://www.fastmail.fm - Accessible with your email software
                          or over the web

Re: Encryption

[cwillu]

On Wed, Dec 12, 2012 at 12:38 PM,  <merc1984@f-m.fm> wrote:
>
> On Wed, Dec 12, 2012, at 10:31, Mitch Harder wrote:
>> I run btrfs on top of LUKS encryption on my laptop.  You should be able to do the same.
>>
>> You could then run rsync through ssh.  However, rsync will have no knowledge of any blocks shared under subvolume snapshots.
>>
>> Btrfs does not yet have internal encryption.

> The FAQ says specifically to NOT run BTRFS with any kind of volume
> encryption, so you're asking for trouble.

Sayeth the FAQ:

Does Btrfs work on top of dm-crypt?
This is deemed safe since 3.2 kernels. Corruption has been reported
before that, so you want a recent kernel. The reason was improper
passing of device barriers that are a requirement of the filesystem to
guarantee consistency.

> And clearly encryption is not possible if you need snapshots.

Snapshots don't come into this at all:  btrfs doesn't care where the
block devices it's on come from.  Things like dm-crypt show btrfs (or
whatever filesystem you put on it) a decrypted view of the device.

Re: Encryption

[merc1984]

On Wed, Dec 12, 2012, at 10:31, Mitch Harder wrote:
> I run btrfs on top of LUKS encryption on my laptop.  You should be able to do the same.
>
> You could then run rsync through ssh.  However, rsync will have no knowledge of any blocks shared under subvolume snapshots.
>
> Btrfs does not yet have internal encryption.

The FAQ says specifically to NOT run BTRFS with any kind of volume
encryption, so you're asking for trouble.

And clearly encryption is not possible if you need snapshots.

-- 
http://www.fastmail.fm - One of many happy users:
  http://www.fastmail.fm/help/overview_quotes.html

Re: Encryption

[Mitch Harder]

On Wed, Dec 12, 2012 at 11:12 AM,  <merc1984@f-m.fm> wrote:
>
> So there is no way to have filesystem encryption, while keeping
> snapshots?
>
>

I run btrfs on top of LUKS encryption on my laptop.  You should be
able to do the same.

You could then run rsync through ssh.  However, rsync will have no
knowledge of any blocks shared under subvolume snapshots.

Btrfs does not yet have internal encryption.

Re: Encryption

[merc1984]

So there is no way to have filesystem encryption, while keeping
snapshots?


On Fri, Dec 7, 2012, at 8:16, [2]merc1984@f-m.fm wrote:

> We're using a backups server to back up all machines in a LAN.  Four 2TB disks are assembled in a BTRFS RAID array and mounted as /media/backups.  Under this are subvolumes droog, hex, etc, and snapshots droog_snap-{date1}, hex_snap-{date1}, etc.

> Goal is to encrypt backups, but the concern is with snapshots.  Won't piping rsync through encryption with GPG or somesuch, play havoc with BTRFS snapshot accounting?

> Is there any way to encrypt an array so it is inaccesible while umounted?

> I've already asked on the ecryptfs listserv and it resulted in mass confusion.

--


-- 
http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again

Re: Encryption

[Josef Bacik]

On Thu, Jan 20, 2011 at 07:05:52AM -0800, Carl Cook wrote:
> 
> Does BTRFS have subvolume encryption built in?  If not, why?
> 

No, and because nobody has done it yet.  Thanks,

Josef

Re: Encryption

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

On Thu, Jan 20, 2011 at 07:05:52AM -0800, Carl Cook wrote:
> 
> Does BTRFS have subvolume encryption built in?  If not, why?

   Not at the moment.

   My opinion on why: Getting crypto right is *hard*. There are far
easier features that people are asking for that we can implement
first.

   There may be technical issues that make it hard to implement within
btrfs, although being able to do compression is harder from a FS
structure point of view, so I suspect that the issues are more about
ensuring correctness of the crypto implementation (not just the basic
symmetric algorithm, because we've got those in the kernel, but all
the key management and block chaining and probably a bunch of things I
don't know about because I'm not a cryptographer -- all of which makes
a big difference to the security of the final system).

   Hugo.

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
     --- Once is happenstance; twice is coincidence; three times ---     
                            is enemy action.                             

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Encryption

[Carl Cook]

Does BTRFS have subvolume encryption built in?  If not, why?

Re: Encryption

[Edward Shushkin]

Hans Reiser wrote:
> 
> Yury Umanets wrote:
> 
> > Pierre Abbat wrote:
> >
> >> How is filesystem encryption going to work? Or has anyone figured
> >> that out yet?
> >>
> >> phma
> >>
> >>
> > Don't worry, it is going up :)
> >
> Edward, please provide a serious answer including your design documents,
> so that the list can review your design and comment. 
> Chances are that
> they will make at least one serious improvement to the design...

Ok, it will be very nice.
Edward.

.. and
> it might be nice to get that improvement made before you have made the
> time investment required to debug.....
> 
> --
> Hans

Re: Encryption

[Hans Reiser]

Yury Umanets wrote:

> Pierre Abbat wrote:
>
>> How is filesystem encryption going to work? Or has anyone figured 
>> that out yet?
>>
>> phma
>>  
>>
> Don't worry, it is going up :)
>
Edward, please provide a serious answer including your design documents, 
so that the list can review your design and comment.  Chances are that 
they will make at least one serious improvement to the design..... and 
it might be nice to get that improvement made before you have made the 
time investment required to debug.....

-- 
Hans

Re: Encryption

[Yury Umanets]

Pierre Abbat wrote:

>How is filesystem encryption going to work? Or has anyone figured that out 
>yet?
>
>phma
>  
>
Don't worry, it is going up :)

-- 
Yury Umanets

Encryption

[Pierre Abbat]

How is filesystem encryption going to work? Or has anyone figured that out 
yet?

phma
-- 
.i toljundi do .ibabo mi'afra tu'a do
.ibabo damba do .ibabo do jinga
.icu'u la ma'atman.