Subject: Re: Revised MDC packet spec

From: [email-masked]
Date: Fri, 16 Jun 2000 14:40:07 -0700

Tom writes, quoting Werner:
> > One suggestion:  Add a note that the old PGP sync mode is not used with
> > the wew packet 18.  
>
> Did I miss something?  The description of the new type 18 packet
> indicates a prefix that looks like the PGP-sync prefix used elsewhere.
>
> But I didn't see the resync operation that is done everywhere else (I
> didn't read that carefully).
>
> So if I understand correctly, we are going to use the prefix but NOT
> going to do the resync?

That's correct.  This is for two reasons: one is that the sync is nonstandard
and has caused problems.  Perhaps someday we can deprecate the old symmetric
encryption packet and eliminate the sync altogether.  The second reason is
to make the encrypted data in these packets more different from the data in
the old packets, making it less likely that an attacker could turn a new
packet into an old one.

Maybe as Werner said the spec should have an explicit note confirming that
the sync is not done in this packet.

Hal

---

From: Jon Callas <[email-masked]>
Date: Fri, 16 Jun 2000 17:38:28 -0700

Or maybe we should just do the sync anyway.

It's one thing to not be standard, but it's another to not be consistent.
The only thing that one can complain about PGP-CFB for is that it's not
standard CFB. I don't see that as an issue.

Other systems, like CMS, use CBC mode not CFB at all, so we're no less
different even if we switch.

I would prefer to keep one encryption mode and use it everywhere. The one
to use, is of course PGP-CFB. However, if we're going to change it, we
should discuss using CBC mode.

	Jon

---

From: Tom Zerucha <[email-masked]>
Date: Sat, 17 Jun 2000 01:25:24 -0400

> should discuss using CBC mode.

I agree with this since I separate the operators from the core, though
cfb mode is one of the standard calls in openssl.  For all else I have
a cfbomatic routine.

However wasn't there something about NOT resetting if the block length
for the cipher was over 9 bytes in length?

Let me bring up another consideration (while looking for the above).

3.6.2.1...

   These are followed by an 8-octet Initial Vector for the decryption of
   the secret values, if they are encrypted, and then the secret key
   values themselves.

5.5.3...

     - [Optional] If secret data is encrypted, eight-octet Initial
       Vector (IV).

and

   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 bou

The symmetric ciphers are used more than one place - one is for
unlocking secret keys, and we have resyncs here.

So what happens for secret keys using a cipher with a 128 bit block
size?  Do we use 16 octet IVs?  Do we resync on mpi boundaries for a
V3 key (is this possible - I don't see anywhere in the spec where it
says you MUST use IDEA to encrypt V3 secret key material)?

(Actually I have a problem in my current opgp implementation since I
don't support block sizes other than 8 bytes (no, I refuse to always
use "octet"), but as soon as I can get the new algorithms going I know
where and how to fix it).