Re: Utterly Confused by Resync

Ben Laurie <ben@algroup.co.uk> Thu, 02 March 2006 12:30 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEmxD-0005IT-DV for openpgp-archive@lists.ietf.org; Thu, 02 Mar 2006 07:30:47 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEmxC-0003xv-0t for openpgp-archive@lists.ietf.org; Thu, 02 Mar 2006 07:30:47 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22Bsjh8088326; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k22Bsj2s088325; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22BsiRX088318 for <ietf-openpgp@imc.org>; Thu, 2 Mar 2006 04:54:44 -0700 (MST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id A106F33C1C; Thu, 2 Mar 2006 11:54:43 +0000 (GMT)
Message-ID: <4406DD0A.4010103@algroup.co.uk>
Date: Thu, 02 Mar 2006 11:54:50 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Hal Finney <hal@finney.org>
CC: ietf-openpgp@imc.org
Subject: Re: Utterly Confused by Resync
References: <20060301173527.D665657FAF@finney.org>
In-Reply-To: <20060301173527.D665657FAF@finney.org>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955

Hal Finney wrote:
> Ben Laurie writes:
>> I just implemented the Symmetrically Encrypted Data packet.
>>
>> It also does a "resync" after the first blocksize+2 bytes. However, I
>> find that, unlike the MPI resync for v3 keys, as well as wiggling around
>> the IV I have to encrypt it.
>>
>> That is, the resync operation for MPI looks like this:
>>
>> 1. Set the IV to the last blocksize bytes of ciphertext
>> 2. Set the offset within the IV to zero.
>>
>> Whereas for the Symmetrically Encrypted Data resync looks like:
>>
>> 1. Set the IV to the last blocksize bytes of ciphertext
>> 2. Encrypt the IV
>> 3. Set the offset within the IV to zero.
>>
>> Can this possibly be right? Does the spec explain this at all?
> 
> The resync operation is the same for encrypted data packets as for
> V3 keys.  There is a difference between the two cases, but it doesn't
> involve the resync.  The difference is that V3 keys use a regular IV,
> while encrypted data packets use an IV of 0 and then discard the first
> blocksize+2 bytes.  But that does not affect the resync; the resync is
> done exactly in the same way.
> 
> CFB works like this.  Encrypting plaintext block N starts with the
> ciphertext of block N-1. Encrypt that ciphertext and then XOR the result
> with plaintext block N to get ciphertext block N.  For the 1st block,
> where there is no previous ciphertext block, the IV is used.  Encrypt the
> IV and XOR with the 1st plaintext block to get the 1st ciphertext block.
> 
> The resync operation can be though of as setting the IV to the previous
> blocksize bytes of ciphertext, and starting this process from the
> beginning.  Encrypt the IV, XOR with the 1st bytes of the plaintext,
> and you get your ciphertext.
> 
> This will work for both encrypted data packets and for V3 private keys.
> Your description fo the data packet case says as step 2, encrypt the IV.
> I don't know how to interpret that.  Of course you encrypt the IV, it
> is part of the CFB process as I just described.  Is that all you mean?
> Or do you think you encrypt the IV twice?  Is that what you are implying?
> That would not work.
> 
> The details of encryption for data packets are described in RFC2440bis
> in section 12.8.  It's a cumbersome and wordy description but if you read
> it carefully it will hopefully shed light on what you need to do.

I'm hesitant to say definitively I'm right, after the previous debacle,
but... my resync function does _not_ perform an encryption, all it does
is wriggle around the previous and current IVs, and it works fine with
V3 keys.

After I have called resync for the symmetric encrypted data packet, I
have to encrypt the new IV, or it doesn't work. If I add the encrypt
step to the resync, it breaks V3 keys.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff