Hello,
I have a little problem with the min|max keysize: /proc/crypto:
name : aes
driver : aes-special
module : aes2
priority : 150
refcnt : 1
type : cipher
blocksize : 16
min keysize : 24
max keysize : 32
name : aes
driver : aes-generic
module : aes
priority : 100
refcnt : 1
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32
16bit key are not supported by the -special algo, only by the -generic
driver. My understanding of this was if someone needs 16bit keys
aes-generic id used and for 24 and 32 bit long keys the -special driver.
Unfortunately crypto_alloc_blkcipher() does not care about the min|max
keysize field.
I thing the main problem here is that the crypto api knows nothing about
the key size until crypto_blkcipher_setkey() what is probably too late.
Is it possible to modify the api to something like OpenSSL's
aes-128-cbc (or cbc(aes(128)) in our case :) ) ?
I have a question regarding the git tree: Which one is valid?
MAINTAINERS says .../git/herbert/crypto-2.6.git but once I clone it,
there is .git directory in it (with 151MB but no source code).
./git/herbert/cryptodev-2.6.git on the other has source inside.
--
Best regards
Sebastian Siewior
Sebastian Siewior <[email protected]> wrote:
>
> I have a little problem with the min|max keysize: /proc/crypto:
>
> name : aes
> driver : aes-special
> module : aes2
> priority : 150
> refcnt : 1
> type : cipher
> blocksize : 16
> min keysize : 24
> max keysize : 32
>
> name : aes
> driver : aes-generic
> module : aes
> priority : 100
> refcnt : 1
> type : cipher
> blocksize : 16
> min keysize : 16
> max keysize : 32
>
> 16bit key are not supported by the -special algo, only by the -generic
> driver. My understanding of this was if someone needs 16bit keys
> aes-generic id used and for 24 and 32 bit long keys the -special driver.
> Unfortunately crypto_alloc_blkcipher() does not care about the min|max
> keysize field.
> I thing the main problem here is that the crypto api knows nothing about
> the key size until crypto_blkcipher_setkey() what is probably too late.
> Is it possible to modify the api to something like OpenSSL's
> aes-128-cbc (or cbc(aes(128)) in our case :) ) ?
What exactly is the aes-special algorithm and where can I find a copy?
Yes key length support is missing as far as algorithm selection
is concerned. I haven't worried too much about it because there
hasn't been that many algorithms needing this.
So my question is how hard is it to make aes-special support 16-bit keys?
> I have a question regarding the git tree: Which one is valid?
> MAINTAINERS says .../git/herbert/crypto-2.6.git but once I clone it,
> there is .git directory in it (with 151MB but no source code).
> ./git/herbert/cryptodev-2.6.git on the other has source inside.
crypto-2.6.git is the tree that is usually the tree that has been
already submitted upstream. cryptodev-2.6.git is the tree which
will be submitted the next time the merge window opens.
If you find no source code after the clone all you have to do is check
them out with 'git-checkout-index -a'.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
* Herbert Xu | 2007-03-17 15:12:17 [+1100]:
>What exactly is the aes-special algorithm and where can I find a copy?
The only difference between -special and -generic is the limited key
size. It was just an example.
>Yes key length support is missing as far as algorithm selection
>is concerned. I haven't worried too much about it because there
>hasn't been that many algorithms needing this.
>
>So my question is how hard is it to make aes-special support 16-bit keys?
I was browsing through the api and noticed that the key size is not
considered (except in proc code). If aes-special utilizes some hardware
device to do the job it may be possible, that the hardware does not
support all key sizes. This is the case for the Geode AES driver [1] and
for the s390 aes driver [2]. The latter checks at runtime what key sizes
are supported while Geode can only handle 16 byte long keys (according to
the source).
The author may still add part of the aes-generic code as a fall back or
try to load a fullback algorithm like VIA PadLock SHA1 does [3]. I
prefer the latter. Anyway: I don't like the idea of adding fall back code
for a key size, that I never claimed to support.
>If you find no source code after the clone all you have to do is check
>them out with 'git-checkout-index -a'.
ach, thx.
[1] drivers/crypto/geode-aes.c
[2] arch/s390/crypto/aes_s390.c
[3] drivers/crypto/padlock-sha.c
>Cheers,
--
Regards
Sebastian Siewior
On Sat, 2007-03-17 at 21:28 +0100, Sebastian Siewior wrote:
> * Herbert Xu | 2007-03-17 15:12:17 [+1100]:
>
> >What exactly is the aes-special algorithm and where can I find a copy?
> The only difference between -special and -generic is the limited key
> size. It was just an example.
>
> >Yes key length support is missing as far as algorithm selection
> >is concerned. I haven't worried too much about it because there
> >hasn't been that many algorithms needing this.
> >
> >So my question is how hard is it to make aes-special support 16-bit keys?
> I was browsing through the api and noticed that the key size is not
> considered (except in proc code). If aes-special utilizes some hardware
> device to do the job it may be possible, that the hardware does not
> support all key sizes. This is the case for the Geode AES driver [1] and
> for the s390 aes driver [2]. The latter checks at runtime what key sizes
> are supported
Currently aes-s390 registers for all three AES key sizes even if the
hardware only supports 128 bit keys. Could be changed easily to only
register for 128 bit keys but this would change nothing (beside having
correct output in /proc/crypto).
> while Geode can only handle 16 byte long keys (according to
> the source).
> The author may still add part of the aes-generic code as a fall back or
> try to load a fullback algorithm like VIA PadLock SHA1 does [3]. I
> prefer the latter. Anyway: I don't like the idea of adding fall back code
> for a key size, that I never claimed to support.
Having fall back support for unsupported parts of an algorithm sounds like
the right thing to me. In include/linux/crypto.h I found:
/*
* Set this bit if and only if the algorithm requires another algorithm of
* the same type to handle corner cases.
*/
#define CRYPTO_ALG_NEED_FALLBACK 0x00000100
which is currently not used but looks like someone has thought of implementing
that kind of fallback method?
OTOH, if aes and padlock are the only two cornercases it may be easier to
implement the fallback manually. Are there other algorithms / hardware accelerators
that would benefit from a generic fallback method?
Cheers,
Jan
* Jan Glauber | 2007-03-19 15:25:39 [+0100]:
>Having fall back support for unsupported parts of an algorithm sounds like
>the right thing to me. In include/linux/crypto.h I found:
>
>/*
> * Set this bit if and only if the algorithm requires another algorithm of
> * the same type to handle corner cases.
> */
>#define CRYPTO_ALG_NEED_FALLBACK 0x00000100
>
>which is currently not used but looks like someone has thought of implementing
>that kind of fallback method?
This is not totally true. padlock-sha makes uses of that flag and
something forbids that padlock-sha gets itself back as fall back. I did
not find out where and how does it check for hat flag, but it does.
>OTOH, if aes and padlock are the only two cornercases it may be easier to
>implement the fallback manually. Are there other algorithms / hardware accelerators
>that would benefit from a generic fallback method?
I wouldn't consider s390'aes and Geode'aes as corner cases because they
never claimed to supported those key sizes. A good example of a corner
case is padlock-sha.c I guess. They support sha1 & sha256 on hardware as
long as the data is not larger than one page.
On the other hand they maybe different interpretation of a corner case
and whether an algorithm like aes, that is standardized for 128, 192 and
256 bits, has to support all of them or may support just a subset.
We need definitely some sort of fall back method, the question is just if
the driver should implement it or the API if the driver already knows
that it can't be handled at all.
And I would like to find out how the flag gets actually checked :)
>Cheers,
>Jan
--
Regards
Sebastian Siewior