Re: Utterly Confused by Resync

hal@finney.org ("Hal Finney") Wed, 01 March 2006 18:05 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVhR-0005nO-OT for openpgp-archive@lists.ietf.org; Wed, 01 Mar 2006 13:05:21 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEVhQ-0000Lr-Cu for openpgp-archive@lists.ietf.org; Wed, 01 Mar 2006 13:05:21 -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 k21HUOaQ062287; Wed, 1 Mar 2006 10:30:24 -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 k21HUO4e062286; Wed, 1 Mar 2006 10:30:24 -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 finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k21HUMdQ062248 for <ietf-openpgp@imc.org>; Wed, 1 Mar 2006 10:30:23 -0700 (MST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id D665657FAF; Wed, 1 Mar 2006 09:35:27 -0800 (PST)
To: ben@algroup.co.uk, ietf-openpgp@imc.org
Subject: Re: Utterly Confused by Resync
Message-Id: <20060301173527.D665657FAF@finney.org>
Date: Wed, 01 Mar 2006 09:35:27 -0800
From: hal@finney.org
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.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca

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.

Hal Finney