Re: V3 secret keys

hal@finney.org ("Hal Finney") Mon, 06 February 2006 22:48 UTC

Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6FA3-0003PD-4a for openpgp-archive@megatron.ietf.org; Mon, 06 Feb 2006 17:48:45 -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 RAA16746 for <openpgp-archive@lists.ietf.org>; Mon, 6 Feb 2006 17:46:43 -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 k16MYOOu017816; Mon, 6 Feb 2006 14:34:24 -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 k16MYO8R017815; Mon, 6 Feb 2006 14:34:24 -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 k16MYLEm017809 for <ietf-openpgp@imc.org>; Mon, 6 Feb 2006 14:34:21 -0800 (PST) (envelope-from hal@finney.org)
Received: by finney.org (Postfix, from userid 500) id 7087157FAE; Mon, 6 Feb 2006 14:38:01 -0800 (PST)
To: ben@algroup.co.uk, ietf-openpgp@imc.org
Subject: Re: V3 secret keys
Message-Id: <20060206223801.7087157FAE@finney.org>
Date: Mon, 06 Feb 2006 14:38:01 -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:
> 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.

This is not correct. 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.

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

Right.

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

This will usually be the case; p and q will be forced to be a multiple
of 8 bytes (64 bits) for keys of usual sizes.  But d, which is e inverse
mod lambda(n) would be shorter sometimes.  lambda(n) is lcm(p-1,q-1) so
lambda will be at least 1 bit shorter (since p-1 and q-1 are both even)
and perhaps 2 bits shorter with probability about 1/2 (in case p-1 and
q-1 have other small common factors).  Independently, d may be shorter
than lambda.  Put it all together and maybe one key in 70 or so would
have a d value which is 1 byte shorter, requiring resynchronization.

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

The current text is not inaccurate, but does rely on knowing what
"resynchronized" means.  Since this is a non-standard term we should
explain it better.  Here is the current text:

    Encryption/decryption of the secret data is done in CFB mode using
    the key created from the passphrase and the Initial Vector from the
    packet. A different mode is used with V3 keys (which are only RSA)
    than with other key formats. With V3 keys, the MPI bit count prefix
    (i.e., the first two octets) is not encrypted.  Only the MPI
    non-prefix data is encrypted.  Furthermore, the CFB state is
    resynchronized at the beginning of each new MPI value, so that the
    CFB block boundary is aligned with the start of the MPI data.

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.

Hal Finney