[1.4.0] hidden recipient vs. ID 00000000
dshaw at jabberwocky.com
Sat Jan 29 21:59:33 CET 2005
On Sat, Jan 29, 2005 at 09:15:06PM +0100, Florian Weimer wrote:
> * David Shaw:
> > On Fri, Jan 28, 2005 at 08:48:48PM +0100, Bernd Eckenfels wrote:
> >> On Fri, Jan 28, 2005 at 03:56:40PM +0100, Janos.Farkas-lists+priv-#RVXrkLgxX70*-gpg-dev at lists.xeon.eu.org wrote:
> >> > On 2005-01-27 at 15:07:33, David Shaw wrote:
> >> > > Try the attached patch. It changes the "no keyid" case to all FFs
> >> > > instead of zeroes. All FFs is as good as all zeroes here, especially
> >> > > since all zeroes is reserved.
> >> >
> >> > It's definitely less disturbing now, thanks! :)
> >> Is all-FF keyid a valid one? If yes this patch does not make it any better.
> >> Ie. it makes normal handling worse. Special values and in-band signalling
> >> sux pretty often.
> > All-FF and All-00 are both valid. All-00 is overloaded to mean
> > "anonymous recipient" on top of its usual meaning.
> > There is a small problem since a V3 key that isn't RSA is illegal
> > according to the spec. Quite literally, they have *no* key IDs. So
> > how should it be represented? The old code represented it as all-00.
> > The new code represents it as all-FF. Pick a value. They all have
> > problems.
> All-0 is not a valid V3 key ID because its LSB is not set. All-1 is
> theoretically valid, but rather unlikely (it imposes rather strict
> requirements on the lower bits in both prime factors).
True, but it doesn't matter in this case since all-0 and all-1 are
both valid in the context of the key ID in a session key packet since
v4 keys can be all-0 or all-1. Remember that the problem that started
this discussion is that an all-0 key ID conflicts with the anonymous
More information about the Gnupg-devel