On Tue, 2005-03-22 at 12:13 +1100, Herbert Xu wrote:
> On Mon, Mar 21, 2005 at 12:30:59PM +0100, Fruhwirth Clemens wrote:
> >
> > Applying all patches results in a "does not work for me". The decryption
> > result is different from the original and my LUKS managed
On Tue, 2005-03-22 at 12:13 +1100, Herbert Xu wrote:
On Mon, Mar 21, 2005 at 12:30:59PM +0100, Fruhwirth Clemens wrote:
Applying all patches results in a does not work for me. The decryption
result is different from the original and my LUKS managed partition
refuses to mount.
Thanks
c815442f7e438865 /dev/mapper/test-map
Cheers,
--
Fruhwirth Clemens - http://clemens.endorphin.org
for robots: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
/test-map
Cheers,
--
Fruhwirth Clemens - http://clemens.endorphin.org
for robots: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
h*" patches in one-large acrypto patch set, and an other for
"bd*". I'd be glad to say something different, but I think acrypto has
not been considered by the maintainers to be merged soon, so patch
splitting doesn't make sense anyway at the moment.
Best Regards,
--
Fruhwirth Cleme
-large acrypto patch set, and an other for
bd*. I'd be glad to say something different, but I think acrypto has
not been considered by the maintainers to be merged soon, so patch
splitting doesn't make sense anyway at the moment.
Best Regards,
--
Fruhwirth Clemens - http://clemens.endorphin.org
On Mon, 2005-02-14 at 10:16 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > First, one has to make kmap fallible.
>
> I think it would be relatively simple and sane to modify the existing
> kmap() implementations to add a
On Mon, 2005-02-14 at 10:16 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
First, one has to make kmap fallible.
I think it would be relatively simple and sane to modify the existing
kmap() implementations to add a new try_kmap() which is atomic and returns
On Mon, 2005-02-14 at 09:07 -0800, David S. Miller wrote:
> On Mon, 14 Feb 2005 18:06:39 +0100
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> > There is nothing wrong with having special methods, that lack generality
> > but are superior in performance. The
On Mon, 2005-02-14 at 07:56 -0800, David S. Miller wrote:
> On Mon, 14 Feb 2005 14:20:34 +0100
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
>
> > Conclusion: The idea of high-mem and low-mem seperation is fundamentally
> > broken. The limitation of page table entrie
s the burden to the users of the interface.
Being disgusted by the highmem interface and the "ungenericness" of my
generic workaround, there is not going to be any update to my LRW work
from my side. This patch set is dead.
--
Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.e
to the users of the interface.
Being disgusted by the highmem interface and the ungenericness of my
generic workaround, there is not going to be any update to my LRW work
from my side. This patch set is dead.
--
Fruhwirth Clemens [EMAIL PROTECTED] http://clemens.endorphin.org
signature.asc
On Mon, 2005-02-14 at 07:56 -0800, David S. Miller wrote:
On Mon, 14 Feb 2005 14:20:34 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
Conclusion: The idea of high-mem and low-mem seperation is fundamentally
broken. The limitation of page table entries to a fixed set is causing
more
On Mon, 2005-02-14 at 09:07 -0800, David S. Miller wrote:
On Mon, 14 Feb 2005 18:06:39 +0100
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
There is nothing wrong with having special methods, that lack generality
but are superior in performance. There is something wrong, when
On Thu, 2005-02-10 at 12:02 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
>
> > Hm, alright. So I'm going take the internal of kmap_atomic into
> > scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
> > it is, I'm going
On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> > > Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > > Adding a few more fixmap
On Wed, 2005-02-09 at 20:42 -0500, James Morris wrote:
> On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
>
> > Because a tweak is different from an IV. There can be an arbitrary
> > number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
> > have a 4k p
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > It must be
> > possible to process more than 2 mappings in softirq context.
>
> Adding a few more fixmap slots wouldn't hurt anyone. But if you w
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
It must be
possible to process more than 2 mappings in softirq context.
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily large number of them
On Wed, 2005-02-09 at 20:42 -0500, James Morris wrote:
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
Because a tweak is different from an IV. There can be an arbitrary
number of tweaks. For instance, EME takes 1 tweak per 512 bytes. If you
have a 4k page to encrypt, you have to process 8
On Thu, 2005-02-10 at 02:33 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
On Wed, 2005-02-09 at 17:19 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
Adding a few more fixmap slots wouldn't hurt anyone. But if you want an
arbitrarily
On Thu, 2005-02-10 at 12:02 -0500, James Morris wrote:
On Thu, 10 Feb 2005, Fruhwirth Clemens wrote:
Hm, alright. So I'm going take the internal of kmap_atomic into
scatterwalk.c. to test if the page is in highmem, with PageHighMem. If
it is, I'm going to kmap_atomic and mark the fixmap
On Wed, 2005-02-09 at 19:30 -0500, James Morris wrote:
> On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
>
> > I can't code for the case of two. Because, first, that's the idea of
> > generic in the name "generic scatterwalk", second, I need at least 3
> > scatterl
On Tue, 2005-02-08 at 19:09 -0500, James Morris wrote:
> On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
>
> > > You can't call kmap() in softirq context (why was it even trying?):
> >
> > Why not? What's the alternative, then?
>
> It can sleep in map_new_virtual(
On Tue, 2005-02-08 at 19:09 -0500, James Morris wrote:
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
You can't call kmap() in softirq context (why was it even trying?):
Why not? What's the alternative, then?
It can sleep in map_new_virtual().
The alternative is to use atomic kmaps
On Wed, 2005-02-09 at 19:30 -0500, James Morris wrote:
On Wed, 9 Feb 2005, Fruhwirth Clemens wrote:
I can't code for the case of two. Because, first, that's the idea of
generic in the name generic scatterwalk, second, I need at least 3
scatterlists in parallel for LRW.
Can you explain
On Tue, 2005-02-08 at 18:30 -0500, James Morris wrote:
> On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
>
> > I shot out the last patch too quickly. Having reviewed the mapping one
> > more time I noticed, that there as the possibility of "off-by-one"
> > unmapp
On Tue, 2005-02-08 at 17:08 +0100, Fruhwirth Clemens wrote:
> On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
> > On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
> >
> > > + * The generic scatterwalker applies a certain function, pf, utilising
> > > + * an arb
On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
> On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
>
> > + * The generic scatterwalker applies a certain function, pf, utilising
> > + * an arbitrary number of scatterlist data as it's arguments. These
> > + * arguments
This patch removes cipher.c/crypt in favour of a more generic function,
scatterwalk_walk, which can process an unlimited number of scatterlists in
parallel.
For a more in-depth description see the comments in front of
scatterwalk_walk and scatterwalk_info_init.
Changes since last patch:
to all previously posted versions.
Signed-off-by: Fruhwirth Clemens <[EMAIL PROTECTED]>
--- 0/crypto/api.c 2005-01-20 10:15:22.0 +0100
+++ 1/crypto/api.c 2005-01-20 10:15:40.0 +0100
@@ -3,6 +3,7 @@
*
* Copyright (c) 2002 James Morris <[EMAIL PROTECTED]>
to all previously posted versions.
Signed-off-by: Fruhwirth Clemens [EMAIL PROTECTED]
--- 0/crypto/api.c 2005-01-20 10:15:22.0 +0100
+++ 1/crypto/api.c 2005-01-20 10:15:40.0 +0100
@@ -3,6 +3,7 @@
*
* Copyright (c) 2002 James Morris [EMAIL PROTECTED]
* Copyright (c
This patch removes cipher.c/crypt in favour of a more generic function,
scatterwalk_walk, which can process an unlimited number of scatterlists in
parallel.
For a more in-depth description see the comments in front of
scatterwalk_walk and scatterwalk_info_init.
Changes since last patch:
On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
+ * The generic scatterwalker applies a certain function, pf, utilising
+ * an arbitrary number of scatterlist data as it's arguments. These
+ * arguments are supplied as an array
On Tue, 2005-02-08 at 17:08 +0100, Fruhwirth Clemens wrote:
On Tue, 2005-02-08 at 09:48 -0500, James Morris wrote:
On Sat, 5 Feb 2005, Fruhwirth Clemens wrote:
+ * The generic scatterwalker applies a certain function, pf, utilising
+ * an arbitrary number of scatterlist data as it's
On Tue, 2005-02-08 at 18:30 -0500, James Morris wrote:
On Tue, 8 Feb 2005, Fruhwirth Clemens wrote:
I shot out the last patch too quickly. Having reviewed the mapping one
more time I noticed, that there as the possibility of off-by-one
unmapping, and instead of doing doubtful guesses
he work of any reviewers. Mostly whitespace changes..
Outlook for the next patches: tweakable cipher modes interface, LRW
core, Michal's multiblock rewrite. Fortunately, none of them is as
intruding as the scatterwalk change.
Signed-off-by: Fruhwirth Clemens <[EMAIL PROTECTED]>
--- 1/cryp
whitespace changes..
Outlook for the next patches: tweakable cipher modes interface, LRW
core, Michal's multiblock rewrite. Fortunately, none of them is as
intruding as the scatterwalk change.
Signed-off-by: Fruhwirth Clemens [EMAIL PROTECTED]
--- 1/crypto/cipher.c 2005-01-20 10:15
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
> Way too complicated. This is a crypto project, why does nobody think of
> crypto to solve the problem :). Here's the idea:
> [see original post, http://lkml.org/lkml/2005/2/3/109 , for idea]
Very simple patch. With t
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
Way too complicated. This is a crypto project, why does nobody think of
crypto to solve the problem :). Here's the idea:
[see original post, http://lkml.org/lkml/2005/2/3/109 , for idea]
Very simple patch. With that, it's
On Thu, 2005-02-03 at 05:15 -0500, Christopher Warner wrote:
> On Thu, 2005-02-03 at 15:18 +0100, Fruhwirth Clemens wrote:
> >
> > Keys are handed to dm-crypt regularly the first time. But when dm-crypt
> > hands keys back to user space, it uses some sort of blinding
On Thu, 2005-02-03 at 15:47 +0100, Andries Brouwer wrote:
> On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
>
> > (Actually it's a Multi Time Pad.)
>
> And you call this "crypto"?
Is the quoted part all you have read?
--
Fruhwirth Cleme
ion instead of XOR-ing with the kernel
secret as blinding mechanism, as the kernel secret can easily be
recovered by setting up a all-zero key. But the main intend of this
approach is to protect against incompetent roots and user space
programs, so I think this XOR OTP is sufficient, and further, trivia
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> > +#define scatterwalk_needscratch(walk, nbytes)
> > \
> > + ((nbytes) <
On Thu, 2005-02-03 at 13:40 +1300, Michal Ludvig wrote:
> Fruhwirth Clemens wrote:
>
> > Especially, if James ask me to redo Michal's conflicting patches
> > (done btw), which are totally off-topic for me.
>
> Great, thanks! Has the interface for multiblock modules cha
On Thu, 2005-02-03 at 13:40 +1300, Michal Ludvig wrote:
Fruhwirth Clemens wrote:
Especially, if James ask me to redo Michal's conflicting patches
(done btw), which are totally off-topic for me.
Great, thanks! Has the interface for multiblock modules changed or
should my old modules
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
+#define scatterwalk_needscratch(walk, nbytes)
\
+ ((nbytes) = (walk)-len_this_page
by setting up a all-zero key. But the main intend of this
approach is to protect against incompetent roots and user space
programs, so I think this XOR OTP is sufficient, and further, trivially
to implement. (Actually it's a Multi Time Pad.)
--
Fruhwirth Clemens [EMAIL PROTECTED] http
On Thu, 2005-02-03 at 15:47 +0100, Andries Brouwer wrote:
On Thu, Feb 03, 2005 at 03:18:20PM +0100, Fruhwirth Clemens wrote:
(Actually it's a Multi Time Pad.)
And you call this crypto?
Is the quoted part all you have read?
--
Fruhwirth Clemens [EMAIL PROTECTED] http
On Thu, 2005-02-03 at 05:15 -0500, Christopher Warner wrote:
On Thu, 2005-02-03 at 15:18 +0100, Fruhwirth Clemens wrote:
Keys are handed to dm-crypt regularly the first time. But when dm-crypt
hands keys back to user space, it uses some sort of blinding to make the
keys meaningless
w), which are
totally off-topic for me. Then, I'm certainly not going to redo all my
code, just because someone thinks different about the naming of my
variables.
--
Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
> On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
> > James, please test it against ipsec. I'm confident, that everything will
> > work as expected and we can proceed to merge padlock-multiblock against this
> > scatterwal
On Wed, 2005-02-02 at 17:46 -0500, James Morris wrote:
On Sun, 30 Jan 2005, Fruhwirth Clemens wrote:
James, please test it against ipsec. I'm confident, that everything will
work as expected and we can proceed to merge padlock-multiblock against this
scatterwalker, so please Andrew, merge
are
totally off-topic for me. Then, I'm certainly not going to redo all my
code, just because someone thinks different about the naming of my
variables.
--
Fruhwirth Clemens [EMAIL PROTECTED] http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
On Sat, Jan 29, 2005 at 10:23:10AM -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > My advise is, drop Michaels patches
> > for now, merge scatterwalker and add an ability to change the stepsize
> > dynamically in the run. Th
On Sat, 2005-01-29 at 16:02 -0800, Matt Mackall wrote:
> On Mon, Jan 24, 2005 at 12:57:50PM +0100, Fruhwirth Clemens wrote:
> > This is the core of my LRW patch. Added test vectors.
> > http://grouper.ieee.org/groups/1619/email/pdf00017.pdf
>
> Please include a URL for th
tepsize
dynamically in the run. Then I will finish my port and post it.
If we can agree on this "agenda", I'll shift my focus to scatterwalker
testing.
--
Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
to scatterwalker
testing.
--
Fruhwirth Clemens [EMAIL PROTECTED] http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
So, are we heading for hardware support in cryptoapi, hardware
support in acrypto, acrypto instead of cryptoapi, OCF instead of
cryptoapi, or put everything into the kernel and export 3 interface?
And how - when there is more than one interface - are these projects
going to reuse code?
--
Fruh
, hardware
support in acrypto, acrypto instead of cryptoapi, OCF instead of
cryptoapi, or put everything into the kernel and export 3 interface?
And how - when there is more than one interface - are these projects
going to reuse code?
--
Fruhwirth Clemens [EMAIL PROTECTED] http
On Mon, 2005-01-24 at 14:31 -0800, Andrew Morton wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> >
> > This patch adds the ability for a cipher mode to store cipher mode specific
> > information in crypto_tfm. This is necessary for LRW's precomputed
&
This is the core of my LRW patch. Added test vectors.
http://grouper.ieee.org/groups/1619/email/pdf00017.pdf
Please notice, that this is not a patch for dm-crypt. I will
post a nice splitted patch set for dm later that day.
Signed-off-by: Fruhwirth Clemens <[EMAIL PROTECTED]>
--- 3/
This patch adds a new cipher interface "tweakable". This interface
will be used for tweakable cipher modes such as LRW (or EME, CMC .. if I
every going to port my old code).
Signed-off-by: Fruhwirth Clemens <[EMAIL PROTECTED]>
--- 2/crypto/cipher.c 2005-01-22 16:53:33.0
the number of IV memcpy's to 1 at most.
This patch is the one responsible for the performance increase
mentioned in http://lkml.org/lkml/2005/1/19/191
Signed-off-by: Fruhwirth Clemens <[EMAIL PROTECTED]>
--- 1/crypto/cipher.c 2005-01-20 10:15:40.0 +0100
+++ 2/crypto/cipher.c 2005
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
Signed-off-by: Fruhwirth Clemens <[EMAIL PROTECTED]>
--- 0/crypto/api.c 2005-01-20 10:15:22.0 +0100
+++ 1/
On Mon, 2005-01-24 at 14:31 -0800, Andrew Morton wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
These patches
This patch adds the ability for a cipher mode to store cipher mode specific
information in crypto_tfm. This is necessary for LRW's precomputed
GF-multiplication tables.
Signed-off-by: Fruhwirth Clemens [EMAIL PROTECTED]
--- 0/crypto/api.c 2005-01-20 10:15:22.0 +0100
+++ 1/crypto
the number of IV memcpy's to 1 at most.
This patch is the one responsible for the performance increase
mentioned in http://lkml.org/lkml/2005/1/19/191
Signed-off-by: Fruhwirth Clemens [EMAIL PROTECTED]
--- 1/crypto/cipher.c 2005-01-20 10:15:40.0 +0100
+++ 2/crypto/cipher.c 2005-01-22 16
This patch adds a new cipher interface tweakable. This interface
will be used for tweakable cipher modes such as LRW (or EME, CMC .. if I
every going to port my old code).
Signed-off-by: Fruhwirth Clemens [EMAIL PROTECTED]
--- 2/crypto/cipher.c 2005-01-22 16:53:33.0 +0100
+++ 3/crypto
This is the core of my LRW patch. Added test vectors.
http://grouper.ieee.org/groups/1619/email/pdf00017.pdf
Please notice, that this is not a patch for dm-crypt. I will
post a nice splitted patch set for dm later that day.
Signed-off-by: Fruhwirth Clemens [EMAIL PROTECTED]
--- 3/crypto/cipher.c
On Wed, 2005-01-19 at 16:24 -0500, James Morris wrote:
> On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
>
> > I've rewritten some CBC code to fit the facilities I introduce in my LRW
> > patch[1]. Here are the results for my [EMAIL PROTECTED]:
> >
> > loop-aes, CB
s just the price you pay, when you have to do things right and
clean, so they get merged into main. Kernel developers are choosey
customers, you know.
[1] http://clemens.endorphin.org/patches/lrw/
--
Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
developers are choosey
customers, you know.
[1] http://clemens.endorphin.org/patches/lrw/
--
Fruhwirth Clemens [EMAIL PROTECTED] http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
On Wed, 2005-01-19 at 16:24 -0500, James Morris wrote:
On Wed, 19 Jan 2005, Fruhwirth Clemens wrote:
I've rewritten some CBC code to fit the facilities I introduce in my LRW
patch[1]. Here are the results for my [EMAIL PROTECTED]:
loop-aes, CBC: ~30.5mb/s
dm-crypt, CBC prior to my
On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
> Fruhwirth Clemens <[EMAIL PROTECTED]> wrote:
> > This is FUD. To get serious in-depth information about the problems
> > associated with dm-crypt and loop-aes read,
> >
> > http://clemens.endorphin.org/
On Mon, 2005-01-17 at 19:29 +, Paul Walker wrote:
> On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
>
> > > Unlikely to go to mainline kernel. Mainline folks are just too much in
> > > love
> > > with their backdoored device crypto imple
d loop-aes is
the reason why I have been pushing this patch so hard for the last two
months now.
--
Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
pushing this patch so hard for the last two
months now.
--
Fruhwirth Clemens [EMAIL PROTECTED] http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
On Mon, 2005-01-17 at 19:29 +, Paul Walker wrote:
On Mon, Jan 17, 2005 at 08:14:58PM +0100, Fruhwirth Clemens wrote:
Unlikely to go to mainline kernel. Mainline folks are just too much in
love
with their backdoored device crypto implementations [1].
Just to add back in Jari's
On Mon, 2005-01-17 at 22:26 +0100, markus reichelt wrote:
Fruhwirth Clemens [EMAIL PROTECTED] wrote:
This is FUD. To get serious in-depth information about the problems
associated with dm-crypt and loop-aes read,
http://clemens.endorphin.org/LinuxHDEncSettings
excuse me, but that's
h easier to read for people, and tfm's aren't alloced
that often.
Probably, we can add a wrapper for cia_modesel, that when cia_modesel is
NULL, it falls back to the old behaviour. This way, we don't have to
patch all algorithm implementations to include cia_modesel.
How you like that idea?
--
Fruhwirth Clemens <[EMAIL PROTECTED]> http://clemens.endorphin.org
signature.asc
Description: This is a digitally signed message part
can add a wrapper for cia_modesel, that when cia_modesel is
NULL, it falls back to the old behaviour. This way, we don't have to
patch all algorithm implementations to include cia_modesel.
How you like that idea?
--
Fruhwirth Clemens [EMAIL PROTECTED] http://clemens.endorphin.org
signature.asc
82 matches
Mail list logo
