Re: V3 secret keys

hal@finney.org ("Hal Finney") Tue, 07 February 2006 20:34 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6ZY0-00071Z-1Q for openpgp-archive@megatron.ietf.org; Tue, 07 Feb 2006 15:34:50 -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 PAA27439 for <openpgp-archive@lists.ietf.org>; Tue, 7 Feb 2006 15:32:49 -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 k17KG4fK095799; Tue, 7 Feb 2006 12:16:04 -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 k17KG4Z6095798; Tue, 7 Feb 2006 12:16:04 -0800 (PST)
X-Authentication-Warning: above.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 above.proper.com (8.12.11/8.12.9) with ESMTP id k17KG26P095792 for <ietf-openpgp@imc.org>; Tue, 7 Feb 2006 12:16:03 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id B07EF57FAF; Tue, 7 Feb 2006 12:19:45 -0800 (PST)
To: ben@algroup.co.uk, hal@finney.org
Subject: Re: V3 secret keys
Cc: ietf-openpgp@imc.org
Message-Id: <20060207201945.B07EF57FAF@finney.org>
Date: Tue, 07 Feb 2006 12:19:45 -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>

Ben Laurie writes:
> Hal Finney wrote:
> > The IV is used in the standard way.  You may be
> > thinking of symmetrically encrypted data packets, which work as you
> > say here.  V3 private keys are standard.
>
> Experiment and code reading/running says it is correct.

I rechecked my source code and I can confirm my statement.  The IV is
used in the standard way for V3 secret key CFB encryption.  The line is

	PGPInitCFB(*cfbp, key, buf + alglen);

This initializes the CFB context in the first argument, using the key
in the 2nd argument and the IV in the 3rd argument.  In this case the
IV is buf+alglen where buf is a pointer into the secret key data and
alglen is the offset past the S2K stuff.  If we were using an all-zeros
IV as Ben suggests then we would have had to set up a buffer to act as
the IV, fill it with zeros, and pass that to the PGPInitCFB function.
We don't do that.

(This is an important point because if it doesn't work as I have
described, then the spec is completely wrong and it would be extremely
important to change it ASAP.  So I hope Ben or others can confirm that
the spec is right on this matter.)

> > The last sentence is the one which is problematic.  What if we changed
> > it to:
> > 
> >    Furthermore, at the beginning of each MPI value after the first,
> >    the CFB state is re-synchronized to its initial state, with the IV
> >    for that MPI taken as the last 8 octets of the ciphertext of the
> >    previous MPI value.
> > 
> > Note that V3 keys only support ciphers with a block size of 8 bytes, so
> > I think it is OK to explicitly say "8 octets" here.

(As noted, I was mistaken about this 8-octet restriction.)

> "re-synchronised to its initial state" is perhaps not entirely clear -
> wouldn't it better to just say the IV is set to the last 8 octets of the
> previous ciphertext and not mention initial state?

The problem is that "IV" is not necessarily well defined in the middle
of a CFB.  You are using it synonymously with the chaining vector (or
whatever other term you want to use).  The "I" of "IV" means Initial,
so the IV is the value used "initially" to begin the CFB operation.
I am afraid that people would not know what to do if all we said was to
change the IV to such-and-such, in the middle of a CFB stream.  That's why
I said to go back to the "initial state" of the CFB and then what the IV
would be.  In the initial state, the concept of the IV is well defined.
I think that will be clearer to an implementor.

Maybe "re-synchronized" is unclear; how about if we said "... the CFB
state is reset to its initial state, with the IV for that MPI taken as..."

Hal Finney