headers
Daniel Kahn Gillmor | 27 Jun 07:47
Face

lib/opencdk/read-packet.c: read_s2k() implementation

Hey folks--

After wrapping my head around the relevant section of RFC 4880 and
bits of opencdk, i've fleshed out the previously unimplemented opencdk
internal function intended to interpret OpenPGP String-To-Key
transformations, read_s2k() in read-packet.c.

Attached, please find the patch for this function.  Inspection with a
debugger shows that the values being stored are congruent with what is
expected in other uses of the cdk_s2k_t construct.

After my first draft of this patch, i noticed that similar code
already existed in the read_symkey_enc() function (also in
lib/opencdk/read-packet.c).  So instead of publishing my first draft,
i've collapsed the code for these two so that there's a canonical
implementation of reading s2k values present in the opencdk codebase.
The attached patch reflects this approach.

This change should not affect the API or ABI at all, and it allows
GnuTLS to recognize encrypted secret keys (though it cannot yet use
them, afaict).

This patch was done against Andreas Metzler's 2.4.0-2 package of
gnutls that is currently in debian/unstable.

As always, feedback is welcome.

Regards,

        --dkg
(Continue reading)

Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 27 Jun 12:21

Re: lib/opencdk/read-packet.c: read_s2k() implementation

Hello Daniel,
 In a few days I'll merge with the new opencdk code in the development
branch (changes almost all code), thus I'd appreciate if you could
port your patch there.

regards,
Nikos

On Fri, Jun 27, 2008 at 8:50 AM, Daniel Kahn Gillmor
<dkg-debian.org <at> fifthhorseman.net> wrote:
> Hey folks--
>
> After wrapping my head around the relevant section of RFC 4880 and
> bits of opencdk, i've fleshed out the previously unimplemented opencdk
> internal function intended to interpret OpenPGP String-To-Key
> transformations, read_s2k() in read-packet.c.
>
> Attached, please find the patch for this function.  Inspection with a
> debugger shows that the values being stored are congruent with what is
> expected in other uses of the cdk_s2k_t construct.
>
> After my first draft of this patch, i noticed that similar code
> already existed in the read_symkey_enc() function (also in
> lib/opencdk/read-packet.c).  So instead of publishing my first draft,
> i've collapsed the code for these two so that there's a canonical
> implementation of reading s2k values present in the opencdk codebase.
> The attached patch reflects this approach.
>
> This change should not affect the API or ABI at all, and it allows
> GnuTLS to recognize encrypted secret keys (though it cannot yet use
(Continue reading)

Permalink | Reply |
headers
Daniel Kahn Gillmor | 27 Jun 17:01
Face

Re: lib/opencdk/read-packet.c: read_s2k() implementation

On Fri 2008-06-27 06:21:12 -0400, Nikos Mavrogiannopoulos wrote:

>  In a few days I'll merge with the new opencdk code in the
> development branch (changes almost all code), thus I'd appreciate if
> you could port your patch there.

It's not clear to me what branch you're specifically talking about.  I
see no branches named anything like "new opencdk" or "development" --
do you mean "gnutls_with_ext_mpi" ?

In my message on the "2.6.x goals" thread [0], i asked if me doing
work on these would be likely to collide with anyone else's work, and
got no response from you.  It would be useful for collaboration if we
can communicate with each other about this sort of thing.  Sorry for
the miscommunication from my end!

If the branch you're referring to *is* gnutls_with_ext_mpi, then it's
not clear to me how to port this properly.  CDK_PKT_SYMKEY_ENC is the
packet type whose parser contained the code i ended up moving into
read_s2k.  But CDK_PKT_SYMKEY_ENC appears to have been removed from
opencdk.h on the gnutls_with_ext_mpi branch, despite being clearly
defined in the standard [1].  Any reason this was removed?  It seems
like a useful packet type for OpenCDK to be able to handle.

I'm attaching an (untested) patch against the gnutls_with_ext_mpi
branch, which at least fleshes out the read_s2k function.

It's untested because when i still don't know how to build from the
git repo.  The developer's site says [2] "Build GnuTLS/libtasn1 by
running 'make' twice (once to run autoreconf and configure and another
(Continue reading)

Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 27 Jun 21:05

Re: lib/opencdk/read-packet.c: read_s2k() implementation

Daniel Kahn Gillmor wrote:
> On Fri 2008-06-27 06:21:12 -0400, Nikos Mavrogiannopoulos wrote:
> 
>>  In a few days I'll merge with the new opencdk code in the
>> development branch (changes almost all code), thus I'd appreciate if
>> you could port your patch there.
> 
> It's not clear to me what branch you're specifically talking about.  I
> see no branches named anything like "new opencdk" or "development" --
> do you mean "gnutls_with_ext_mpi" ?

Yes this is the branch and sorry for any inconvenience this might have
caused to you. I'm working on this branch but due to my very limited
free time I couldn't safely merge with the rest of the code. I plan to
do it this weekend.

> In my message on the "2.6.x goals" thread [0], i asked if me doing
> work on these would be likely to collide with anyone else's work, and
> got no response from you. 

Probably I missed this email. Sorry again for any inconvenience.

> If the branch you're referring to *is* gnutls_with_ext_mpi, then it's
> not clear to me how to port this properly.  CDK_PKT_SYMKEY_ENC is the
> packet type whose parser contained the code i ended up moving into
> read_s2k.  But CDK_PKT_SYMKEY_ENC appears to have been removed from
> opencdk.h on the gnutls_with_ext_mpi branch, despite being clearly
> defined in the standard [1].  Any reason this was removed?  It seems
> like a useful packet type for OpenCDK to be able to handle.
(Continue reading)

Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 28 Jun 11:06

Re: lib/opencdk/read-packet.c: read_s2k() implementation

Daniel Kahn Gillmor wrote:
> On Fri 2008-06-27 06:21:12 -0400, Nikos Mavrogiannopoulos wrote:
> 
> It's not clear to me what branch you're specifically talking about.  I
> see no branches named anything like "new opencdk" or "development" --
> do you mean "gnutls_with_ext_mpi" ?

The gnutls_with_ext_mpi branch has now been merged into master.

regards,
Nikos
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 5 Jul 10:21

some opencdk history (was: lib/opencdk/read-packet.c: read_s2k() implementation)

Daniel Kahn Gillmor wrote:
> After wrapping my head around the relevant section of RFC 4880 and
> bits of opencdk, i've fleshed out the previously unimplemented opencdk
> internal function intended to interpret OpenPGP String-To-Key
> transformations, read_s2k() in read-packet.c.
> 
> Attached, please find the patch for this function.  Inspection with a
> debugger shows that the values being stored are congruent with what is
> expected in other uses of the cdk_s2k_t construct.
> 
> After my first draft of this patch, i noticed that similar code
> already existed in the read_symkey_enc() function (also in
> lib/opencdk/read-packet.c).  So instead of publishing my first draft,
> i've collapsed the code for these two so that there's a canonical
> implementation of reading s2k values present in the opencdk codebase.
> The attached patch reflects this approach.
> 
> This change should not affect the API or ABI at all, and it allows
> GnuTLS to recognize encrypted secret keys (though it cannot yet use
> them, afaict).

Hello Daniel,

 I've finally found some time to check your patch and I have some
remarks. The first is about patches in opencdk. The opencdk library
included in gnutls is a crippled version of the "full" opencdk library
by Timo Schulz. This crippling was done for mainly two reasons. The full
opencdk library contained GPL code that forced us to include the openpgp
support only in libextra, and the second is that we only wanted to
include the parts of opencdk we used.
(Continue reading)

Permalink | Reply |
headers
Daniel Kahn Gillmor | 8 Jul 17:52
Face

Re: some opencdk history

On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote:

>  I've finally found some time to check your patch and I have some
> remarks. The first is about patches in opencdk. The opencdk library
> included in gnutls is a crippled version of the "full" opencdk
> library by Timo Schulz. This crippling was done for mainly two
> reasons. The full opencdk library contained GPL code that forced us
> to include the openpgp support only in libextra, and the second is
> that we only wanted to include the parts of opencdk we used.

Cool, thanks for the explanation, Nikos.  Are you saying that the
OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then?
That they currently fall under the LGPL instead?  I know that there
has been a lot of changes recently, but i haven't followed them
closely enough to know here.

Was it necessary to remove the pieces that were removed *because* they
were only under the GPL, not the LGPL?  

Was there a copyright assignment over the OpenCDK sources to the FSF?
If so, is the FSF willing to consider re-licensing the code under LGPL
so that we can include all the functionality instead of just part of
it?

> Thus if you or anyone wants to add anything to gnutls' opencdk it
> might be appropriate to check the older opencdk library if it
> contains the code and is under LGPL. This still will require some
> porting (since now the included opencdk uses gnutls' internal api)
> but that wouldn't be that difficult.
(Continue reading)

Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 9 Jul 18:48

Re: some opencdk history

Daniel Kahn Gillmor wrote:
> On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote:
> 
>>  I've finally found some time to check your patch and I have some
>> remarks. The first is about patches in opencdk. The opencdk library
>> included in gnutls is a crippled version of the "full" opencdk
>> library by Timo Schulz. This crippling was done for mainly two
>> reasons. The full opencdk library contained GPL code that forced us
>> to include the openpgp support only in libextra, and the second is
>> that we only wanted to include the parts of opencdk we used.
> Cool, thanks for the explanation, Nikos.  Are you saying that the
> OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then?
> That they currently fall under the LGPL instead?  I know that there
> has been a lot of changes recently, but i haven't followed them
> closely enough to know here.
> Was it necessary to remove the pieces that were removed *because* they
> were only under the GPL, not the LGPL?  

This wasn't the only reason. Of course the GPL parts had to be removed,
but there were also some other parts under LGPL that we didn't use at
that time in gnutls and/or required some rewritting, so they were also
dropped.

> Was there a copyright assignment over the OpenCDK sources to the FSF?
> If so, is the FSF willing to consider re-licensing the code under LGPL
> so that we can include all the functionality instead of just part of
> it?

Yes the FSF has relicensed all the parts of opencdk that we needed for
proper openpgp certificate support in gnutls. Those are the parts that
(Continue reading)

Permalink | Reply |
headers
Ludovic Courtès | 9 Jul 23:23

Re: some opencdk history

Hi,

Nikos Mavrogiannopoulos <nmav <at> gnutls.org> writes:

> Daniel Kahn Gillmor wrote:
>> On Sat 2008-07-05 01:21:56 -0700, Nikos Mavrogiannopoulos wrote:
>> 
>>>  I've finally found some time to check your patch and I have some
>>> remarks. The first is about patches in opencdk. The opencdk library
>>> included in gnutls is a crippled version of the "full" opencdk
>>> library by Timo Schulz. This crippling was done for mainly two
>>> reasons. The full opencdk library contained GPL code that forced us
>>> to include the openpgp support only in libextra, and the second is
>>> that we only wanted to include the parts of opencdk we used.
>> Cool, thanks for the explanation, Nikos.  Are you saying that the
>> OpenPGP pieces of GnuTLS themselves are now *not* in libextra, then?
>> That they currently fall under the LGPL instead?  I know that there
>> has been a lot of changes recently, but i haven't followed them
>> closely enough to know here.
>> Was it necessary to remove the pieces that were removed *because* they
>> were only under the GPL, not the LGPL?  
>
> This wasn't the only reason. Of course the GPL parts had to be removed,
> but there were also some other parts under LGPL that we didn't use at
> that time in gnutls and/or required some rewritting, so they were also
> dropped.

Still, the Guile bindings keep providing OpenPGP support as part of the
`(gnutls extra)' module, released under the GPLv3+, not the LGPL.  Does
that mean they're not in sync with core GnuTLS (which wouldn't
(Continue reading)

Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 10 Jul 19:10

Re: some opencdk history

Ludovic Courtès wrote:

> Still, the Guile bindings keep providing OpenPGP support as part of the
> `(gnutls extra)' module, released under the GPLv3+, not the LGPL.  Does
> that mean they're not in sync with core GnuTLS (which wouldn't
> necessarily be a problem)?

Indeed it should be moved to the core library.

regards,
Nikos
Permalink | Reply |
headers
Ludovic Courtès | 10 Jul 21:14

Re: some opencdk history

Hi,

Nikos Mavrogiannopoulos <nmav <at> gnutls.org> writes:

> Ludovic Courtès wrote:
>
>> Still, the Guile bindings keep providing OpenPGP support as part of the
>> `(gnutls extra)' module, released under the GPLv3+, not the LGPL.  Does
>> that mean they're not in sync with core GnuTLS (which wouldn't
>> necessarily be a problem)?
>
> Indeed it should be moved to the core library.

Yes, but that would cause an incompatibility for little in return, so I
thing we'd be better off leaving things as they are.

Thanks,
Ludovic.
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 9 Jul 18:49

Re: some opencdk history

Daniel Kahn Gillmor wrote:

> With the patch, GnuTLS can create a gnutls_openpgp_privkey_t from such
> a key.  It won't be able to manipulate the key cleanly for any purpose
> that requires access to the secret MPIs themselves because they are
> locked, but GnuTLS will still be able to do all of the pubkey
> functions with that key.  For example, It should still be possible to
> get the fingerprint of the key without knowing the secret MPIs.

What will happen if someone tries to access the MPIs?
Permalink | Reply |
headers
Daniel Kahn Gillmor | 10 Jul 04:40
Face

Re: some opencdk history

On Wed 2008-07-09 12:49:59 -0400, Nikos Mavrogiannopoulos wrote:

> What will happen if someone tries to access the MPIs?

The MPIs associated with a locked secret key are currently set to
NULL, so they are rejected by GnuTLS -- attempts to export them result
in an error (-50, i believe), but no crash.

      --dkg

_______________________________________________
Gnutls-devel mailing list
Gnutls-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/gnutls-devel
Permalink | Reply |
headers
Nikos Mavrogiannopoulos | 12 Jul 11:17

Re: some opencdk history

Daniel Kahn Gillmor wrote:
> On Wed 2008-07-09 12:49:59 -0400, Nikos Mavrogiannopoulos wrote:
> 
>> What will happen if someone tries to access the MPIs?
> 
> The MPIs associated with a locked secret key are currently set to
> NULL, so they are rejected by GnuTLS -- attempts to export them result
> in an error (-50, i believe), but no crash.

I don't know if this is enough. We should have a way to indicate that
this key is encrypted otherwise it would not be distinguishable from
broken keys. Do you have something in mind for that?
Permalink | Reply |

Gmane