linux-kernel - Re: [PATCH] crypto: compress

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Feb 2009 16:19:40 +0100 (CET)
From:	Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] crypto: compress - Add pcomp interface

On Tue, 10 Feb 2009, Herbert Xu wrote:
> On Thu, Feb 05, 2009 at 05:24:51PM +0100, Geert Uytterhoeven wrote:
> > > Well with the netlink parameters these can have variable lengths
> > > depending on how many parameters the user supplies.
> > 
> > How can this be exported to userspace?
> > How does this variable length parameter passing work? Do you have an example?
> 
> See how we use it for rtnetlink, e.g., in net/ipv4/ip_gre.c.
> 
> > Nothing in crypto/ seems to already use nla_*?
> 
> Well we don't have a user-space API yet :) But checkout the
> discussions on this list.

I'm sorry, but this is a totally separate change, so I'm not going to do it
right now.

> > While the core of the crypto system supports two algorithms of the same name
> > with different types, the testmgr doesn't.
> 
> I was lazy :) But really it isn't too hard to add a type field to
> the array in testmgr.  We don't even have to add it for existing
> entries (except for the ones that you're trying to replace, i.e.,
> deflate).

Are you sure about that? Shouldn't all the call sites to tcrypt_test() get a
type parameter, too?

> > As I removed the backwards-compatility layer at your request, I'll use "zlib"
> > for the name of the new module. It's more flexible than the fixed "deflate"
> > one anyway.
> > 
> > Is this OK for you?
> 
> Hmm, I think we need to have it stay as deflate if we're to make
> an easy transition for existing users (e.g., IPsec).

It's just a matter of replacing the literal "deflate" by "zlib", when switching
net/xfrm/xfrm_algo.c from the old to the new API. As there won't be a
backwards-compatibility layer, the algorithm names don't have to match.

It's much less work than adding crypto types to all parts of the test code...

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium

Phone:    +32 (0)2 700 8453
Fax:      +32 (0)2 700 8622
E-mail:   Geert.Uytterhoeven@...ycom.com
Internet: http://www.sony-europe.com/

A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/