Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-crypto@vger.kernel.org, linux-crypto@ml.breakpoint.cc
Subject: Re: [1/1] HIFN: preliminary HIFN 795x driver for new async cryptoapi.
Date: Fri, 25 May 2007 13:00:05 +0400	[thread overview]
Message-ID: <20070525090004.GB3808@2ka.mipt.ru> (raw)
In-Reply-To: <E1HrV37-00076a-00@gondolin.me.apana.org.au>

On Fri, May 25, 2007 at 06:21:25PM +1000, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> > 
> > It does not - your code only supposed to work with ecb, since it is what
> > was requested during initialization time. This new scheme with templates
> > helps alot for ciphers/crypto modes which do not support several
> > templates, so I used old scheme with 'cipher' only template, not
> > 'ecb(cipher)', 'cbc(cipher)' and so on.
> 
> I just had a look and your driver should use the cra_name of "ecb(aes)"
> since ECB is what it implements.  The cra_driver_name can be ecb-aes-hifn
> (if there can only be one hifn device, otherwise make it something like
> ecb-aes-hifn-<devname> or ecb-aes-<devname>).

I implemented one mode only to show that it would be good to have one
structure allocated and use different crypto modes with only the same
callbacks. But since there is no way to determine for which mode
encryption is performed until 'mode(cipher)' string is used, I have to
allocate and initialize all supported modes and register them
saparately.

> Your priority should also be above 200 which is where assembly-optimised
> software algorithms are registered at by default.  I suggest 300.

Ok.

> > HIFN supports at least 12 different ciphers/mode (3des, des and aes,
> > each one with 4 modes), so it is not a good idea to put them all into
> > separated structures, so I rised a question about it.
> 
> Well it is a trade-off of a bit of work here vs. the ability to better
> support new cipher modes that arise.  Could we perhaps use macro helpers
> so that you don't have to type out each one by hand?

I think that would be good to have set of functions like
struct crypto_alg alloc_crypto_alg(char *name, setkey_callback,
encrypt/decrypt callbacks);
I will put them into driver initially for testing purposes, later
we could move them into generic code to be reused.

> Cheers,
> -- 
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

-- 
	Evgeniy Polyakov

  reply	other threads:[~2007-05-25  9:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-22 12:58 [1/1] HIFN: preliminary HIFN 795x driver for new async cryptoapi Evgeniy Polyakov
2007-05-22 15:19 ` Sebastian Siewior
2007-05-23  8:03   ` Evgeniy Polyakov
2007-05-23 10:02     ` Sebastian Siewior
2007-05-23 12:30       ` Evgeniy Polyakov
2007-05-25  8:31       ` Herbert Xu
2007-05-25  8:21     ` Herbert Xu
2007-05-25  9:00       ` Evgeniy Polyakov [this message]
2007-05-25 11:03         ` Herbert Xu
2007-05-25  8:14 ` Herbert Xu
2007-05-25  8:55   ` Evgeniy Polyakov
2007-05-25  9:35     ` Sebastian Siewior
2007-05-25 10:20       ` Evgeniy Polyakov
2007-05-25 11:35         ` Herbert Xu
2007-05-25 11:01     ` 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=20070525090004.GB3808@2ka.mipt.ru \
    --to=johnpol@2ka.mipt.ru \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@ml.breakpoint.cc \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox