Re: V3 secret keys

Ben Laurie <ben@algroup.co.uk> Fri, 03 February 2006 15:44 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5376-0004y3-Ae for openpgp-archive@megatron.ietf.org; Fri, 03 Feb 2006 10:44:44 -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 KAA11909 for <openpgp-archive@lists.ietf.org>; Fri, 3 Feb 2006 10:43:05 -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 k13FEkbs046903; Fri, 3 Feb 2006 07:14:46 -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 k13FEkVq046902; Fri, 3 Feb 2006 07:14:46 -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 k13FEjfu046895 for <ietf-openpgp@imc.org>; Fri, 3 Feb 2006 07:14:45 -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 AF21933C1C; Fri, 3 Feb 2006 15:14:43 +0000 (GMT)
Message-ID: <43E3736C.6030300@algroup.co.uk>
Date: Fri, 03 Feb 2006 15:14:52 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Adam Back <adam@cypherspace.org>
CC: "Daniel A. Nagy" <nagydani@epointsystem.org>, OpenPGP <ietf-openpgp@imc.org>
Subject: Re: V3 secret keys
References: <43E20DB6.30209@algroup.co.uk> <20060202140612.GA13906@epointsystem.org> <43E23D08.10806@algroup.co.uk> <20060202184601.GA20613@bitchcake.off.net>
In-Reply-To: <20060202184601.GA20613@bitchcake.off.net>
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

Adam Back wrote:
> The pgp263 docs say (not much better):
> 
> | One unusual point about the way encryption is done.  Using the IDEA
> | cipher in CFB mode, the first 10 bytes are decrypted normally, but
> | bytes 10 to 17, the first 8 bytes of the data proper, are encrypted
> | using bytes 2 to 9 (the last 8 bytes of the key check prefix) as the
> | IV.  This is essentially using CFB-16 for one part of the
> | encryption, while CFB-64 is used elsewhere.
> 
> So actually (I implemented this funky thing at some point to get
> compat with some parts of pgp) what it means is you encrypt normally
> with CFB-64 (encrypt previous 8 bytes, xor with plaintext).  When you
> get to one of these sync points, it may be part way thru a block, so
> you encrypt the short block as normal.  Then you take the previous 8
> bytes of ciphertext and use it as the IV and continue.
> 
> So it I think really is standard partial block encryption, but to
> resume after the block you take the last 8 bytes from the end of the
> previous ciphertext chunk and use as the IV for the next chunk.

OK, but this is how CFB works normally (at least, as implemented in
OpenSSL), so what you appear to be saying is that in v3 mode you carry
on as if the two plaintext bytes (the MPI length field) weren't there.
Right?

> 
> I agree what is written is pretty unclear.
> 
> Adam
> 
> On Thu, Feb 02, 2006 at 05:10:32PM +0000, Ben Laurie wrote:
>>>> Does it mean that the IV is reset to whatever it was at the start of the
>>>> current block? Does it mean that we use the partially-updated IV, but
>>>> set the position back to the beginning? Does it mean we reset the IV to
>>>> the initial value and start again? Or what?
>>>>
>>>> Cheers,
>>>>
>>>> Ben.
>>> It means the usual CFB synchronization with outputting a partial block and
>>> shifting the IV.
>> If that means anything at all, you appear to be describing standard CFB
>> when applied to a partial block, which I assume the above is not.
>>
>> -- 
>> 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
> 
> 


-- 
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