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
- Utterly Confused by Resync Ben Laurie
- Re: Utterly Confused by Resync "Hal Finney"
- Re: Utterly Confused by Resync Ben Laurie