Mailing List Archive

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

> Does this list exist? I heard of it through
> http://www.gnupg.org/docs.html. I think that I've subscribed, but I
> didn't get any feedback, nor does there seem to be an archive.

Sorry. I added a .procmail rule but forgot to add the folder to my
list of mailboxes, so I noticed your mail today while looking at the
archive (lists.gnupg.org). There are no subscribers yet and I think I
have to check why it does not work.

> I would like to try using gcrypt in Pluto, the IKE daemon of the FreeS/WAN
> project (http://www.xs4al.nl/~freeswan).
>
> Is there such a thing as gcrypt?

I am working on it (talked with Richard about this a while back) but I
am not ready. Symmetric cipher and MD API will not chnage anmore but
I am not sure how to do the PK API.

Please tell me what functionality you need for Pluto, so that I can do
a first release with that in mind.

I am currently working on a 1.1 of GnuPG which will use this library.


Werner

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013

| From: Werner Koch <wk@gnupg.org>

| > Does this list exist? I heard of it through
| > http://www.gnupg.org/docs.html. I think that I've subscribed, but I
| > didn't get any feedback, nor does there seem to be an archive.
|
| Sorry. I added a .procmail rule but forgot to add the folder to my
| list of mailboxes, so I noticed your mail today while looking at the
| archive (lists.gnupg.org). There are no subscribers yet and I think I
| have to check why it does not work.

Will the list be the right way to communicate (once it is functional)?

| > I would like to try using gcrypt in Pluto, the IKE daemon of the FreeS/WAN
| > project (http://www.xs4al.nl/~freeswan).

| Please tell me what functionality you need for Pluto, so that I can do
| a first release with that in mind.

I'm not sure what library we are going to use in the long term (I
don't make that decision). It may well be gcrypt.

Right now, I'm trying to hack dsa.c/elgamal.c to fit into our code
since we need support for DSS yesterday.

I'm trying to make dsa.c/elgamal.c work with GMP because that is what
we use for big integers. We use it because we use libdes (Eric
Young's old code) and libdes uses GMP. What a tangle.

We'd like to use OpenSSL, but we are not 100% sure of it being free of
US export control (we don't know that none of the code came from USA).

So this is why I'm trying to hack code from gnupg.

In the end, we'd like all sorts of crypto code: symmetric and public
key. I'd like to be using one library, not two. We'd even like RSA,
but that isn't important for another year :-).

Oh, and it would be great if we could compile it in a way for it to be
run in the linux kernel (not my area). I don't know how this fits in
with the international kernel patch; maybe it doesn't.

| I am currently working on a 1.1 of GnuPG which will use this library.

Good!

Any thought to a timeframe for the gcrypt portion?

Should I be on a different mailing list to find out about this?

Thanks,

Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253

"D. Hugh Redelmeier" <hugh@mimosa.com> writes:

> Will the list be the right way to communicate (once it is functional)?

Yes, I did this on request of one Debian developer but it happend to
get never used. The permissions are now fixed. Please subscribe if
you like to do so.

> Right now, I'm trying to hack dsa.c/elgamal.c to fit into our code
> since we need support for DSS yesterday.

I understand.

> I'm trying to make dsa.c/elgamal.c work with GMP because that is what
> we use for big integers. We use it because we use libdes (Eric
> Young's old code) and libdes uses GMP. What a tangle.

libdes needs big integers - it is not the one from OpenSSL I guess.

There are some reasons why I decided not to use plain GMP:

- Too much unneeded code (okay that doesn't matter with shared lib)
- GMP does not use a pointer to hide internals - this gives better
performance but because we only do a few function calls this does
not matter much when compared to the execution time of a single
function.
- It is not possible to use a chunk of mlock()ed memory for
confidential numbers due to the use of alloca() and mallocs. I
hacked the whole library to support what I called "secure memory":
You have 2 calls to allocate a MPI, one for normal ones and
another which flags that MPI to be stored and calucatled only in
a special memory area.

> In the end, we'd like all sorts of crypto code: symmetric and public
> key. I'd like to be using one library, not two. We'd even like RSA,
> but that isn't important for another year :-).

No problem; there will be RSA on Sep 20th, 2000 ;-)

> Oh, and it would be great if we could compile it in a way for it to be
> run in the linux kernel (not my area). I don't know how this fits in
> with the international kernel patch; maybe it doesn't.

I talked with Richard about this and I will take care to allow for
this (ciphers and digests).

> Any thought to a timeframe for the gcrypt portion?

Yes, last spring :-( Due to many other tasked I have not done any
real work on code for the last couple of weeks. I'll be to Japan next
week and I hope to find some time to work on libgcrypt while I am
there or in the week after it.

I really need libgcrypt for gnupg 1.1 and some other things I am
working on, so there should be some working code soon.

> Should I be on a different mailing list to find out about this?

Feel free to use this ML, it is no extra work for me (I will add
a search engine for the lists too).


Werner

--
Werner Koch at guug.de www.gnupg.org keyid 621CC013