Crypto should be done by trained professionals[*].
I agree I feel uneasy to write cryptographic code.
Best regards
Benoît
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_buf,
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
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,
Paolo Bonzini pbonz...@redhat.com 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,
Am 29.07.2013 um 13:21 hat Markus Armbruster geschrieben:
Paolo Bonzini pbonz...@redhat.com 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,
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 pbonz...@redhat.com 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
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 pbonz...@redhat.com writes:
Il 23/07/2013 17:57, Daniel P. Berrange ha scritto:
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) calls
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 woefully
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 Canet
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 only used
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 leads to weak
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.
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 ?
Best regards
Benoît
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 monitor
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
best to
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
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
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 deprecate
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 POV. If we
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
21 matches
Mail list logo
