Re: [PATCH 00/17] Multiple changes to crypto/ansi_cprng.c
On Wed, Dec 03, 2014 at 03:27:53PM -0500, George Spelvin wrote: So, generally speaking I'm ok with most of this I think, One open issue... I thought you had said that the non-determinsitic version was not in the current X9.31 and I had the impression that it wasn't wanted. I've got reorganized patch series that gets rid of that and just tweaks the comments. I presume you're referring to the deterministic DT vector here? It is currently in the implementation, and I personally have no need for a non-deterministic variant. I'm fine if you add it as long as the default remains the same as it currently is. I'm happy to put it back, of course. Or just hold off until Herbert chimes in with an opinion. As an example of the reorganization, now the comment for patch 4 in the series is a bit clearer: crypto: ansi_cprng - Eliminate ctx-I and ctx-last_rand_data Careful use of the other available buffers avoids the need for these, shrinking the context by 32 bytes. Neither the debug output nor the FIPS-required anti-repetition check are changed in the slightest. (That's because I change the debug output in patches 2 and 3, to make this more-sensitive patch easier to review.) but before it goes anywhere, it really needs to pass the NIST and FIPS test vectors. Can you do that please and post the results? It of course passes the ones in testmgr.h, and I can add the others from http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf and http://csrc.nist.gov/groups/STM/cavp/documents/rng/rngtestvectors.zip I didn't know there were separate FIPS test vectors for this PRNG; can you give me a clue where to find them? I'm also not sure what the results look like. As I mentioned previously, I have been unable to figure out how to make the tcrypt code print anything in the event of a successful test, so its output is the empty string. I am using my own version which prints cprng: Test %d passed, and I can turn debugging on, but the 1-round MCT produces an annoying amount of output in that case. (Note to self: teach test_cprng to test odd-sized reads, since that was a previous bug source and I'm touching that code some more.) I'm fine with changing the output, as I don't think anything particularly relies on the format, but I can't speak for others. The current debug output for the first 5 testmgr.h tests (the 6th is omitted) is follows, but obviously things get reconfirmed right at the end. getting 16 random bytes for context 88042ce41b18 Calling _get_more_prng_bytes for context 88042ce41b18 DT = e6b3be782a23fa62d71d4afbb0e922f9 V = 8000 I = 92640cf08d302f2550ea3d73d1985385 V^I = 12640cf08d302f2550ea3d73d1985385 R = 59531ed13bb0c05584796685c12f7641 R^I = cb371221b680ef70d4935bf610b725c4 V' = 2ac489ad47640b6d86380229e769adc3 DT' = e6b3be782a23fa62d71d4afbb0e922fa Returning new block for context 88042ce41b18 returning 16 from get_prng_bytes in context 88042ce41b18 cprng: Test 0 passed getting 16 random bytes for context 88042ce41b18 Calling _get_more_prng_bytes for context 88042ce41b18 DT = e6b3be782a23fa62d71d4afbb0e922fa V = c000 I = b30a8cba1c4cd3a14af7d9db9488f5f0 V^I = 730a8cba1c4cd3a14af7d9db9488f5f0 R = 7c222cf4ca8fa24c1c9cb641a9f3220d R^I = cf28a04ed6c371ed566b6f9a3d7bd7fd V' = fcbd61e7c51dd167624c56cb97b4c66d DT' = e6b3be782a23fa62d71d4afbb0e922fb Returning new block for context 88042ce41b18 returning 16 from get_prng_bytes in context 88042ce41b18 cprng: Test 1 passed getting 16 random bytes for context 88042ce41b18 Calling _get_more_prng_bytes for context 88042ce41b18 DT = e6b3be782a23fa62d71d4afbb0e922fb V = e000 I = d761699cc3de4a90234c62eec2479cd9 V^I = 3761699cc3de4a90234c62eec2479cd9 R = 8aaa003966675be529142881a94d4ec7 R^I = 5dcb69a5a5b911750a584a6f6b0ad21e V' = ef2c1fbf609a68f8fe5110636bf4bf6a DT' = e6b3be782a23fa62d71d4afbb0e922fc Returning new block for context 88042ce41b18 returning 16 from get_prng_bytes in context 88042ce41b18 cprng: Test 2 passed getting 16 random bytes for context 88042ce41b18 Calling _get_more_prng_bytes for context 88042ce41b18 DT = e6b3be782a23fa62d71d4afbb0e922fc V = f000 I = 048ecb25943e8c31d614cd8a23f13f84 V^I = f48ecb25943e8c31d614cd8a23f13f84 R = 88dda456302423e5f69da57e7b95c73a R^I = 8c536f73a41aafd4208968f45864f8be V' = 48893b71bce400b65e21ba378a0ad570 DT' = e6b3be782a23fa62d71d4afbb0e922fd Returning new block for context 88042ce41b18 returning 16 from get_prng_bytes in context 88042ce41b18 cprng: Test 3 passed getting 16 random bytes for context 88042ce41b18 Calling _get_more_prng_bytes for context 88042ce41b18 DT = e6b3be782a23fa62d71d4afbb0e922fd V = f800 I = 3a6a1754bdf6f844e53662990cadc492 V^I
Re: [PATCH] staging: crypto: fixed style errors in ablkcipher.c
Joshua,
Your subject, [PATCH] staging: crypto: fixed style errors in
ablkcipher.c is misleading. 'staging' is a location in the tree,
drivers/staging/, not a separate git tree. So your subject for this
series should have been [PATCH] crypto: ablkcipher: Cleanup minor
checkpatch error. More below.
On Fri, Dec 05, 2014 at 02:06:16PM +0900, Joshua I. James wrote:
From: Joshua I. James jos...@cybercrimetech.com
Fixed style errors reported by checkpatch.
WARNING: Missing a blank line after declarations
+ u8 *end_page = (u8 *)(((unsigned long)(start + len - 1)) PAGE_MASK);
+ return max(start, end_page);
WARNING: line over 80 characters
+ scatterwalk_start(walk-out,
scatterwalk_sg_next(walk-out.sg));
WARNING: Missing a blank line after declarations
+ int err = ablkcipher_copy_iv(walk, tfm, alignmask);
+ if (err)
While checkpatch is correct with the above, alone they don't justify a
patch.
ERROR: do not use assignment in if condition
+ if ((err = crypto_register_instance(tmpl, inst))) {
imho, this one is a good cleanup. Especially in crypto code. I would
like to see a comment in this commit message explaining that the code
was reviewed to make sure it wasn't an actual bug, and this is indeed
just a style cleanup.
I would also explain that since it's worth doing a patch for the
checkpatch error, we may as well hit a few warnings while we are here.
Signed-off-by: Joshua I. James jos...@cybercrimetech.com
---
crypto/ablkcipher.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/crypto/ablkcipher.c b/crypto/ablkcipher.c
index 40886c4..7bbc8b4 100644
--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -69,6 +69,7 @@ static inline void ablkcipher_queue_write(struct
ablkcipher_walk *walk,
static inline u8 *ablkcipher_get_spot(u8 *start, unsigned int len)
{
u8 *end_page = (u8 *)(((unsigned long)(start + len - 1)) PAGE_MASK);
+
return max(start, end_page);
}
This one is fine.
@@ -86,7 +87,8 @@ static inline unsigned int ablkcipher_done_slow(struct
ablkcipher_walk *walk,
if (n == len_this_page)
break;
n -= len_this_page;
- scatterwalk_start(walk-out,
scatterwalk_sg_next(walk-out.sg));
+ scatterwalk_start(walk-out, scatterwalk_sg_next(
+ walk-out.sg));
nit: I would just ignore this warning. checkpatch just points you in a
direction, it isn't an enforcer of policy.
Especially here in crypto code, I don't like to see any changes that
make me start counting braces or otherwise looking for tricks. Because
that means I'm questioning the submitters motivation. The goal with
checkpatch is to make the code *more* obvious and readable. The above
change does the opposite.
}
return bsize;
@@ -284,6 +286,7 @@ static int ablkcipher_walk_first(struct
ablkcipher_request *req,
walk-iv = req-info;
if (unlikely(((unsigned long)walk-iv alignmask))) {
int err = ablkcipher_copy_iv(walk, tfm, alignmask);
+
if (err)
return err;
}
No problem here.
@@ -589,7 +592,8 @@ static int crypto_givcipher_default(struct crypto_alg
*alg, u32 type, u32 mask)
if (IS_ERR(inst))
goto put_tmpl;
- if ((err = crypto_register_instance(tmpl, inst))) {
+ err = crypto_register_instance(tmpl, inst);
+ if (err) {
tmpl-free(inst);
goto put_tmpl;
}
This is a nice cleanup that justifies doing the patch. Just mention in
the commit message why this looks like it wasn't a bug (was it supposed
to be '==' ?) and the change makes that clear. I'm really looking to
see that you are thinking about if the change is appropriate, not just
blindly making checkpatch shut up.
thx,
Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: crypto: fixed style error in aead.c
Joshua,
On Fri, Dec 05, 2014 at 02:24:44PM +0900, Joshua I. James wrote:
From: Joshua I. James jos...@cybercrimetech.com
Fixed style error identified by checkpatch.
ERROR: do not use assignment in if condition
+ if ((err = crypto_register_instance(tmpl, inst))) {
Short comment needed here like I mentioned with the first patch. Also,
subject line needs corrected as with the first.
Signed-off-by: Joshua I. James jos...@cybercrimetech.com
---
crypto/aead.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/crypto/aead.c b/crypto/aead.c
index 547491e..710 100644
--- a/crypto/aead.c
+++ b/crypto/aead.c
@@ -448,7 +448,8 @@ static int crypto_nivaead_default(struct crypto_alg *alg,
u32 type, u32 mask)
if (IS_ERR(inst))
goto put_tmpl;
- if ((err = crypto_register_instance(tmpl, inst))) {
+ err = crypto_register_instance(tmpl, inst);
+ if (err) {
tmpl-free(inst);
goto put_tmpl;
}
I haven't looked at the rest of the series yet, but if they are just
like this one, Herbert may prefer just to put these all in one patch.
I'll add him to the To: and you should wait for his response.
thx,
Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: crypto: fixed style error in af_alg.c
On Fri, Dec 05, 2014 at 02:38:40PM +0900, Joshua I. James wrote:
From: Joshua I. James jos...@cybercrimetech.com
Fixed style error identified by checkpatch.
ERROR: space required before the open parenthesis '('
+ switch(cmsg-cmsg_type) {
Signed-off-by: Joshua I. James jos...@cybercrimetech.com
---
crypto/af_alg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Subject line, and this change really doesn't justify a patch by itself.
If Herbert prefers them merged into one, I'd include this change,
otherwise, I'd drop it.
It'd also be a good idea to run ./scripts/get_maintainer.pl on your
patch to determine who to include in the To/Cc on the next version of
this series.
thx,
Jason.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] staging: crypto: fixed style error in ahash.c
On Fri, Dec 05, 2014 at 02:44:54PM +0900, Joshua I. James wrote:
From: Joshua I. James jos...@cybercrimetech.com
Fixed style error identified by checkpatch.
WARNING: Missing a blank line after declarations
+ unsigned int unaligned = alignmask + 1 - (offset alignmask);
+ if (nbytes unaligned)
Signed-off-by: Joshua I. James jos...@cybercrimetech.com
---
crypto/ahash.c | 1 +
1 file changed, 1 insertion(+)
Same comment as the third patch.
thx,
Jason.
diff --git a/crypto/ahash.c b/crypto/ahash.c
index f6a36a5..dd28906 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -55,6 +55,7 @@ static int hash_walk_next(struct crypto_hash_walk *walk)
if (offset alignmask) {
unsigned int unaligned = alignmask + 1 - (offset alignmask);
+
if (nbytes unaligned)
nbytes = unaligned;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] crypto: AF_ALG: add AEAD support
On Wed, Dec 03, 2014 at 08:57:24PM +0100, Stephan Mueller wrote:
+ if (ctx-merge) {
+ sg = sgl-sg + sgl-cur - 1;
+ len = min_t(unsigned long, len,
+ PAGE_SIZE - sg-offset - sg-length);
+
+ err = memcpy_fromiovec(page_address(sg_page(sg)) +
+sg-offset + sg-length,
+msg-msg_iov, len);
+ if (err)
+ goto unlock;
+
+ sg-length += len;
+ ctx-merge = (sg-offset + sg-length) (PAGE_SIZE - 1);
+
+ ctx-used += len;
+ copied += len;
+ size -= len;
+ }
Any reason why you got rid of the outer loop here? This will cause
short writes I think.
+static struct proto_ops algif_aead_ops = {
+ .family = PF_ALG,
+
+ .connect= sock_no_connect,
+ .socketpair = sock_no_socketpair,
+ .getname= sock_no_getname,
+ .ioctl = sock_no_ioctl,
+ .listen = sock_no_listen,
+ .shutdown = sock_no_shutdown,
+ .getsockopt = sock_no_getsockopt,
+ .mmap = sock_no_mmap,
+ .bind = sock_no_bind,
+ .accept = sock_no_accept,
+
+ .release= af_alg_release,
+ .sendmsg= aead_sendmsg,
+ .sendpage = aead_sendpage,
+ .recvmsg= aead_recvmsg,
+ .poll = aead_poll,
+ .setsockopt = aead_setsockopt,
No it should go into the parent setsockopt. Perhaps add a setsockopt
to af_alg_type in order to keep this out of the generic code.
Thanks,
--
Email: Herbert Xu herb...@gondor.apana.org.au
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] crypto: AF_ALG: add random number generator support
On Wed, Dec 03, 2014 at 08:59:01PM +0100, Stephan Mueller wrote:
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock-sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask-private;
+ int err = -EFAULT;
+
+ if (len == 0)
+ return 0;
+ if (len MAXSIZE)
+ len = MAXSIZE;
+
+ lock_sock(sk);
This lock simply protects ctx-result. Since you're using a
tiny buffer why not just put it on the stack?
+ u8 *buf = kmalloc(seedsize, GFP_KERNEL);
+ if (!buf)
+ goto err;
+ get_random_bytes(buf, seedsize);
+ ret = crypto_rng_reset(private, buf, len);
I think you should leave the seeding and the seed to the user.
Perhaps do it through setsockopt (on the parent socket).
Cheers,
--
Email: Herbert Xu herb...@gondor.apana.org.au
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/5] crypto: AF_ALG: add user space interface for AEAD
On Wed, Dec 03, 2014 at 08:55:42PM +0100, Stephan Mueller wrote: AEAD requires the caller to specify the following information separate from the data stream. This information allows the AEAD interface handler to identify the AAD, ciphertext/plaintext and the authentication tag: * Associated authentication data of arbitrary length and length * Length of authentication tag for encryption Signed-off-by: Stephan Mueller smuel...@chronox.de Patch applied. -- Email: Herbert Xu herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] crypto: qat - Fix for invalid dma mapping and numa
On 10/13/2014 06:24 PM, Tadeusz Struk wrote: Hi, These two patches fix invalid (zero length) dma mapping and enforce numa configuration for maximum performance. Change log: v2 - Removed numa node calculation based bus number and use predefined functions instead. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com --- Tadeusz Struk (2): crypto: qat - Prevent dma mapping zero length assoc data crypto: qat - Enforce valid numa configuration drivers/crypto/qat/qat_common/adf_accel_devices.h |3 +- drivers/crypto/qat/qat_common/adf_transport.c | 12 +--- drivers/crypto/qat/qat_common/qat_algs.c |7 +++-- drivers/crypto/qat/qat_common/qat_crypto.c|8 +++-- drivers/crypto/qat/qat_dh895xcc/adf_admin.c |2 + drivers/crypto/qat/qat_dh895xcc/adf_drv.c | 32 - drivers/crypto/qat/qat_dh895xcc/adf_isr.c |2 + 7 files changed, 32 insertions(+), 34 deletions(-) Hi Herbert, Looks like these two are not in cryptodev-2.6 yet. Do you plan to merge it sometime soon or should I generate incremental patches based on crypto-2.6 instead of cryptodev-2.6 Thanks, Tadeusz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH] crypto: drbg - panic on continuous self test error
This patch adds a panic if the FIPS 140-2 self test error failed. Note, that entire code is only executed with fips_enabled (i.e. when the kernel is booted with fips=1. It is therefore not executed for 99.9% of all user base. As mathematically such failure cannot occur, this panic should never be triggered. But to comply with NISTs current requirements, an endless loop must be replaced with the panic. When the new version of FIPS 140 will be released, this entire continuous self test function will be ripped out as it will not be needed any more. This patch is functionally equivalent as implemented in ansi_cprng.c and drivers/char/random.c. Signed-off-by: Stephan Mueller smuel...@chronox.de --- crypto/drbg.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 9fb38a5..2c46d5e 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -222,15 +222,6 @@ static inline unsigned short drbg_sec_strength(drbg_flag_t flags) * function. Thus, the function implicitly knows the size of the * buffer. * - * The FIPS test can be called in an endless loop until it returns - * true. Although the code looks like a potential for a deadlock, it - * is not the case, because returning a false cannot mathematically - * occur (except once when a reseed took place and the updated state - * would is now set up such that the generation of new value returns - * an identical one -- this is most unlikely and would happen only once). - * Thus, if this function repeatedly returns false and thus would cause - * a deadlock, the integrity of the entire kernel is lost. - * * @drbg DRBG handle * @buf output buffer of random data to be checked * @@ -257,6 +248,8 @@ static bool drbg_fips_continuous_test(struct drbg_state *drbg, return false; } ret = memcmp(drbg-prev, buf, drbg_blocklen(drbg)); + if (!ret) + panic(DRBG continuous self test failed\n); memcpy(drbg-prev, buf, drbg_blocklen(drbg)); /* the test shall pass when the two compared values are not equal */ return ret != 0; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/5] crypto: AF_ALG: add AEAD support
Am Freitag, 5. Dezember 2014, 23:46:06 schrieb Herbert Xu:
Hi Herbert,
On Wed, Dec 03, 2014 at 08:57:24PM +0100, Stephan Mueller wrote:
+ if (ctx-merge) {
+ sg = sgl-sg + sgl-cur - 1;
+ len = min_t(unsigned long, len,
+ PAGE_SIZE - sg-offset - sg-length);
+
+ err = memcpy_fromiovec(page_address(sg_page(sg)) +
+ sg-offset + sg-length,
+ msg-msg_iov, len);
+ if (err)
+ goto unlock;
+
+ sg-length += len;
+ ctx-merge = (sg-offset + sg-length) (PAGE_SIZE - 1);
+
+ ctx-used += len;
+ copied += len;
+ size -= len;
+ }
Any reason why you got rid of the outer loop here? This will cause
short writes I think.
You are absolutely right. I removed it as I do not have the multiple sgl
entries. But now as you mentioned it, I still need it if size
aead_sndbuf(sk).
This will be fixed in the next installment.
+static struct proto_ops algif_aead_ops = {
+ .family = PF_ALG,
+
+ .connect= sock_no_connect,
+ .socketpair = sock_no_socketpair,
+ .getname= sock_no_getname,
+ .ioctl = sock_no_ioctl,
+ .listen = sock_no_listen,
+ .shutdown = sock_no_shutdown,
+ .getsockopt = sock_no_getsockopt,
+ .mmap = sock_no_mmap,
+ .bind = sock_no_bind,
+ .accept = sock_no_accept,
+
+ .release= af_alg_release,
+ .sendmsg= aead_sendmsg,
+ .sendpage = aead_sendpage,
+ .recvmsg= aead_recvmsg,
+ .poll = aead_poll,
+ .setsockopt = aead_setsockopt,
No it should go into the parent setsockopt. Perhaps add a setsockopt
to af_alg_type in order to keep this out of the generic code.
I was thinking about that for quite a while. My thought for the current
approach was that the actual cipher operation happens in the child FD (i.e.
after accept). AAD is delivered to that FD. Therefore, I thought that the size
of the AAD can be specific to that operational FD.
If we move it to the parent setsockopt, all child FDs have the same AAD size.
If you think that this is the right course of action, I can surely implement
that.
Would you please be so kind and help me understand when some operations are
intended for the parent FD and when for the child FD?
Thanks
--
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] crypto: AF_ALG: add random number generator support
Am Freitag, 5. Dezember 2014, 23:53:59 schrieb Herbert Xu:
Hi Herbert,
On Wed, Dec 03, 2014 at 08:59:01PM +0100, Stephan Mueller wrote:
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock-sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask-private;
+ int err = -EFAULT;
+
+ if (len == 0)
+ return 0;
+ if (len MAXSIZE)
+ len = MAXSIZE;
+
+ lock_sock(sk);
This lock simply protects ctx-result. Since you're using a
tiny buffer why not just put it on the stack?
When I developed the DRBG code, I got comments that 128 byte variables shall
not be on the stack in kernel code.
But if you agree that I can put a 128 byte variable on the stack, I will see
it done.
+ u8 *buf = kmalloc(seedsize, GFP_KERNEL);
+ if (!buf)
+ goto err;
+ get_random_bytes(buf, seedsize);
+ ret = crypto_rng_reset(private, buf, len);
I think you should leave the seeding and the seed to the user.
Perhaps do it through setsockopt (on the parent socket).
Sure. But please note that the seeding happens only when seedsize 0. Such
seeding therefore is not performed for krng, and the DRBG because both seed
automatically.
Therefore, may I propose the following: We offer a setsockopt for (re)seeding.
For all RNGs with seedsize 0, we return EAGAIN for recvmsg until a
setsockopt for at least seedsize is provided. That would imply that krng and
DRBG would be usable without seeding from user space.
--
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] crypto: qat - Fix for invalid dma mapping and numa
On Fri, Dec 05, 2014 at 10:34:33AM -0800, Tadeusz Struk wrote: Looks like these two are not in cryptodev-2.6 yet. Do you plan to merge it sometime soon or should I generate incremental patches based on crypto-2.6 instead of cryptodev-2.6 Just generate them on top of all your existing patches. If necessary I will merge the crypto tree into cryptodev. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
