Re: IV copy strategy
On Sun, Nov 18, 2007 at 02:52:37PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote: On Fri, Nov 16, 2007 at 02:11:10PM +0300, Evgeniy Polyakov wrote: That's a question - should it copy IV back or not? Currently it is not required by crypto users. OK I've changed my mind :) The reason is CTR, or rather the CTR as used by IPsec. CTR itself should be able to chain, in fact one of the things I'll do later is to move most of the current CTR code into a chainable CTR with just the algorithm parameter, i.e., ctr(aes) which would be what we currently call ctr(0,16,16). We can then put a non- chainable wrapper around that, perhaps ctr-ipsec(aes). In any case, it is clear that some algorithms simply won't be able to chain because the IV exposed to the outside is not the complete IV. So my plan is to add a new flag, CRYPTO_ALG_CIPHER_NOCHAIN that you would set on algorithms that cannot be chained. The semantics is that everything else remains the same except that on encrypt calls, the req-info after completion is undefined. Users requiring chaining would then do crypto_alloc_blkcipher(foo, 0, CRYPTO_ALG_CIPHER_NOCHAIN) Hmm, users who want chaining will set flag _NOCHAIN :) I would call it something more informative... For hardware offload devices such as yours where chaining does not come naturally you could then elect to not implement chaining and just set the flag. Please let me know if you see any problems with this approach. I'm not sure what user will do, when it request chaining, but driver will set CRYPTO_ALG_CIPHER_NOCHAIN itself and return wrong/old in req-info? For IPsec it is not an issue though, but I can not say that for all. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HIFN 00/03]: RNG support v2
On Sunday 18 November 2007 22:32:52 Patrick McHardy wrote: These patches add support for using the HIFN rng. Acked-by: Michael Buesch [EMAIL PROTECTED] Patrick, can you send this patchset to Andrew for inclusion into -mm? -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HIFN 00/03]: RNG support v2
Michael Buesch wrote: On Sunday 18 November 2007 22:32:52 Patrick McHardy wrote: These patches add support for using the HIFN rng. Acked-by: Michael Buesch [EMAIL PROTECTED] Patrick, can you send this patchset to Andrew for inclusion into -mm? I think he already pulls from Herbert's cryptodev-2.6 tree (otherwise the patches useless anyway since the HIFN driver is only in that tree). - To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Moving xor_* functions into common header file
Hi,
'grep static void xor_ crypto/*' shows that cbc.c, ctr.c, pcbc.c and
xcbc.c share similar xor_* functions. It seems a good idea to
encourage code reuse by putting them into a common header (iirc
Evgeniy suggested it when reviewing one of my earlier mail). It will
also be useful to me when porting other eSTREAM ciphers. So I would
like to move them into include/crypto/xor_n.h and make them all
static inline. Any objections?
For xor_byte and xor_quad, the implementation in ctr.c differs from
that in cbc.c and pcbc.c. In cbc.c and pcbc.c we have:
static void xor_byte(u8 *a, const u8 *b, unsigned int bs)
{
do {
*a++ ^= *b++;
} while (--bs);
}
static void xor_quad(u8 *dst, const u8 *src, unsigned int bs)
{
u32 *a = (u32 *)dst;
u32 *b = (u32 *)src;
do {
*a++ ^= *b++;
} while ((bs -= 4));
}
while in ctr.c it is:
static void xor_byte(u8 *a, const u8 *b, unsigned int bs)
{
for (; bs; bs--)
*a++ ^= *b++;
}
static void xor_quad(u8 *dst, const u8 *src, unsigned int bs)
{
u32 *a = (u32 *)dst;
u32 *b = (u32 *)src;
for (; bs = 4; bs -= 4)
*a++ ^= *b++;
xor_byte((u8 *)a, (u8 *)b, bs);
}
The former saves one check by assuming bs 0. For cbc.c and pcbc.c,
we can assume bs 0 since xor() uses the non-negative blocksize. For
ctr.c, we check bs == 0 as the call to xor_quad uses min(nbytes,
bsize). Given that we need both semantics, I would like to propose
renaming the former as xor_byte_quick() and xor_quad_block() in the
common header. Would that be fine?
Swee Heng
-
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [camellia-oss:00952] Re: [PATCH 5/5] camellia: de-unrolling, 64bit-ization
Hi, Sun, 18 Nov 2007 20:30:16 -0800 [Subject: Re: [camellia-oss:00952] Re: [PATCH 5/5] camellia: de-unrolling, 64bit-ization] Denys Vlasenko [EMAIL PROTECTED] 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 (visually shorter) form using macros. And here is 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. This shaves off another ~1k: dec hex filename 2141453a6 2.6.23.1.camellia6.t/crypto/camellia.o 205185026 2.6.23.1.camellia7.t/crypto/camellia.o 163553fe3 2.6.23.1.camellia6.t64/crypto/camellia.o 158133dc5 2.6.23.1.camellia7.t64/crypto/camellia.o At the moment I cannot run test it, try to do it ASAP. Takamiya-san, can you review attached patch please? Sorry for late reply. I think you're testing now:-), and if speed impact is less than 1% as you say, I think it is acceptable. The smaller code size is, the easier to enable camellia in the embedded systems. Regards, Acked-by: Noriaki TAKAMIYA [EMAIL PROTECTED] -- Noriaki TAKAMIYA - To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HIFN 00/03]: RNG support v2
On Monday 19 November 2007 19:25:25 Patrick McHardy wrote: Michael Buesch wrote: On Sunday 18 November 2007 22:32:52 Patrick McHardy wrote: These patches add support for using the HIFN rng. Acked-by: Michael Buesch [EMAIL PROTECTED] Patrick, can you send this patchset to Andrew for inclusion into -mm? I think he already pulls from Herbert's cryptodev-2.6 tree (otherwise the patches useless anyway since the HIFN driver is only in that tree). Ok, well. Then apply it to any tree you like and push it upstream somehow. I'm OK with it. -- Greetings Michael. - To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving xor_* functions into common header file
On Tue, Nov 20, 2007 at 02:34:48AM +0800, Tan Swee Heng wrote:
Hi,
'grep static void xor_ crypto/*' shows that cbc.c, ctr.c, pcbc.c and
xcbc.c share similar xor_* functions. It seems a good idea to
encourage code reuse by putting them into a common header (iirc
Evgeniy suggested it when reviewing one of my earlier mail). It will
also be useful to me when porting other eSTREAM ciphers. So I would
like to move them into include/crypto/xor_n.h and make them all
static inline. Any objections?
Do you actually need to xor anything that's not a multiple of
8 bytes?
I'm currently working on a patch to just restrict the block
size for non-stream ciphers to multiples of 8 since that's what
we have anyway. That allows us to just use bitmap_xor.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
