On Thursday 22 November 2007 14:41, Denys Vlasenko wrote:
> Patches start from 5 because pathches 1..4 are already
> in cryptodev-2.6.
>
> camellia5:
> Remove unused macro params.
> Use (u8)(expr) instead of (expr) & 0xff,
> helps gcc to realize how to use simpler commands.
On Thursday 22 November 2007 14:41, Denys Vlasenko wrote:
> camellia9:
> Adds 64-bit key setup, it is used if BITS_PER_LONG is 64.
> 30% faster key setup and 1k (7%) smaller module on amd64.
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff -urpN cryptodev-2.6.camellia
On Thursday 22 November 2007 14:41, Denys Vlasenko wrote:
> camellia8:
> Analogously to camellia7 patch, move
> "absorb kw2 to other subkeys" and "absorb kw4 to other subkeys"
> code parts into camellia_setup_tail(). This further reduces
> source and object code size
On Thursday 22 November 2007 14:41, Denys Vlasenko wrote:
> camellia7:
> Move "key XOR is end of F-function" code part into
> camellia_setup_tail(), it is sufficiently similar
> between camellia_setup128 and camellia_setup256.
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED
On Thursday 22 November 2007 14:41, Denys Vlasenko wrote:
> camellia6:
> unifies encrypt/decrypt routines for different key lengths.
> This reduces module size by ~25%, with tiny (less than 1%)
> speed impact.
> Also collapses encrypt/decrypt into more readable
>
Patches start from 5 because pathches 1..4 are already
in cryptodev-2.6.
camellia5:
Remove unused macro params.
Use (u8)(expr) instead of (expr) & 0xff,
helps gcc to realize how to use simpler commands.
Move CAMELLIA_FLS macro closer to encrypt/decrypt routines.
ca
On Thursday 22 November 2007 04:25, Herbert Xu wrote:
> On Wed, Nov 21, 2007 at 12:23:49AM -0800, Denys Vlasenko wrote:
> > On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> > > Patches start from 5 because pathches 1..4 are already
> > > in cryptodev-2.6.
> > >
> > > camellia5:
> > >
On Thu, Nov 22, 2007 at 04:49:12PM +0800, Herbert Xu wrote:
> [CRYPTO] aead: Add givcrypt operation
>
> This patch adds the crypto_aead_givcrypt and associated support elements.
> The rationale is identical to that of the block cipher givcrypt operation,
> i.e., sometimes only the algorithm knows
On Thu, Nov 22, 2007 at 03:37:02PM +0300, Evgeniy Polyakov wrote:
>
> > First of all givcrypt is designed to work for hardware devices too.
> > If they can generate their own IVs then they should directly hook
> > up to the givcrypt method and use the givcipher type.
>
> But for example chainiv_gi
On Thu, Nov 22, 2007 at 08:09:37PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> On Thu, Nov 22, 2007 at 02:57:07PM +0300, Evgeniy Polyakov wrote:
> >
> > Somehow you described that to others - just combine things together and
> > put to Documentation/crypto and that will be enough.
>
> Patches a
On Wed, Nov 21, 2007 at 12:23:49AM -0800, Denys Vlasenko wrote:
> On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> > Patches start from 5 because pathches 1..4 are already
> > in cryptodev-2.6.
> >
> > camellia5:
> > adds 64-bit key setup, it is used if BITS_PER_LONG is 64.
> >
On Wed, Nov 21, 2007 at 12:25:10AM -0800, Denys Vlasenko wrote:
> On Wednesday 21 November 2007 00:22, Denys Vlasenko wrote:
> > camellia6:
> > unifies encrypt/decrypt routines for different key lengths.
> > This reduces module size by ~25%, with tiny (less than 1%)
> > spee
On Thu, Nov 22, 2007 at 03:05:00PM +0300, Evgeniy Polyakov wrote:
>
> What if dm-crypt will use the same interface (or other bulk-processing
> user) will use it with software crypto? Or was it specially designed for
> ipsec only?
dm-crypt (when we convert it to using givcrypt instead of its
own ha
On Thu, Nov 22, 2007 at 02:57:07PM +0300, Evgeniy Polyakov wrote:
>
> Somehow you described that to others - just combine things together and
> put to Documentation/crypto and that will be enough.
Patches are welcome :)
> For example this patchset looks like possible first step in proper
> chaini
On Thu, Nov 22, 2007 at 07:26:13PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> On Thu, Nov 22, 2007 at 02:17:11PM +0300, Evgeniy Polyakov wrote:
> >
> > > + spin_lock_bh(&ctx->lock);
> >
> > Crypto hardware can access iv in interrupt context and thus this can get
> > wrong data.
>
> This lock
On Thu, Nov 22, 2007 at 07:31:16PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> > Idea and implementation look very good, I have couple of comments on
> > patches and one generic comment here: you absolutely have to write at
> > least bits of documentation for this new interfaces, how they behave
On Thu, Nov 22, 2007 at 07:28:15PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> On Thu, Nov 22, 2007 at 02:18:07PM +0300, Evgeniy Polyakov wrote:
> >
> > On Thu, Nov 22, 2007 at 04:48:41PM +0800, Herbert Xu ([EMAIL PROTECTED])
> > wrote:
> > > [CRYPTO] blkcipher: Merge ablkcipher and blkcipher
On Thu, Nov 22, 2007 at 02:25:59PM +0300, Evgeniy Polyakov wrote:
>
> Idea and implementation look very good, I have couple of comments on
> patches and one generic comment here: you absolutely have to write at
> least bits of documentation for this new interfaces, how they behave and
> who and how
On Thu, Nov 22, 2007 at 02:18:07PM +0300, Evgeniy Polyakov wrote:
>
> On Thu, Nov 22, 2007 at 04:48:41PM +0800, Herbert Xu ([EMAIL PROTECTED])
> wrote:
> > [CRYPTO] blkcipher: Merge ablkcipher and blkcipher into one option/module
> >
> > Now that we have the givcipher type, both blkcipher and ab
On Thu, Nov 22, 2007 at 02:17:11PM +0300, Evgeniy Polyakov wrote:
>
> > + spin_lock_bh(&ctx->lock);
>
> Crypto hardware can access iv in interrupt context and thus this can get
> wrong data.
This lock only guards against other callers of this function.
It doesn't care about how you do the under
Hi Herbert.
On Thu, Nov 22, 2007 at 04:47:58PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> This series of patches introduces IV generators which can be
> accessed through the givcrypt operation on block ciphers (other
> than crypto_blkcipher which should not be used for new code).
>
> The givc
Hi Herbert.
On Thu, Nov 22, 2007 at 04:48:41PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> [CRYPTO] blkcipher: Merge ablkcipher and blkcipher into one option/module
>
> Now that we have the givcipher type, both blkcipher and ablkcipher algorithms
> will use it to create givcipher objects. As
On Thu, Nov 22, 2007 at 04:48:43PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> +static int chainiv_givcrypt(struct ablkcipher_request *req)
> +{
> + struct crypto_ablkcipher *geniv = crypto_ablkcipher_reqtfm(req);
> + struct chainiv_ctx *ctx = crypto_ablkcipher_ctx(geniv);
> + struct
[CRYPTO] eseqiv: Add Encrypted Sequence Number IV Generator
This generator generates an IV based on a sequence number by xoring it
with a salt and then encrypting it with the same key as used to encrypt
the plain text. This algorithm requires that the block size be equal
to the IV size. It is ma
[CRYPTO] seqiv: Add Sequence Number IV Generator
This generator generates an IV based on a sequence number by xoring it
with a salt. This algorithm is mainly useful for CTR and similar modes.
This patch also sets it as the default IV generator for ctr.
Signed-off-by: Herbert Xu <[EMAIL PROTECTE
[CRYPTO] blkcipher: Create default givcipher instances
This patch makes crypto_alloc_ablkcipher/crypto_spawn_ablkcipher always
return objects that are capable of generating their own IVs before encryption
through givcrypt. Each algorithm may specify its default IV generator
through the geniv fiel
[CRYPTO] ablkcipher: Added ablkcipher_request_complete
This patch adds the helper ablkcipher_request_complete which should be
called when an ablkcipher algorithm has completed a request.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
include/crypto/algapi.h |6 ++
1 files changed, 6
[CRYPTO] aead: Add givcrypt operation
This patch adds the crypto_aead_givcrypt and associated support elements.
The rationale is identical to that of the block cipher givcrypt operation,
i.e., sometimes only the algorithm knows how the IV should be generated.
The aead_request structure gains two
[CRYPTO] authenc: Add givcrypt operation
This patch implements the givcrypt function for authenc. It simply
calls the givcrypt operation on the underlying cipher instead of encrypt.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
crypto/authenc.c | 21 +
1 files changed
[CRYPTO] chainiv: Add chain IV generator
The chain IV generator is the one we've been using in the IPsec stack.
It simply starts out with a random IV, then uses the last block of each
encrypted packet's cipher text as the IV for the next packet.
It can only be used by synchronous ciphers since we
[CRYPTO] blkcipher: Add givcipher_alloc_inst/givcipher_free_inst
This patch creates the infrastructure to help the construction of givcipher
templates that wrap around existing blkcipher/ablkcipher algorithms by adding
an IV generator to them.
It also adds the function crypto_spawn_nivcipher that
[CRYPTO] blkcipher: Merge ablkcipher and blkcipher into one option/module
Now that we have the givcipher type, both blkcipher and ablkcipher algorithms
will use it to create givcipher objects. As such it no longer makes sense
to split the system between ablkcipher and blkcipher. In particular, b
[CRYPTO] cryptd: Use geniv of the underlying algorithm
If the underlying algorithm specifies a specific geniv algorithm then
we should use it for the cryptd version as well.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
crypto/cryptd.c |3 +++
1 files changed, 3 insertions(+)
diff --gi
[CRYPTO] ablkcipher: Add givcrypt operation and givcipher type
Different block cipher modes have different requirements for intialisation
vectors. For example, CBC can use a simple randomly generated IV while
modes such as CTR must use an IV generation mechanisms that give a stronger
guarantee on
[CRYPTO] api: Add crypto_inc and crypto_xor
With the addition of more stream ciphers we need to curb the proliferation
of ad-hoc xor functions. This patch creates a generic pair of functions,
crypto_inc and crypto_xor which does big-endian increment and exclusive or,
respectively.
For optimum pe
[CRYPTO] cbc: Use crypto_xor
This patch replaces the custom xor in CBC with the generic crypto_xor.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
crypto/cbc.c | 93 ++-
1 files changed, 16 insertions(+), 77 deletions(-)
diff --git a
Hi:
This series of patches introduces the fcuntionc crypto_xor and
crypto_inc. It then uses them in the spots where duplicates
have been created for the same operations.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gond
[CRYPTO] cbc: Require block size to be a power of 2
All common block ciphers have a block size that's a power of 2. In fact,
all of our block ciphers obey this rule.
If we require this then CBC can be optimised to avoid an expensive divide
on in-place decryption.
I've also changed the saving of
[CRYPTO] pcbc: Use crypto_xor
This patch replaces the custom xor in CBC with the generic crypto_xor.
It changes the operations for in-place encryption slightly to avoid
calling crypto_xor with tmpbuf since it is not necessarily aligned.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
crypto/
[CRYPTO] ctr: Use crypto_inc and crypto_xor
This patch replaces the custom inc/xor in CTR with the generic functions.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
---
crypto/ctr.c | 71 +--
1 files changed, 16 insertions(+), 55 deletion
Hi:
This series of patches introduces IV generators which can be
accessed through the givcrypt operation on block ciphers (other
than crypto_blkcipher which should not be used for new code).
The givcrypt operation is identical to encrypt except that the
IV is generated by the algorithm instead of
41 matches
Mail list logo
