Hello,
thanks your review and all comments.
----- "Linus Walleij" <[email protected]> wrote:
> For internal keys, a function for compare of HMAC function results
> could improve security considerably.
I'm afraid I don't understand what this refers to. Can you give me an example?
(You already can use OP_VERIFY with a HMAC, provide it the key, input data and
incoming HMAC value, and receive a pass/fail indication.)
> 3. A general interface for stream ciphers would be nice. The only differences
> are that they do not operate on blocks, but bits, and that they always
> require
> an IV.
I think this is already supported: the IV is specified in "session init"
operation, subsequent "session update" operations use a single
crypto_ablkcipher that implicitly carries the IV through the chain of
"update"s. Is that not sufficient?
> - The big patch 0002 to crypto/userspace is including the Makefile
> changes for patch 0004 making it non-bisectable. Also it is very large,
> is it possible to break it down a little?
It must be :) I was lazy when posting it for initial review.
> Many files are prefixed "ncr-*"
> and I don't see why - can this prefix simply be removed?
I suppose so - originally the module included two separate interfaces, "ncr-*"
corresponds to the ncr.h inteface.
> I hope the patch 0004 with software fallbacks is not strictly required
> by the userspace API so these two can be considered separately?
Those are not fallbacks - AFAIK there is currently no RSA/DSA implementation in
the kernel. It can be separated from the userspace API at the cost of loss of
functionality.
> Else can you describe how the dependecies go.. surely it must be
> possible to patch in the software fallbacks in libtom* separately?
Right now ncr-dh.c and ncr-pk.c depend on libtomcrypt, and libtomcrypt depends
on some utilities in patch 2/4. At least the second dependency can be
eliminated.
> - The big patch containing the entire libtomcrypt should be destined to
> drivers/staging or similar at this point (OK it is not a driver, should have
> been lib/staging if such a thing existed). The sheer size of it makes it
> very
> hard to review, and all attempts at breaking it in smaller pieces would
> be much appreciated.
As noted in the patch, we are considering replacing this with a libgcrypt-based
implementation; this was included mainly for functional completeness.
Thanks again for the comments,
Mirek
--
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
