Re: [experimantal patch] show allowed keylengths in /proc/cipher/*

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 29, 2000 at 03:13:27PM +0000, Marc Mutz wrote:
> Hi out there!
> 
> This little patch allows /proc/cipher/* to show a bitmask of allowed
> keysizes. Simple as it may ssem, it breaks the current jungle of
> #define's quite thoroughly. Ciphers that want to take advantage of this
> patch and actually _provide_ more than one keylength per cipher
> implementation (and most ciphers could), will not be able to use the
> DEFINE_CIPHER construct any more.
> 

Why not just let all ciphers accept any key-length up to a maximum key
length, and have the cipher internally treat shorter keys as a
possible optimization opportunities.  For example, the rijndael cipher
could exploit that kind of stuff to select the correct number of
rounds.  So the user wouldn't really care about which intermediate
keylengths a cipher was designed for, just the maximum keylength it
was designed for.

> So what now? I'd like to remove the DEFINE_CIPHER construct althogether.
> It makes defining "dumb" ciphers easy, but it obfuscates the definition
> of a cipher for unexperienced (w.r.t. cipherapi) coders and interested
> eyes that read the source, since the meaning of the numbers and strings
> appearing in DEFINE_CIPHER is not obvious. Even when you have read over
> a few cipher sources you catch yourself going back to
> include/linux/crypto.h to look up what each entry means.
> 
> On the opposite, having the struct cipher_implementation populated
> without the help of macros goes a long way towards transparency, because
> the field identifiers show up alongside their values. Or not?
> 
> Now my inexprience with C comes up again: Is there a C construct that
> shows the field identifiers even in static const definitions? Like in
> perl:
> 
> %an_associative_array = {
> 	field1 -> value1,
> 	field2 -> value2,
> 	 :          :
> }
> 

You are free to not use DEFINE_CIPHER if you want.  There are two
constructs that can be used to initialize C structs.  One is a gcc
extension and looks like this:

struct foo bar = {
	membera: 1,
	memberb: 2
};

The other one is part of C99 and goes like this:

struct foo bar = {
	.membera = 1,
	.memberb = 2
};

In the kernel, the first form is used since it is programmed in GNU C,
and not standard C.

astor

-- 
Alexander Kjeldaas                Mail:  astor@xxxxxxx
finger astor@xxxxxxxxxxxxxxxxx for OpenPGP key.

Linux-crypto:  cryptography in and on the Linux system
Archive:       http://mail.nl.linux.org/linux-crypto/


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux