Howdy folks!
Thanks for working on nettle,
pgp_put_public_rsa_key seems to throw an assertion error:
assert(buffer->size == start + length)
buffer->size is 3 larger than (start + length).
Removing the PGP_LENGTH_TWO_OCTETS works (but this is wrong, since 4880 defines it as it's written, I think, still new with the spec), so I think there might be a bug in the assert.
Can someone who groks the code confirm this?
Thanks! Paul
Paul Tagliamonte paultag@gmail.com writes:
pgp_put_public_rsa_key seems to throw an assertion error:
Note that the pgp functions in Nettle are undocumented and unfinished. Cool that anybody else is having a look at them.
Can someone who groks the code confirm this?
Can't say I really grok the code either, I wrote those functions back in 2007... But it looks fishy to me with two calls to pgp_put_header, using the same tag value PGP_TAG_PUBLIC_KEY. If you have read the spec recently, is there any way that could be correct?
I'd suggest deleting the second call to pgp_put_header (the one with the PGP_LENGTH_TWO_OCTETS argument). The the correct body length should be passed to the first pgp_put_header call, and the variable start, and the assert, check that we really generate a packet body matching that length.
In case you'd like to try to get some more of the pgp code in shape, additional testcases would be a good place to start.
The way I remember it, I tried passing the generated pckets to gpg, but it was a bit difficult to get any interoperability by supporting only the "new" openpgp formats. Things might have changed since then, of course.
Regards, /Niels
Good morning, Niels,
On Tue, Oct 15, 2013 at 08:46:36AM +0200, Niels Möller wrote:
pgp_put_public_rsa_key seems to throw an assertion error:
Note that the pgp functions in Nettle are undocumented and unfinished.
Yeah, I noticed that in the source; but that never stoped me before! :)
Cool that anybody else is having a look at them.
Yeah! I've been a bit keen to learn a bit more about PGP in general, so I figured I'd play around. Lo and behold I get the chance to read some spec as well.
Can someone who groks the code confirm this?
Can't say I really grok the code either, I wrote those functions back in 2007... But it looks fishy to me with two calls to pgp_put_header, using the same tag value PGP_TAG_PUBLIC_KEY.
Yeah, to me as well.
If you have read the spec recently, is there any way that could be correct?
I don't know yet. It seems like no, at least not for v4. After sending this email, I tried to implement it myself a bit, and got a bit further. My gut's telling me there's something wonky there.
I'd suggest deleting the second call to pgp_put_header (the one with the PGP_LENGTH_TWO_OCTETS argument). The the correct body length should be passed to the first pgp_put_header call, and the variable start, and the assert, check that we really generate a packet body matching that length.
Aye. I have that in a local copy of the function, but gpg was kicking back exported keys - I'm thinking I might have to hack a bit on it.
In case you'd like to try to get some more of the pgp code in shape, additional testcases would be a good place to start.
I think I'll do that, thank you!
The way I remember it, I tried passing the generated pckets to gpg, but it was a bit difficult to get any interoperability by supporting only the "new" openpgp formats. Things might have changed since then, of course.
ACK. I'll see what I can learn / document.
Regards, /Niels
Thanks for the quick reply! Paul
-- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
nettle-bugs@lists.lysator.liu.se
-
nisse＠lysator.liu.se -
Paul Tagliamonte