Hello!
The CCMP encryption in mac80211 uses crypto API to encrypt 16 bytes at a
time. I believe this is not the best approach if hardware acceleration
is used. The ixp4xx_crypto driver doesn't even provide the "aes"
ciphers. It only provides block ciphers, such as "cbc(des)".
It would be much better if mac80211 could encrypt the whole packet at a
time. Actually, that's what the WEP code is doing.
I realize that CCMP is a more sophisticated cipher, so maybe it's not so
easy. "ccm(aes)" is probably the closest thing to what is needed, but
it's not even a block cipher, it's an AEAD.
Unfortunately, I don't see any examples of AEAD use in the kernel other
than the crypto testing module. And I'm not even sure if "ccm(aes)" is
the right choice for CCMP.
I'll appreciate if somebody with a cryptographic background could have a
look at net/mac80211/aes_ccm.c and suggest whether it could be converted
to packet-at-a-time processing.
--
Regards,
Pavel Roskin
Hello
i'm not expert with cryptographic modules, but i played sometime with the
"authenc" module, which is AEAD, and i applied it to the filesystem "ecryptfs".
In the forwarded message i added a brief description of what i do and i hope
this can be a useful example for you.
On Fri, 2010-03-12 at 11:49 +0100, Roberto Sassu wrote:
> Hello
>
> i'm not expert with cryptographic modules, but i played sometime with the
> "authenc" module, which is AEAD, and i applied it to the filesystem "ecryptfs".
> In the forwarded message i added a brief description of what i do and i hope
> this can be a useful example for you.
Thank you! That's indeed a useful example.
However, it's disappointing that the caller needs to deal explicitly
with completions. The blkcipher API is much simpler. I would have hard
time advocating a patch to CCMP that makes the code more complicated.
--
Regards,
Pavel Roskin
Pavel Roskin <[email protected]> wrote:
>
> However, it's disappointing that the caller needs to deal explicitly
> with completions. The blkcipher API is much simpler. I would have hard
> time advocating a patch to CCMP that makes the code more complicated.
You won't have to deal with completions if you allocate your
algorithm with the CRYPTO_ALG_ASYNC bit off. Of course you won't
be able to use most hardware accelerations either.
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
On Sat, 2010-03-13 at 20:28 +0800, Herbert Xu wrote:
> Pavel Roskin <[email protected]> wrote:
> >
> > However, it's disappointing that the caller needs to deal explicitly
> > with completions. The blkcipher API is much simpler. I would have hard
> > time advocating a patch to CCMP that makes the code more complicated.
>
> You won't have to deal with completions if you allocate your
> algorithm with the CRYPTO_ALG_ASYNC bit off. Of course you won't
> be able to use most hardware accelerations either.
Actually, I thought using CRYPTO_ALG_ASYNC in the mask meant to
_exclude_ asynchronous algorithms.
Is there any documentation for Linux crypto API that documents use of
CRYPTO_ALG_ASYNC? Also, I'd like to know meanings of
CRYPTO_TFM_REQ_MAY_BACKLOG and CRYPTO_TFM_REQ_MAY_SLEEP.
The crypto API feels like a minefield to me - I should check everything
in the code or even experiment to figure out how the public API works.
--
Regards,
Pavel Roskin
Pavel Roskin <[email protected]> wrote:
>
>> You won't have to deal with completions if you allocate your
>> algorithm with the CRYPTO_ALG_ASYNC bit off. Of course you won't
>> be able to use most hardware accelerations either.
>
> Actually, I thought using CRYPTO_ALG_ASYNC in the mask meant to
> _exclude_ asynchronous algorithms.
That's what I just said, no?
> Is there any documentation for Linux crypto API that documents use of
> CRYPTO_ALG_ASYNC? Also, I'd like to know meanings of
> CRYPTO_TFM_REQ_MAY_BACKLOG and CRYPTO_TFM_REQ_MAY_SLEEP.
Normally an async driver will simply drop requests and return
EBUSY when the hardware queue is full. MAY_BACKLOG allows the
caller to place a single request on a backlog queue. When that
request moves onto the hardware queue the caller will be notified
through the completion function with err set to EINPROGRESS.
This is used by drivers/md/dm-crypt.
MAY_SLEEP is only relevant for synchronous algorithms, it allows
the API to sleep which is useful if you are making a single large
request which would take an extended period of time to process.
> The crypto API feels like a minefield to me - I should check everything
> in the code or even experiment to figure out how the public API works.
Well patches to improve the API and/or documentation are welcome.
Thanks,
--
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