Mailing List Archive

On Sun, 22 Jun 2003 19:00:10 +0300, Nikos Mavroyanopoulos said:

> Is there any chance into including RC2 in libgcrypt? Without
> it, it is not possible to create a real pkcs-12 packet parser.

As I already told here, PC2 is patented and anyway obsolete. We won't
include it. Furthermore importing a 40 bit RC2 encoded certificate
is really silly as this can be broken trivially and it must be assumed
that such a certificate has already ben compromised.

> An RC2 implementation under the public domain can be found at:
> ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/rc2/rrc2.tar.gz

There is nothing like public domain in most European countries and
such the legel status of such an implementation might get us in trouble
later on.

--
Werner Koch <wk@gnupg.org>
The GnuPG Experts http://g10code.com
Free Software Foundation Europe http://fsfeurope.org

On Tue, Jun 24, 2003 at 08:43:25AM +0200, Werner Koch wrote:

> > Is there any chance into including RC2 in libgcrypt? Without
> > it, it is not possible to create a real pkcs-12 packet parser.
> As I already told here, PC2 is patented and anyway obsolete. We won't
No RC2 is not patented. As far as I know it has the same status as RC4
(was a trade secret). There is also an informational RFC on it
at http://www.faqs.org/rfcs/rfc2268.html

> include it. Furthermore importing a 40 bit RC2 encoded certificate
> is really silly as this can be broken trivially and it must be assumed
> that such a certificate has already ben compromised.
Certificates do not need much protection, that's why the browsers use
weak encryption on them. The only thing protected in a PKCS12 structure
with strong encryption is the private key.

> > An RC2 implementation under the public domain can be found at:
> > ftp://ftp.funet.fi/pub/crypt/cryptography/symmetric/rc2/rrc2.tar.gz
> There is nothing like public domain in most European countries and
> such the legel status of such an implementation might get us in trouble
> later on.

Well not having RC2 means that the whole work I've done on PKCS12
packets is useless, since I cannot decrypt them.


> --
> Werner Koch <wk@gnupg.org>
> The GnuPG Experts http://g10code.com
> Free Software Foundation Europe http://fsfeurope.org

--
Nikos Mavroyanopoulos

On Tue, 24 Jun 2003 10:09:46 +0300, Nikos Mavroyanopoulos said:

> No RC2 is not patented. As far as I know it has the same status as RC4
> (was a trade secret). There is also an informational RFC on it

Okay. This is still smells fishy and using the name RC2 might be
problematic.

Anyway, I have no time to create a new implementation from the
description and as you know, we can't simply use some random public
domain code.

> Well not having RC2 means that the whole work I've done on PKCS12
> packets is useless, since I cannot decrypt them.

The CVS libgcrypt has a mechanism to hook in your own cipher.

--
Werner Koch <wk@gnupg.org>
The GnuPG Experts http://g10code.com
Free Software Foundation Europe http://fsfeurope.org

On Tue Jun 24 2003; 11:24, Werner Koch wrote:

> Okay. This is still smells fishy and using the name RC2 might be
> problematic.

We could call it "ARCTWO" ;-).


> Anyway, I have no time to create a new implementation from the
> description and as you know, we can't simply use some random public
> domain code.

What about Nikos libmcrypt? mcrypt --list shows that RC2 is included
with 128-bit. It should be no problem to cut this down to 40-bit and
the library is available under the terms of the LGPL.


> > Well not having RC2 means that the whole work I've done on PKCS12
> > packets is useless, since I cannot decrypt them.
>
> The CVS libgcrypt has a mechanism to hook in your own cipher.

Really? How is the name of the function.

(My CVS repository is in sync with the latest version but I could
not find anything, sorry if I'm blind.)


Timo

--
Windows Privacy Tools "Der Tugendhafte begnügt sich, von dem zu
(http://winpt.sourceforge.net) träumen, was der Böse im Leben verwirklicht."
OpenPGP Key 0xBF3DF9B4 -- Platon

On Tue, Jun 24, 2003 at 11:56:00AM +0200, Timo Schulz wrote:

> > Okay. This is still smells fishy and using the name RC2 might be
> > problematic.
> We could call it "ARCTWO" ;-).
Sounds fine :)

> > Anyway, I have no time to create a new implementation from the
> > description and as you know, we can't simply use some random public
> > domain code.
> What about Nikos libmcrypt? mcrypt --list shows that RC2 is included
> with 128-bit. It should be no problem to cut this down to 40-bit and
> the library is available under the terms of the LGPL.

This uses the same public domain code I was talking before.
I may try to create a fresh implementation based on the attached description
by Peter Gutmann. I attach it in case someone is more inclined to
do it :)

>
> Timo
> --
> Windows Privacy Tools "Der Tugendhafte begn?gt sich, von dem zu
> (http://winpt.sourceforge.net) tr?umen, was der B?se im Leben verwirklicht."
> OpenPGP Key 0xBF3DF9B4 -- Platon

--
Nikos Mavroyanopoulos

On Tue Jun 24 2003; 15:38, Nikos Mavroyanopoulos wrote:

> I may try to create a fresh implementation based on the attached description
> by Peter Gutmann. I attach it in case someone is more inclined to
> do it :)

Or maybe you can ask him to release the rc2.c code from CryptLib under
LPGL oder a GPL compatible license. But from my point of view, a fresh
implementation from the attached specs should only take some minutes so
there is no need to ask him ;-).


Timo

--
Windows Privacy Tools "Der Tugendhafte begnügt sich, von dem zu
(http://winpt.sourceforge.net) träumen, was der Böse im Leben verwirklicht."
OpenPGP Key 0xBF3DF9B4 -- Platon

On Tue, 24 Jun 2003 11:56:00 +0200, Timo Schulz said:

> What about Nikos libmcrypt? mcrypt --list shows that RC2 is included
> with 128-bit. It should be no problem to cut this down to 40-bit and
> the library is available under the terms of the LGPL.

The thing is that we need a CA for ths FSF and thus an arbitrary
implemention is not good enough under legal aspects..

> Really? How is the name of the function.

/* Public function. Register a provided CIPHER. Returns zero on
success, in which case the chosen cipher ID has been stored in
CIPHER, or an error code. */
gpg_error_t
gcry_cipher_register (gcry_cipher_spec_t *cipher,
gcry_module_t **module)


--
Werner Koch <wk@gnupg.org>
The GnuPG Experts http://g10code.com
Free Software Foundation Europe http://fsfeurope.org

On Wed Jun 25 2003; 13:39, Werner Koch wrote:

> > with 128-bit. It should be no problem to cut this down to 40-bit and
> > the library is available under the terms of the LGPL.
>
> The thing is that we need a CA for ths FSF and thus an arbitrary
> implemention is not good enough under legal aspects..

OK, I understand.


> /* Public function. Register a provided CIPHER. Returns zero on
> success, in which case the chosen cipher ID has been stored in
> CIPHER, or an error code. */
> gpg_error_t
> gcry_cipher_register (gcry_cipher_spec_t *cipher,
> gcry_module_t **module)

gcrypt.h (CVS-1.86): can't find it and my repository is in sync with
the newest CVS.


Timo


--
Windows Privacy Tools "Der Tugendhafte begnügt sich, von dem zu
(http://winpt.sourceforge.net) träumen, was der Böse im Leben verwirklicht."
OpenPGP Key 0xBF3DF9B4 -- Platon

On Wed, 25 Jun 2003 13:50:18 +0200, Timo Schulz said:

> gcrypt.h (CVS-1.86): can't find it and my repository is in sync with
> the newest CVS.

It has not yet been published because it might undergo changes. The
function is available, though.

--
Werner Koch <wk@gnupg.org>
The GnuPG Experts http://g10code.com
Free Software Foundation Europe http://fsfeurope.org

Timo Schulz <twoaday@freakmail.de> writes:

>> /* Public function. Register a provided CIPHER. Returns zero on
>> success, in which case the chosen cipher ID has been stored in
>> CIPHER, or an error code. */
>> gpg_error_t
>> gcry_cipher_register (gcry_cipher_spec_t *cipher,
>> gcry_module_t **module)
>
> gcrypt.h (CVS-1.86): can't find it and my repository is in sync with
> the newest CVS.

This is correct. The *mechanism* is already there, but the interface
has not yet been made public; furthemore documentation needs to be
written.

Werner, do you remember any unsolved problems with the gcry_*_register
API or shall I just finish that part?

moritz
--
((gpg-key-id . "6F984199")
(email . "moritz@duesseldorf.ccc.de")
(webpage . "http://duesseldorf.ccc.de/~moritz/"))

On Sat, 28 Jun 2003 07:44:07 +0200, Moritz Schulte said:

> Werner, do you remember any unsolved problems with the gcry_*_register
> API or shall I just finish that part?

I have not yet used it but I am not aware of any problems.

--
Werner Koch <wk@gnupg.org>
The GnuPG Experts http://g10code.com
Free Software Foundation Europe http://fsfeurope.org

Werner Koch <wk@gnupg.org> writes:

>> Werner, do you remember any unsolved problems with the
>> gcry_*_register API or shall I just finish that part?
>
> I have not yet used it but I am not aware of any problems.

Alright, then I'll just work on making this interface public,
including test cases.

moritz
--
((gpg-key-id . "6F984199")
(email . "moritz@duesseldorf.ccc.de")
(webpage . "http://duesseldorf.ccc.de/~moritz/"))