From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: linux-crypto@vger.kernel.org, Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [1/1] HIFN 795x driver.
Date: Tue, 2 Oct 2007 14:54:31 +0400 [thread overview]
Message-ID: <20071002105431.GA28803@2ka.mipt.ru> (raw)
In-Reply-To: <20071001202214.GA15421@Chamillionaire.breakpoint.cc>
Hi.
On Mon, Oct 01, 2007 at 10:22:14PM +0200, Sebastian Siewior (linux-crypto@ml.breakpoint.cc) wrote:
> >optimisations. It also refuses to register 'ecb(des)' with min and max
> >keylen set to the same number, so right now des and 3des are removed.
> I don't know if I understood you correctly but keep this in mind:
> min and max key size is only important for the output in /proc/crypto.
> If you register an algorithm like AES which is specified for 128, 192
> and 256 bit keys you have to provide all three sizes within one
> algorithm. If you post some code that is not working I could take a
> look.
>
> After a quick look I can tell:
> - CBC is not working because when you call hifn_setup_session() from
> hifn_setup_crypto() you don't use the IV supplied by the crypto API
> (tcrypt) but set the IV to NULL and its length to zero. You should use
> something like req->base.data, 16 :)
Yep :)
iv sits in req->info, but its size can not be obtained via
crypto_ablkcipher_ivsize(crypto_ablkcipher_reqtfm(req)) for tcrypt at
least, so I added a check if req->info is not NULL and mode is not ecb,
in that case I set ivsize according to algorithm, but that can lead to
undetectible errors - if caller has a bug and iv is not set correctly,
so ivsize will be zero, but code will use some garbage as iv.
> - The code looks like you are going to remove
> hifn_encrypt_aes_ecb_{16,24,32} and set the appropriate
Yes, I've removed that.
> ACRYPTO_TYPE_AES_??? depending on ctx->current_key_len. Good.
> - You need a software queue in case your HW queue is full and you receive
> a requests which you may not drop. Currently you don't consider
> CRYPTO_TFM_REQ_MAY_BACKLOG (it is fine if you can process all requests
> no mater what).
That is what I do not like, but will implement.
> - You may want to call
> crypto_ablkcipher_set_flags(cipher, CRYPTO_TFM_RES_BAD_KEY_LEN);
> in hifn_setkey() if the key size is wrong (you may want to move the
> check for 16/24/32 from hifn_setup_session() to hifn_setkey()).
Done.
> Anyway, it looks fine from what I can say :)
Thanks for review, Sebastian, I will release new version soon with fixed
issues.
--
Evgeniy Polyakov
next prev parent reply other threads:[~2007-10-02 10:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-01 12:48 [1/1] HIFN 795x driver Evgeniy Polyakov
2007-10-01 12:51 ` Tcrypt output for " Evgeniy Polyakov
2007-10-01 13:15 ` Herbert Xu
2007-10-01 13:23 ` Evgeniy Polyakov
2007-10-01 12:57 ` [1/1] " Evgeniy Polyakov
2007-10-01 20:22 ` Sebastian Siewior
2007-10-02 10:54 ` Evgeniy Polyakov [this message]
2007-10-08 1:19 ` David McCullough
2007-10-08 2:57 ` Herbert Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071002105431.GA28803@2ka.mipt.ru \
--to=johnpol@2ka.mipt.ru \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.