Subject: Re: Glitch in section 3.2

From: [email-masked]
Date: Wed, 2 May 2001 10:37:11 -0700

Florian Weimer, <[email-masked]>, writes:
> >From the current draft:
>
> | 3.2. Multi-Precision Integers
>
> |    The length field of an MPI describes the length starting from its
> |    most significant non-zero bit. Thus, the MPI [00 02 01] is not
> |    formed correctly. It should be [00 01 01].
>
> I think it's worthwhile to point out that MPIs with an arbitrary
> number of leading zeroes might legitimately occur inside V3 secret key
> packets.  Perhaps it's even necessary to amend section 5.5.3 to
> clarify this issue (i.e. that leading zeroes MUST NOT be stripped in
> this case).

Why is this?  Are you worried about leaking information about the size
of p, q, etc.?

Hal

---

From: Florian Weimer <[email-masked]>
Date: 02 May 2001 20:39:32 +0200

> Why is this?  Are you worried about leaking information about the size

No, the cause is completely different.  The unencrypted actual MPI
determines the bit length and should not include any leading zeroes,
but encryption might introduce them (and it's probably not wise to
adjust the bit length accordingly).

-- 
Florian Weimer 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---

From: "Michael Young" <[email-masked]>
Date: Wed, 2 May 2001 17:27:21 -0400

-----BEGIN PGP SIGNED MESSAGE-----

> adjust the bit length accordingly).

This sounds like a bug I found in the OpenPGP engine inside Mixmaster
2.9beta23...  it (wrongly) treats the encrypted data as an MPI and
puts out the wrong bit count.  (Note that the "encrypted MPI" could
have a bit count that's a whole byte or more shorter.  The bit
counting in Mix2.9b23 serendipitously avoids an accident here.)
This resulted in other PGP versions reporting checksum errors
(because they did not adjust the bit count after decrypting).

All that said, this is an implementation bug, not a spec issue.

---

From: Jon Callas <[email-masked]>
Date: Thu, 3 May 2001 12:05:49 -0700

One thing to remember about IETF specs, especially format specifications,
is that they describe input and output, not implementation.

An implementation is free to store any of these data structures in any way
they see fit. You're free to convert them in memory, or put them in a
database in whatever is convenient to you. What 2440, and other IETF specs
really say are:

* If you write out the structures in this format, and another
implementation doesn't accept them, it's the reader's problem.

* If you read in a structure that is not in this format, and you don't feel
like compensating, it's writer's problem.

You are always free to correctly read things that don't meet the spec!
Remember the IETF meta-rule, "be conservative in what you emit, and
generous in what you accept." Following this guideline, accepting an MPI
with extra leading zeroes is a fine thing to do, but you really ought to
write it out with no extra leading zeroes.

Here's a different example. Suppose you were making an OpenPGP
implementation for a cell phone. You need it to be small. It's therefore
perfectly acceptable to always write out packets with 5-byte lengths, thus
saving on code size, but you still need to *read* the other packet lengths.

On a slightly related issue, OpenPGP encourages, but does not require
compatibility with PGP 2.6. Nothing in the spec forbids you from reading in
a V3 key, and immediately converting it to a V4 key internally and using
it. It might be polite to be able to re-export it in V3 format -- and you
might get catcalls from the user community if you didn't -- but you don't
*have* to to be OpenPGP compliant. One can even argue that we're getting
close to when we should start deprecating V3 structures. The known flaws
keep piling up.

	Jon
--