headers
Florian Weimer | 2 May 2001 18:33
Picon
Favicon

Glitch in section 3.2

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

Well, maybe it's a good idea to stress already in section 3.2 that
implementations must be able to handle overlong MPI values
transparently.

(As you might guess, there's at least one implementations which gets
this wrong. ;-)

--

-- 
Florian Weimer 	                  Florian.Weimer <at> RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
Permalink | Reply | 2 comments |
headers
Werner Koch | 2 May 2001 19:29
Picon
Favicon

Re: Glitch in section 3.2

On Wed, 2 May 2001, Florian Weimer wrote:

> 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

I don't think we should bloat the RFC with hints on how to implement
stuff needed for legacy keys.  OpenPGP is already large enough.

> (As you might guess, there's at least one implementations which gets
> this wrong. ;-)

At least the last versions of GnuPG got it wrong.

  Werner

--

-- 
Werner Koch        Omnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH      et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions                                        -- Augustinus
Permalink | Reply | 1 comment |
headers
hal | 2 May 2001 19:37

Re: Glitch in section 3.2

Florian Weimer, <Florian.Weimer <at> RUS.Uni-Stuttgart.DE>, 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
Permalink | Reply | 503 comments |
headers
Florian Weimer | 2 May 2001 20:39
Picon
Favicon

Re: Glitch in section 3.2

hal <at> finney.org writes:

> Florian Weimer, <Florian.Weimer <at> RUS.Uni-Stuttgart.DE>, 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.?

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 	                  Florian.Weimer <at> RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
(Continue reading)

Permalink | Reply | 502 comments |
headers
Florian Weimer | 2 May 2001 21:20
Picon
Favicon

Re: Glitch in section 3.2

Werner Koch <wk <at> gnupg.org> writes:

> I don't think we should bloat the RFC with hints on how to implement
> stuff needed for legacy keys.  OpenPGP is already large enough.

I don't think V3 keys are legacy, at least not before the expiration
date protocol error is addressed in some way.

--

-- 
Florian Weimer 	                  Florian.Weimer <at> RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
Permalink | Reply | 0 comments |
headers
hal | 2 May 2001 21:40

Re: Glitch in section 3.2

> > Florian Weimer, <Florian.Weimer <at> RUS.Uni-Stuttgart.DE>, writes:
> > > 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).
>
> 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).

Oh, I see what you mean.  I don't think they should be considered
MPIs while in the encrypted state.  They are encrypted MPI values.
Even though the bit length prefix is left in the clear, they are not to
be interpreted as MPIs until after decrypting.

Hal
Permalink | Reply | 1 comment |
headers
Florian Weimer | 2 May 2001 22:13
Picon
Favicon

Re: Glitch in section 3.2

hal <at> finney.org writes:

> Oh, I see what you mean.  I don't think they should be considered
> MPIs while in the encrypted state.  They are encrypted MPI values.
> Even though the bit length prefix is left in the clear, they are not to
> be interpreted as MPIs until after decrypting.

This is all true, but the OpenPGP spec doesn't separate unencrypted
and encrypted MPI, they are treated in the same manner.

--

-- 
Florian Weimer 	                  Florian.Weimer <at> RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898
Permalink | Reply | 0 comments |
headers
Michael Young | 2 May 2001 23:27

Re: Glitch in section 3.2


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

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.
Permalink | Reply | 3 comments |
headers
Dominikus Scherkl | 3 May 2001 11:45
Favicon

Zero MPI

Hi!

Has anybody thought about how to store the value 0 (zero) in an MPI?
(I don't think that was used for any of the yet-supported algorithms,
but it may occure in ECC).
The standard implies, that it must be stored as the two octets
[00 00] and that no additional zeroes may be added. (In fact,
we have no chance to determine the end of an oversized zero-MPI,
because no non-zero octets must follow - a sequence of four zeros
could be a single padded zero-MPI or two non-padded zero-MPIs.)

Is this correct so far?
But how do current implementations behave this case?
Do they pad? How about v3 encoding (the complete value is left
unencoded but what does the cipher with the zero-lenght string?

--

-- 
Dominikus Scherkl
Permalink | Reply | 0 comments |
headers
Jon Callas | 3 May 2001 21:05
Gravatar

Re: Glitch in section 3.2

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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane