From wk at gnupg.org  Mon Nov  5 15:54:46 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 05 Nov 2007 15:54:46 +0100
Subject: Is invoking exit(2) in a library the right thing to do?
In-Reply-To: <20071105123716.GB22637@bongo.bofh.it> (Marco d'Itri's message of
	"Mon, 5 Nov 2007 13:37:16 +0100")
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
Message-ID: <871wb4pwsp.fsf@wheatstone.g10code.de>

On Mon,  5 Nov 2007 13:37, md at Linux.IT said:

> I still do not consider calling exit(2) in a library acceptable under
> any condition.

So you want abort () instead?  I consider this a bad option in this case
because exit handlers would not be run.

Given the reluctance of many programmers to properly check error codes
and act accordingly, there is no choice in critical situation than to
terminate the process.  It was a design decision of the linux kernel to
always provide a /dev/random and it is a design decision of libgcrypt
not to return bad random number - in any case.

BTW, glibc also calls abort if it detects an internal inconsistency.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From md at Linux.IT  Mon Nov  5 16:00:22 2007
From: md at Linux.IT (Marco d'Itri)
Date: Mon, 5 Nov 2007 16:00:22 +0100
Subject: Is invoking exit(2) in a library the right thing to do?
In-Reply-To: <871wb4pwsp.fsf@wheatstone.g10code.de>
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
Message-ID: <20071105150022.GA25109@bongo.bofh.it>

On Nov 05, Werner Koch <wk at gnupg.org> wrote:

> > I still do not consider calling exit(2) in a library acceptable under
> > any condition.
> So you want abort () instead?  I consider this a bad option in this case
> because exit handlers would not be run.
I the function to fail with something like an error code.

> Given the reluctance of many programmers to properly check error codes
> and act accordingly, there is no choice in critical situation than to
> terminate the process.
I still disagree.

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20071105/c9ee74ed/attachment.pgp 

From nmav at gnutls.org  Sun Nov 11 08:00:27 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 11 Nov 2007 09:00:27 +0200
Subject: gcry_cipher_register()
Message-ID: <200711110900.27964.nmav@gnutls.org>

Hello,
 I happened to work on some embedded boards that have cryptographic
co-processors or so and they can execute AES, SHA etc faster than a
software implementation on the same board. For curiocity I'd like to ask
whether the gcry_*_register() would allow replacing a default cipher using an 
external implementation.

regards,
Nikos


From psicus78 at gmail.com  Mon Nov 12 09:39:48 2007
From: psicus78 at gmail.com (Gabriele Monti)
Date: Mon, 12 Nov 2007 09:39:48 +0100
Subject: Strange definition in gcrypt.h, bug?
Message-ID: <47381154.3060702@gmail.com>

Hi,
I was having a look at libgcrypt source code. I found what could be a
bug, or maybe something meant to. I'd just like to report it:

#if _GCRY_GCC_VERSION >= 300200
#define _GCRY_GCC_ATTR_MALLOC  __attribute__ ((__malloc__))
#endif

since _GCRY_GCC_VERSION is computed using:


#define _GCRY_GCC_VERSION (__GNUC__ * 10000 \
                             + __GNUC_MINOR__ * 100 \
                             + __GNUC_PATCHLEVEL__)

It will never be greater than 300200, maybe you meant 30200, or maybe
the code is there but attribute __malloc__ is not used yet?

Bye!


From wk at gnupg.org  Mon Nov 12 12:55:58 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 12 Nov 2007 12:55:58 +0100
Subject: gcry_cipher_register()
In-Reply-To: <200711110900.27964.nmav@gnutls.org> (Nikos Mavrogiannopoulos's
	message of "Sun, 11 Nov 2007 09:00:27 +0200")
References: <200711110900.27964.nmav@gnutls.org>
Message-ID: <87bq9zr835.fsf@wheatstone.g10code.de>

On Sun, 11 Nov 2007 08:00, nmav at gnutls.org said:

>  I happened to work on some embedded boards that have cryptographic
> co-processors or so and they can execute AES, SHA etc faster than a
> software implementation on the same board. For curiocity I'd like to ask
> whether the gcry_*_register() would allow replacing a default cipher using an 

No, it is not defined.  However, I'd very much like to add such support.
I recently added a bit of framework for it and I am keen to actually
code some support.  I am still missing a test machine (remote should be
sufficient).  Adding support would automagially benefit all
applications.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From nmav at gnutls.org  Mon Nov 12 20:11:31 2007
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 12 Nov 2007 21:11:31 +0200
Subject: gcry_cipher_register()
In-Reply-To: <87bq9zr835.fsf@wheatstone.g10code.de>
References: <200711110900.27964.nmav@gnutls.org>
	<87bq9zr835.fsf@wheatstone.g10code.de>
Message-ID: <200711122111.32611.nmav@gnutls.org>

On Monday 12 November 2007, Werner Koch wrote:
> On Sun, 11 Nov 2007 08:00, nmav at gnutls.org said:
> >  I happened to work on some embedded boards that have cryptographic
> > co-processors or so and they can execute AES, SHA etc faster than a
> > software implementation on the same board. For curiocity I'd like to ask
> > whether the gcry_*_register() would allow replacing a default cipher
> > using an
> No, it is not defined.  However, I'd very much like to add such support.
> I recently added a bit of framework for it and I am keen to actually
> code some support.  I am still missing a test machine (remote should be
> sufficient).  Adding support would automagially benefit all
> applications.

Unfortunately the embedded devices that are available at the company I work,
are totally crap. Those are connexant boards, totally undocumented and filled 
with proprietary crap. From what I have seen is that they provide openssl 
engine, thus I was curious whether we could provide something similar (not on 
this board though, no way).



From wk at gnupg.org  Tue Nov 13 09:40:28 2007
From: wk at gnupg.org (Werner Koch)
Date: Tue, 13 Nov 2007 09:40:28 +0100
Subject: Strange definition in gcrypt.h, bug?
In-Reply-To: <47381154.3060702@gmail.com> (Gabriele Monti's message of "Mon,
	12 Nov 2007 09:39:48 +0100")
References: <47381154.3060702@gmail.com>
Message-ID: <87lk92mtc3.fsf@wheatstone.g10code.de>

On Mon, 12 Nov 2007 09:39, psicus78 at gmail.com said:

> It will never be greater than 300200, maybe you meant 30200, or maybe
> the code is there but attribute __malloc__ is not used yet?

Right, it should be 30200.  I fixed that in decel and stable.


Thanks,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From wk at gnupg.org  Thu Nov 15 12:45:16 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Nov 2007 12:45:16 +0100
Subject: Bug#412408: Is invoking exit(2) in a library the right thing to
	do?
In-Reply-To: <Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	(James Andrewartha's message of "Thu, 15 Nov 2007 18:55:51 +0900
	(WST)")
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
Message-ID: <874pfn68c3.fsf@wheatstone.g10code.de>

On Thu, 15 Nov 2007 10:55, trs80 at ucc.gu.uwa.edu.au said:

> The only way forward I can see from here is to refer the issue to the
> Technical Committee. If nobody objects or wants to do it themselves
> I'll write up a summary when I have some free time.

I still do not understand the problem.  Do you say that in an early boot
phase /dev/random is not yet mknod-ed or mounted?  If that is the case,
how at all does the boot process work without /dev/null - that it is
universally used before exec.  I don't understand where the difference
is.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From trs80 at ucc.gu.uwa.edu.au  Thu Nov 15 10:55:51 2007
From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha)
Date: Thu, 15 Nov 2007 18:55:51 +0900 (WST)
Subject: Is invoking exit(2) in a library the right thing to do?
In-Reply-To: <20071105150022.GA25109@bongo.bofh.it>
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
Message-ID: <Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>

On Mon, 5 Nov 2007, Marco d'Itri wrote:
> On Nov 05, Werner Koch <wk at gnupg.org> wrote:
>>> I still do not consider calling exit(2) in a library acceptable under
>>> any condition.
>> So you want abort () instead?  I consider this a bad option in this case
>> because exit handlers would not be run.
> I the function to fail with something like an error code.
>
>> Given the reluctance of many programmers to properly check error codes
>> and act accordingly, there is no choice in critical situation than to
>> terminate the process.
> I still disagree.

The only way forward I can see from here is to refer the issue to the 
Technical Committee. If nobody objects or wants to do it themselves I'll 
write up a summary when I have some free time.

-- 
# TRS-80              trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member     http://trs80.ucc.asn.au/ #|  what squirrels do best     |
[ "There's nobody getting rich writing          ]|  -- Collect and hide your   |
[  software that I know of" -- Bill Gates, 1980 ]\  nuts." -- Acid Reflux #231 /



From trs80 at ucc.gu.uwa.edu.au  Thu Nov 15 13:19:57 2007
From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha)
Date: Thu, 15 Nov 2007 21:19:57 +0900 (WST)
Subject: Bug#412408: Is invoking exit(2) in a library the right thing to
	do?
In-Reply-To: <874pfn68c3.fsf@wheatstone.g10code.de>
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	<874pfn68c3.fsf@wheatstone.g10code.de>
Message-ID: <Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>

On Thu, 15 Nov 2007, Werner Koch wrote:

> On Thu, 15 Nov 2007 10:55, trs80 at ucc.gu.uwa.edu.au said:
>
>> The only way forward I can see from here is to refer the issue to the
>> Technical Committee. If nobody objects or wants to do it themselves
>> I'll write up a summary when I have some free time.
>
> I still do not understand the problem.  Do you say that in an early boot 
> phase /dev/random is not yet mknod-ed or mounted?  If that is the case, 
> how at all does the boot process work without /dev/null - that it is 
> universally used before exec.  I don't understand where the difference 
> is.

There is a file in the udev package, /etc/udev/links.conf, which is parsed 
by make_extra_nodes() in /etc/init.d/udev to create a minimal /dev for 
udev to bootstrap itself on. /etc/udev/links.conf contains a line:
M null          c   1 3
which creates /dev/null, but does not contain a line to create 
/dev/random. It also contains the comment:
# This file does not exist. Please do not ask the debian maintainer about it.


-- 
# TRS-80              trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member     http://trs80.ucc.asn.au/ #|  what squirrels do best     |
[ "There's nobody getting rich writing          ]|  -- Collect and hide your   |
[  software that I know of" -- Bill Gates, 1980 ]\  nuts." -- Acid Reflux #231 /



From wk at gnupg.org  Thu Nov 15 15:22:41 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Nov 2007 15:22:41 +0100
Subject: Bug#412408: Is invoking exit(2) in a library the right thing to
	do?
In-Reply-To: <Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>
	(James Andrewartha's message of "Thu, 15 Nov 2007 21:19:57 +0900
	(WST)")
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	<874pfn68c3.fsf@wheatstone.g10code.de>
	<Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>
Message-ID: <87ve8337wu.fsf@wheatstone.g10code.de>

On Thu, 15 Nov 2007 13:19, trs80 at ucc.gu.uwa.edu.au said:

> M null          c   1 3
> which creates /dev/null, but does not contain a line to create 
> /dev/random. It also contains the comment:

So the fix should be pretty easy:

M random   c  1 8
M urandom  c  1 9


Shalom-Salam,

   Werner


p.s.
Does the volume level wheel of that old box's tape deck still work? ;-)

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From md at Linux.IT  Thu Nov 15 15:32:10 2007
From: md at Linux.IT (Marco d'Itri)
Date: Thu, 15 Nov 2007 15:32:10 +0100
Subject: Bug#412408: Is invoking exit(2) in a library the right thing
	to do?
In-Reply-To: <87ve8337wu.fsf@wheatstone.g10code.de>
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	<874pfn68c3.fsf@wheatstone.g10code.de>
	<Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>
	<87ve8337wu.fsf@wheatstone.g10code.de>
Message-ID: <20071115143210.GA7086@bongo.bofh.it>

On Nov 15, Werner Koch <wk at gnupg.org> wrote:

> So the fix should be pretty easy:
> 
> M random   c  1 8
> M urandom  c  1 9
I oppose this "solution", the only devices which *must* be created
statically (and are available in the standard initramfs indeed) are null
and console.

SSL is not used at this time of the boot process: there is no
networking, so the query is expected to (gracefully) fail anyway.

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20071115/4929607e/attachment.pgp 

From trs80 at ucc.gu.uwa.edu.au  Thu Nov 15 15:55:45 2007
From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha)
Date: Thu, 15 Nov 2007 23:55:45 +0900 (WST)
Subject: Bug#412408: Is invoking exit(2) in a library the right thing to
	do?
In-Reply-To: <20071115143210.GA7086@bongo.bofh.it>
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	<874pfn68c3.fsf@wheatstone.g10code.de>
	<Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>
	<87ve8337wu.fsf@wheatstone.g10code.de>
	<20071115143210.GA7086@bongo.bofh.it>
Message-ID: <Pine.LNX.4.62.0711152355260.27256@martello.ucc.gu.uwa.edu.au>

On Thu, 15 Nov 2007, Marco d'Itri wrote:

> On Nov 15, Werner Koch <wk at gnupg.org> wrote:
>
>> So the fix should be pretty easy:
>>
>> M random   c  1 8
>> M urandom  c  1 9
> I oppose this "solution", the only devices which *must* be created
> statically (and are available in the standard initramfs indeed) are null
> and console.
>
> SSL is not used at this time of the boot process: there is no
> networking, so the query is expected to (gracefully) fail anyway.

There is networking - the machines netboot.

-- 
# TRS-80              trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \
# UCC Wheel Member     http://trs80.ucc.asn.au/ #|  what squirrels do best     |
[ "There's nobody getting rich writing          ]|  -- Collect and hide your   |
[  software that I know of" -- Bill Gates, 1980 ]\  nuts." -- Acid Reflux #231 /



From wk at gnupg.org  Thu Nov 15 18:51:07 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 15 Nov 2007 18:51:07 +0100
Subject: Bug#412408: Is invoking exit(2) in a library the right thing to
	do?
In-Reply-To: <20071115143210.GA7086@bongo.bofh.it> (Marco d'Itri's message of
	"Thu, 15 Nov 2007 15:32:10 +0100")
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	<874pfn68c3.fsf@wheatstone.g10code.de>
	<Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>
	<87ve8337wu.fsf@wheatstone.g10code.de>
	<20071115143210.GA7086@bongo.bofh.it>
Message-ID: <87k5oj1jp0.fsf@wheatstone.g10code.de>

On Thu, 15 Nov 2007 15:32, md at Linux.IT said:

> I oppose this "solution", the only devices which *must* be created
> statically (and are available in the standard initramfs indeed) are null
> and console.

With this reasoning you may also change Linux to allow /dev/random to be
a module.  It was conscious decisions, more than a decade ago, to have
/dev/random *always* available.  Thus it is as important as /dev/null
and more usefule than console.

> SSL is not used at this time of the boot process: there is no
> networking, so the query is expected to (gracefully) fail anyway.

It is not only used for networking but also for login services and all
kind of other non-networking stuff.

But if you really don't like to have /dev/random, you may configure
libgcrypt with --enable-random=auto and it will fall back to rndunix
which has the little disadvantage of running dozens of system utilities
to build up the entropy pool.  I wonder whether this has really any
advantage over creating a node for an already existing device.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From fw at deneb.enyo.de  Sun Nov 18 12:10:04 2007
From: fw at deneb.enyo.de (Florian Weimer)
Date: Sun, 18 Nov 2007 12:10:04 +0100
Subject: Bug#412408: Is invoking exit(2) in a library the right thing to
	do?
In-Reply-To: <87ve8337wu.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Thu, 15 Nov 2007 15:22:41 +0100")
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	<874pfn68c3.fsf@wheatstone.g10code.de>
	<Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>
	<87ve8337wu.fsf@wheatstone.g10code.de>
Message-ID: <87ejenrer7.fsf@mid.deneb.enyo.de>

* Werner Koch:

> On Thu, 15 Nov 2007 13:19, trs80 at ucc.gu.uwa.edu.au said:
>
>> M null          c   1 3
>> which creates /dev/null, but does not contain a line to create 
>> /dev/random. It also contains the comment:
>
> So the fix should be pretty easy:
>
> M random   c  1 8
> M urandom  c  1 9

Indeed.  And you should call abort() instead of exit() in the library.


From wk at gnupg.org  Sun Nov 18 16:41:23 2007
From: wk at gnupg.org (Werner Koch)
Date: Sun, 18 Nov 2007 16:41:23 +0100
Subject: Bug#412408: Is invoking exit(2) in a library the right thing to
	do?
In-Reply-To: <87ejenrer7.fsf@mid.deneb.enyo.de> (Florian Weimer's message of
	"Sun, 18 Nov 2007 12:10:04 +0100")
References: <1194263539.32171.32.camel@zarvora>
	<20071105123716.GB22637@bongo.bofh.it>
	<871wb4pwsp.fsf@wheatstone.g10code.de>
	<20071105150022.GA25109@bongo.bofh.it>
	<Pine.LNX.4.62.0711101902100.32606@martello.ucc.gu.uwa.edu.au>
	<874pfn68c3.fsf@wheatstone.g10code.de>
	<Pine.LNX.4.62.0711152114580.25388@martello.ucc.gu.uwa.edu.au>
	<87ve8337wu.fsf@wheatstone.g10code.de>
	<87ejenrer7.fsf@mid.deneb.enyo.de>
Message-ID: <873av3y318.fsf@wheatstone.g10code.de>

On Sun, 18 Nov 2007 12:10, fw at deneb.enyo.de said:

> Indeed.  And you should call abort() instead of exit() in the library.

I will consider this.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From ametzler at downhill.at.eu.org  Sat Nov 24 09:18:49 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 24 Nov 2007 09:18:49 +0100
Subject: libgcrypt stable release?
Message-ID: <9c3l15-th5.ln1@argenau.downhill.at.eu.org>

Hello,

gnutls seems to be planning a new stable release that is going to
depend on libgcrypt > 1.3.0. Is there going to be a stable gcrypt
release before that?
thanks, cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



From wk at gnupg.org  Mon Nov 26 12:02:02 2007
From: wk at gnupg.org (Werner Koch)
Date: Mon, 26 Nov 2007 12:02:02 +0100
Subject: libgcrypt stable release?
In-Reply-To: <9c3l15-th5.ln1@argenau.downhill.at.eu.org> (Andreas Metzler's
	message of "Sat, 24 Nov 2007 09:18:49 +0100")
References: <9c3l15-th5.ln1@argenau.downhill.at.eu.org>
Message-ID: <87y7clgthx.fsf@wheatstone.g10code.de>

On Sat, 24 Nov 2007 09:18, ametzler at downhill.at.eu.org said:

> gnutls seems to be planning a new stable release that is going to
> depend on libgcrypt > 1.3.0. Is there going to be a stable gcrypt
> release before that?

I would really like to get a new release out but there is one gadget I'd
really like to add first.  Please give me two weeks for a new release
and if that one works for you I have no problems declaring it as stable
(or do a 1.4.0).


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.



From ametzler at downhill.at.eu.org  Mon Nov 26 18:54:36 2007
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 26 Nov 2007 18:54:36 +0100
Subject: libgcrypt stable release?
References: <9c3l15-th5.ln1@argenau.downhill.at.eu.org>
	<87y7clgthx.fsf@wheatstone.g10code.de>
Message-ID: <srdr15-2e5.ln1@argenau.downhill.at.eu.org>

Werner Koch <wk at gnupg.org> wrote:
> On Sat, 24 Nov 2007 09:18, ametzler at downhill.at.eu.org said:
>> gnutls seems to be planning a new stable release that is going to
>> depend on libgcrypt > 1.3.0. Is there going to be a stable gcrypt
>> release before that?

> I would really like to get a new release out but there is one gadget I'd
> really like to add first.  Please give me two weeks for a new release
> and if that one works for you I have no problems declaring it as stable
> (or do a 1.4.0).

Thanks for the update.
cu andreas



From wk at gnupg.org  Thu Nov 29 11:56:40 2007
From: wk at gnupg.org (Werner Koch)
Date: Thu, 29 Nov 2007 11:56:40 +0100
Subject: Padlock support
Message-ID: <877ik12uc7.fsf@wheatstone.g10code.de>

Hi,

the first steps for supporting the Padlock engine of VIA processors have
been taken.  With the current SVN of libgcrypt the ACE engine is used
for AES-128.  More stuff will follow.

Here are the benchmarks (milliseconds for 10^6 bytes):

            ECB        CBC         CFB         OFB         CTR
=================================================================         
Pentium M 1500 MHz:
AES      50    40    60    60    50    60    50    50   100    90
AES192   60    50    60    70    60    60    70    60   100   110
AES256   60    60    70    80    60    80    60    70   110   120

Via Nehemiah 600 MHz:
AES      60    60   110   100    90    90    90    80   280   300
AES192  420   430   480   480   460   470   460   460   660   660
AES256  490   500   540   550   520   530   520   530   730   730

I think this is quite an improvement.  Due to the internal structure of
libgcrypt we can only encrypt one block at a time which seriously limits
the performance.  This is something we need to tackle in the future.

Thanks to Nikos Mavrogiannopoulos for giving me access to his VIA box.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Auschnahme regelt ein Bundeschgesetz.