V3 secret keys

Ben Laurie <ben@algroup.co.uk> Mon, 06 February 2006 18:23 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6B1A-0000Yp-Om for openpgp-archive@megatron.ietf.org; Mon, 06 Feb 2006 13:23:30 -0500
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10107 for <openpgp-archive@lists.ietf.org>; Mon, 6 Feb 2006 13:21:15 -0500 (EST)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id k16I1poU063950; Mon, 6 Feb 2006 10:01:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id k16I1pe8063949; Mon, 6 Feb 2006 10:01:51 -0800 (PST)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id k16I1oK6063943 for <ietf-openpgp@imc.org>; Mon, 6 Feb 2006 10:01:51 -0800 (PST) (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 573A233C45 for <ietf-openpgp@imc.org>; Mon, 6 Feb 2006 18:01:49 +0000 (GMT)
Message-ID: <43E78E94.5070902@algroup.co.uk>
Date: Mon, 06 Feb 2006 17:59:48 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: OpenPGP <ietf-openpgp@imc.org>
Subject: V3 secret keys
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>
Content-Transfer-Encoding: 7bit

OK, I had to resort to reading the PGP 2 source to find out what was
going on here.

In essence its fairly simple, but is _definitely_ no explained by the I-D.

Firstly, v3 CFB does not use the IV in a standard way. Instead, what it
does instead is set the IV to all zeroes and then decrypt the IV and
throw away the result.

Secondly, as I think was correctly explained by someone here (but I
didn't get it, sorry), when "resynchronisation" occurs it means "set the
IV to the last 8 bytes of ciphertext".

Note that for any standard-sized key resynchronisation does _not_ occur,
so people who think they've implemented it from AC are in for a surprise
one day.

Obviously the I-D should be updated to reflect this (and clearly no-one
has ever implemented v3 keys from it).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"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