Re: Utterly Confused by Resync

Ben Laurie <> Thu, 02 March 2006 12:30 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FEmxD-0005IT-DV for; Thu, 02 Mar 2006 07:30:47 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1FEmxC-0003xv-0t for; Thu, 02 Mar 2006 07:30:47 -0500
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id k22Bsjh8088326; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id k22Bsj2s088325; Thu, 2 Mar 2006 04:54:45 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id k22BsiRX088318 for <>; Thu, 2 Mar 2006 04:54:44 -0700 (MST) (envelope-from
Received: from [] (localhost []) by (Postfix) with ESMTP id A106F33C1C; Thu, 2 Mar 2006 11:54:43 +0000 (GMT)
Message-ID: <>
Date: Thu, 02 Mar 2006 11:54:50 +0000
From: Ben Laurie <>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Hal Finney <>
Subject: Re: Utterly Confused by Resync
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
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.




"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