Subject: fingerprint hash material in 12.2.

From: Stephan Beyer <[email-masked]>
Date: Mon, 30 Apr 2007 17:52:24 +0200

Hi,

in section 12.2., the text says, that _the_ two-octet packet length
comes after the 0x99 octet.

Does that mean, that the public key data may not be larger than 65536
bytes?

If so: Is that stated anywhere?
And... is this good? Considering permanently growing key sizes or the
possible existence of practically useful public key algorithms using
(for example) a variable number of integers[1].

So, if there is no 64k limit on public key data, a further question
occurs:
Is the "two-octet packet length" the packet length modulo 65536?[2]
But then, isn't the
	a.2) high order length octet of (b)-(f) (1 octet)	[3]
some kind of "second low order length octet"? ;-)

Or is (a.2) the "most significant octet of the length" while (a.3) is 
the "least significant octet"? ;-)

I looked what GnuPG does, and - note the first comment - ...
 -- snip g10/keyid.c --
  /* What does it mean if n is greater than than 0xFFFF ? */
  md_putc( md, n >> 8 );   /* 2 byte length header */
  md_putc( md, n );
 -- snap --
...they use the "modulo 65536" variant. ;-)

Kind Regards,
Stephan Beyer

Footnotes:
 1. Although it is not considered secure, think of a knapsack-based
    methods with n integers.
 2. By the way, is it correct to say "packet length" when you don't
    actually mean the length of the packet, but the length of
    (b)-(e) in the example? ;-)
 3. Note, that there is a further mistake: (f) doesn't even exist.
    The list ends with (e).

-- 
Stephan Beyer <[email-masked]>, PGP 0x6EDDD207FCC5040F

---

From: Jon Callas <[email-masked]>
Date: Mon, 30 Apr 2007 13:08:16 -0700

> (for example) a variable number of integers[1].

I'm only going to answer parts of your question.

This really isn't an issue. Right now, just about everyone uses only  
4k public keys. 4k bits is 512 bytes. Even if you need several 4k bit  
numbers, there's plenty of room.

The long-term issue we face is crypto-balance with 256-bit symmetric  
algorithms. NIST estimates a 15k-bit key to be balanced with AES-256.  
While plenty of people disagree with that, we all agree that we're  
not going to crypto-balance RSA with AES. It would be annoying and slow.

Long term, we're going to move to elliptic curve, and those keys are  
smaller. Crypto-balance would be at about 512 bits, and thus it fits  
in just fine.

However, let me just assume that next week someone invents Magic  
Dingus Encryption, which has the advantage that it is not only ten  
times faster than ECC, but is proven immune to quantum computers as  
well as mental telepathy. The downside is that the public keys are  
128k bytes in size.

In such a case, when we write the RFC for MDE in OpenPGP, we would  
need to state how you compute the fingerprint of an MDE key in that  
RFC. That's it. (And as a matter of fact, when we do ECC for OpenPGP,  
we'll have to specify the ECC parameters for fingerprints in whatever  
RFC specifies ECC for OpenPGP.)

The reason why it specifies in 12.2 the precise length is that in  
OpenPGP there are often many ways to state a length. Thus, we have to  
state precisely how to compute the fingerprint, because don't want to  
end up with a to-may-to/to-mah-to issue in computing fingerprints.  
That's it.

	Jon