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]

Message-ID: <alpine.LRH.2.00.0902051703150.4290@vixen.sonytel.be>
Date:	Thu, 5 Feb 2009 17:24:51 +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

	Hi Herbert,

On Thu, 15 Jan 2009, Herbert Xu wrote:
> On Wed, Jan 14, 2009 at 04:01:34PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 14 Jan 2009, Herbert Xu wrote:
> > > Also, this is something that we'll potentially export to user-space,
> > > so we need to ensure that it is invariant to word length.
> > > 
> > > So something like this would be good
> > > 
> > > 	int (*setup_comp)(struct crypto_pcomp *tfm, const void *params,
> > > 			  unsigned int length);
> > > 	int (*setup_decomp)(struct crypto_pcomp *tfm, const void *params,
> > > 			    unsigned int length);
> > 
> > I assume "length" is the size of the passed params, so the algorithms can
> > return -EINVAL if they're passed the wrong size?
> > 
> > > The actual parameters should be formatted using the netlink helpers
> > > (nla_*).  So each parameter that you want to set should show up as
> > > a netlink attribute.  If a paramter is absent then you'd just use
> > > the default, etc.
>
> > I assume "length" is the size of the passed params, so the algorithms can
> > return -EINVAL if they're passed the wrong size?
> 
> 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?
Nothing in crypto/ seems to already use nla_*?

> Ah yes because crypto_comp is one of the original types that's
> still built-in.  Because there are so few compression users and
> algorithms (exactly 3 if you include null compression), I think
> we can dispense with the compatibility stuff altogether since
> we'll likely rip out fairly soon anyway.
> 
> So just create the new type, readd deflate using the new type
> alongside the existing deflate algorithm.  The system is capable
> of supporting two algorithms of the same name with different types.

While the core of the crypto system supports two algorithms of the same name
with different types, the testmgr doesn't.

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?

Thanks!

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/