On 07/31/13 17:27, Benoît Canet wrote:
>> For example, current qcow2 encryption is vulnerable to a watermarking
>> attack.
>> http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_chaining_.28CBC.29
>
> void qcow2_encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
>
On 07/31/13 19:52, Laszlo Ersek wrote:
> You'll end up with two identical sectors in the encrypted image.
Apologies for following up on my own message...
If you want to store an arbitrary N bit long bit-string (a watermark)
that is visible in the encrypted image, then you need:
- a good guess at
> For example, current qcow2 encryption is vulnerable to a watermarking
> attack.
> http://en.wikipedia.org/wiki/Disk_encryption_theory#Cipher-block_chaining_.28CBC.29
void qcow2_encrypt_sectors(BDRVQcowState *s, int64_t sector_num,
uint8_t *out_buf, const uint8_t *in_bu
> Crypto should be done by trained professionals[*].
I agree I feel uneasy to write cryptographic code.
Best regards
Benoît
Le Monday 29 Jul 2013 à 12:32:35 (+0100), Daniel P. Berrange a écrit :
> On Mon, Jul 29, 2013 at 01:25:24PM +0200, Kevin Wolf wrote:
> > Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben:
> > > Paolo Bonzini writes:
> > >
> > > > Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
> > > >>
On Mon, Jul 29, 2013 at 01:25:24PM +0200, Kevin Wolf wrote:
> Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben:
> > Paolo Bonzini writes:
> >
> > > Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
> > >> On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote:
> > >>> Am 23.07.2013
Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben:
> Paolo Bonzini writes:
>
> > Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
> >> On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote:
> >>> Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben:
> On Tue, Jul 23, 2013 at
Paolo Bonzini writes:
> Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
>> On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote:
>>> Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben:
On Tue, Jul 23, 2013 at 04:40:34PM +0200, Benoît Canet wrote:
>> More generally, QCow2's
On Wed, Jul 24, 2013 at 05:40:14PM +0200, Paolo Bonzini wrote:
> Il 24/07/2013 17:33, Daniel P. Berrange ha scritto:
> >>> One reason that QCow2 is bad, despite using a standard algorithm, is
> >>> that the user passphrase is directly used encrypt/decrypt the data.
> >>> Thus a weak passphrase lead
Il 24/07/2013 17:33, Daniel P. Berrange ha scritto:
>>> One reason that QCow2 is bad, despite using a standard algorithm, is
>>> that the user passphrase is directly used encrypt/decrypt the data.
>>> Thus a weak passphrase leads to weak data encryption. With the LUKS
>>> format, the passphrase is
On Wed, Jul 24, 2013 at 05:30:22PM +0200, Paolo Bonzini wrote:
> Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
> > On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote:
> >> Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben:
> >>> On Tue, Jul 23, 2013 at 04:40:34PM +0200, Benoît Ca
Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
> On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote:
>> Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben:
>>> On Tue, Jul 23, 2013 at 04:40:34PM +0200, Benoît Canet wrote:
> More generally, QCow2's current encryption support is
> There are two ways I could see it happening. Either integrate directly
> into the qcow2 file format, by mapping LUKS headers & key material
> blocks into the qcow2 header region in some manner.
>
> Alternatively do it in a completely generic block driver, that qcow2
> (or any other qemu bdrv) ca
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
On Tue, Jul 23, 2013 at 05:38:00PM +0200, Kevin Wolf wrote:
> Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben:
> > 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 PO
Am 23.07.2013 um 17:22 hat Stefan Hajnoczi geschrieben:
> 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 d
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
> > qco
> 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
>
> > Do you (the block maintainers) have an idea on how the code could be
> > improved
> > to securely pass the crypto key to the QCOW2 code ?
>
> 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
>
On Tue, Jul 23, 2013 at 02:47:06PM +0200, Benoît Canet wrote:
>
> Hi,
>
> I have some budget to improve QCOW2's cryptography.
>
> My main concern is that the QCOW2 image crypto key is passed in clear text.
That is only a problem if someone can sniff the communications channel
used by the monito
20 matches
Mail list logo
