Hi.
On Fri, Oct 26, 2007 at 01:55:48AM +0800, Tan Swee Heng ([EMAIL PROTECTED])
wrote:
> Hi all,
>
> I am learning CryptoAPI by porting stream ciphers into it
> (particularly eSTREAM candidates at
> <http://www.ecrypt.eu.org/stream/>). As eSTREAM ciphers manipulates IV
> differently depending on algorithm design, it seems that standard
> block modes cannot be used: ECB has no IV; CBC and CTR don't let
> ciphers control how the IV is processed.
>
> So I derived stream.c from Herbert's cbc.c and Joy's ctr.c. It wraps
> around any cipher exporting cia_ivsize and cia_setiv_crypt() from
> "struct cipher_alg". As a test case, I've used Daniel Bernstein's
> Salsa20 implementation at <http://cr.yp.to/snuffle.html> as the
> cipher. My patch against Herbert's cryptodev-2.6 git is attached.
>
> Some questions come to mind:
> 1. Is this the way to go for general stream ciphers?
> 2. Would a separate "struct stream_alg" be better than hijacking
> "struct cipher_alg"?
> 3. Currently cia_setiv_crypt() does setiv() and inplace encryption;
> is this a good design?
> 4. Should the blocksize be 1 for the stream template?
It depends. I do not know any stream cipher, which operates on 1-byte
quantity in real life, but stream means 1-byte blocksize is a correct
assumption.
Your approach is likely the less intrusive for existing block-based
design, so I believe this is a way to go.
Besides number of codying style issues (like comments, () placement,
spaces and the like) it looks good.
--
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
