From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51614)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1V4bde-0000XS-HZ
	for qemu-devel@nongnu.org; Wed, 31 Jul 2013 15:00:52 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1V4bVM-0006lX-BH
	for qemu-devel@nongnu.org; Wed, 31 Jul 2013 14:52:18 -0400
Received: from mx1.redhat.com ([209.132.183.28]:27455)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1V4b8o-0001am-Od
	for qemu-devel@nongnu.org; Wed, 31 Jul 2013 14:28:54 -0400
Message-ID: <51F957F2.808@redhat.com>
Date: Wed, 31 Jul 2013 20:31:14 +0200
From: Laszlo Ersek <lersek@redhat.com>
MIME-Version: 1.0
References: <20130723124706.GB5002@irqsave.net>
	<20130723130053.GW2477@redhat.com>
	<20130723144033.GE5002@irqsave.net>
	<20130723152247.GC14190@stefanha-thinkpad.redhat.com>
	<20130723153800.GD20225@dhcp-200-207.str.redhat.com>
	<20130723155741.GI2477@redhat.com> <51EFF30E.9060102@redhat.com>
	<20130731152714.GC4926@irqsave.net> <51F94EC8.5030203@redhat.com>
In-Reply-To: <51F94EC8.5030203@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] QCOW2 cryptography and secure key handling
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: =?ISO-8859-1?Q?Beno=EEt_Canet?= <benoit.canet@irqsave.net>
Cc: Kevin Wolf <kwolf@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org, stefanha@redhat.com, Stefan Hajnoczi <stefanha@gmail.com>

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 "sector_num" (like before),
- B1 (like before),
- to compute B_n from B(n-1), like before,
- two different trailing plaintext portions (each containing 496 bytes),
let's call them S0 and S1,
- (N+1) consecutive sectors in total.

You'd write the subject bitstring like this:

void compute_next_B(uint64_t B[2], uint64_t *sector_num)
{
    B[0] ^= (*sector_num ^ (*sector_num + 1));
    ++*sector_num;
}

void write_string(const char unsigned *subject_string, size_t N,
                  uint64_t sector_num)
{
    const char unsigned S[2][496] = {
        /* constant originally drawn from a good pseudo-random source */
    };
    uint64_t B[2] = { /* ditto */ };
    int i = 0;
    size_t n;

    write_sector(sector_num, B, S[i]);
    for (n = 0; n < N; ++n) {
        i ^= is_bit_set(subject_string, n);
        compute_next_B(B, &sector_num);
        write_sector(sector_num, B, S[i]);
    }
}

Just speculating...
Laszlo