> + if (!ret && !mpi_cmp(pone, val))
> + ret = -EBADMSG;
> +
> + mpi_free(pone);
> +
> + if (ret)
> + goto err_free_base;
> + }
> +
> ret = mpi_write_to_sgl(val, req->dst, req->dst_len, &sign);
> if (ret)
> goto err_free_base;
> --
> 2.26.2
>
>
>
>
Acked-by: Neil Horman
idity:
> + memzero_explicit(priv, sizeof(priv));
> + memzero_explicit(rand_z, sizeof(rand_z));
> ecc_free_point(product);
> err_alloc_product:
> ecc_free_point(pk);
> --
> 2.26.2
>
>
>
>
Acked-by: Neil Horman
On Fri, Nov 23, 2018 at 12:02:10PM +, Corentin Labbe wrote:
> Hello
>
> This patchset fixes all reported problem by Eric biggers.
>
> Regards
>
> Changes since v3:
> - Added a crypto_stats_init as asked vy Neil Horman
> - Fixed some checkpatch complaints
>
>
On Tue, Nov 20, 2018 at 12:32:17PM +, Corentin Labbe wrote:
> Even if CRYPTO_STATS is set to n, some part of CRYPTO_STATS are
> compiled.
> This patch made all part of crypto_user_stat uncompiled in that case.
>
> Signed-off-by: Corentin Labbe
> ---
> crypto/Makefile |
a QAT firmware update will
be forthcomming to fix the issue
Neil
> thanks
> --Raj
>
> On Tue, Jun 13, 2017 at 5:30 AM, Neil Horman wrote:
> > On Mon, Jun 12, 2017 at 03:52:07PM +, Benedetto, Salvatore wrote:
> >> Hi Raj,
> >>
> >> I've compi
On Mon, Jun 12, 2017 at 03:52:07PM +, Benedetto, Salvatore wrote:
> Hi Raj,
>
> I've compiled and tested kernel 4.12.0-rc4 and I can't reproduce your issue.
> Are you seeing any of this with a previous kernel version? If not, git bisect
> might
> help us finding the root-cause.
> Have you tri
arches don't, and if
qat makes its way to one of those, that can cause all sorts of corruption.
Fix is pretty easy, just init sz_out to zero, and gate the unmapping on sz_out
being non-zero
Signed-off-by: Neil Horman
CC: Herbert Xu
CC: "David S. Miller"
CC: Tadeusz Struk
CC: qat-
ome 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.ke
the X9.31 bits:
Acked-by: Neil Horman
--
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
On Wed, Jan 14, 2015 at 04:31:44PM +0100, Stephan Mueller wrote:
> Am Mittwoch, 14. Januar 2015, 22:00:11 schrieb Herbert Xu:
>
> Hi Herbert,
>
> > On Wed, Jan 14, 2015 at 04:46:31AM -0500, Neil Horman wrote:
> > > On Wed, Jan 14, 2015 at 04:52:29AM +0100, Stepha
On Wed, Jan 14, 2015 at 04:52:29AM +0100, Stephan Mueller wrote:
> Hi,
>
> This patch set adds AEAD and RNG support to the AF_ALG interface
> exported by the kernel crypto API. By extending AF_ALG with AEAD and RNG
> support, all cipher types the kernel crypto API allows access to are
> now access
On Wed, Jan 14, 2015 at 09:14:41AM +0800, weiyj...@163.com wrote:
> From: Wei Yongjun
>
> Fixes the following sparse warnings:
>
> crypto/algif_rng.c:185:13: warning:
> symbol 'rng_exit' was not declared. Should it be static?
>
> Signed-off-by:
On Mon, Dec 15, 2014 at 05:01:02PM -0500, George Spelvin wrote:
> > With that then, I'm really fine with the changes given that they pass the
> > NIST
> > tests.
>
> So here's the current list of issues. First, minor ones:
> 1) Add const to DRBG interface, as per Stephan's request.
> 2) Revised
; > The implementation doesn't support them, and I didn't add them.
>
> Sorry, my bad. :-)
>
> Then, I think the updated implementation matches with the spec.
With that then, I'm really fine with the changes given that they pass the NIST
tests.
Acked-by: Neil Horm
On Mon, Dec 08, 2014 at 11:43:13AM -0500, George Spelvin wrote:
> > Wait, I'm confused. You mention in this note that this is an RFC patch, but
> > not
> > anywhere else in the series. Are you proposing this for inclusion or not?
>
> Er, in the 0/25, I mentioned that I put the least certain stuf
On Sun, Dec 07, 2014 at 05:49:59PM -0500, George Spelvin wrote:
> By the way, this patch includes a bug due to a last minute "oh, I can
> make that more efficient!" which I realized after a night's sleep.
> (The v1 patch worked, FWIW.)
>
> Anyway, it's an RFC; I'm not even sure if I want this pers
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 re
On Tue, Dec 02, 2014 at 03:33:14AM -0500, George Spelvin wrote:
> Thank you all for your hospitality to my amateurish efforts.
>
> Given that this all started with me reading the code in an attempt to
> understand it, it is likely that some of the "problems" I address are
> actually misunderstandi
On Tue, Dec 02, 2014 at 03:28:17PM -0500, George Spelvin wrote:
> >> --- a/crypto/ansi_cprng.c
> >> +++ b/crypto/ansi_cprng.c
> >> @@ -51,9 +51,9 @@ struct prng_context {
> >>unsigned char rand_data[DEFAULT_BLK_SZ];
> >>unsigned char DT[DEFAULT_BLK_SZ];
> >>unsigned char V[DEFAULT_BLK_S
On Tue, Dec 02, 2014 at 03:03:38PM -0500, George Spelvin wrote:
> > I'm only ok with removing I if you can continue to be able to output it.
> > given that I is listed as part of the test sequences that NIST provides,
> > I'd like to be able to compare the values.
>
> I can do that easily, but I c
On Tue, Dec 02, 2014 at 03:43:13AM -0500, George Spelvin wrote:
> rand_read_pos is never more than 16, while there's only 1 flag
> bit allocated, so we can shrink the context a little.
>
> Signed-off-by: George Spelvin
> ---
> crypto/ansi_cprng.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
On Tue, Dec 02, 2014 at 03:37:07AM -0500, George Spelvin wrote:
> It's also not necessary. We do have to change some debugging
> output.
>
> Signed-off-by: George Spelvin
> ---
> crypto/ansi_cprng.c | 39 ---
> 1 file changed, 20 insertions(+), 19 deletions(-
On Tue, Dec 02, 2014 at 03:35:50AM -0500, George Spelvin wrote:
> It's simply not necessary.
>
> Signed-off-by: George Spelvin
NACK
The assumption that its not needed is incorrect. In fips mode its explicitly
needed to validate that the rng isn't reproducing identical random data.
Neil
--
To
On Tue, Dec 02, 2014 at 12:39:30AM -0500, George Spelvin wrote:
> > See Documentation/DocBook/crypto-API.tmpl in the cryptodev-2.6 tree.
> > There you will find tons of documentation (which will be merged during
> > 3.19-rc1)
>
> Yes, I've been reading that. It certainly helps a great deal, but
On Mon, Dec 01, 2014 at 11:55:18PM -0500, George Spelvin wrote:
> >> The other one, which I have to think *very* hard about, is whether
> >> using the same seed material as /dev/random in this much weaker
> >> cryptographic construction will introduce a flaw in *it*.
>
> > I have no idea what you
On Sat, Nov 29, 2014 at 02:32:05PM -0500, George Spelvin wrote:
> >> Other than enough implementation stupidities to make me scream
> >> (particularly the "rand_data_valid" variable name which is actually a
>
> > Its actually a counter of the number of valid random data bytes in the
> > buffer
>
On Sat, Nov 29, 2014 at 12:26:49PM -0500, George Spelvin wrote:
> Sorry for the duplicate; I had a crash and I thought the mail was lost.
> First message was not quite finished, second is a rewrite from scratch.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the
On Fri, Nov 28, 2014 at 06:23:51PM -0500, George Spelvin wrote:
> I've been trying to understand the crypto layer, and it's a bit of a
> struggle because I'm trying to learn how it's supposed to work by
> reading the code, and I keep finding code I want to fix.
>
Patches welcome.
> ansi_cprng.c i
> v2: remove extraneous blank line, perform checks in static inline
> function, drop no longer necessary fips.h include.
>
> CC: Herbert Xu
> CC: "David S. Miller"
> CC: Rusty Russell
> CC: Stephan Mueller
> CC: linux-crypto@vger.kernel.org
> Signed-off-by:
On Mon, Mar 24, 2014 at 01:01:04AM +0530, Monam Agarwal wrote:
> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
>
> The rcu_assign_pointer() ensures that the initialization of a structure
> is carried out before storing a pointer to that structure.
> And in
On Sun, Feb 16, 2014 at 07:41:23AM +0800, Herbert Xu wrote:
> On Fri, Feb 14, 2014 at 06:01:06PM -0800, Tim Chen wrote:
> >
> > Module A selects CRYPTO_ALG_B in config, which causes the generic
> > ALG_B to get built and a module dependency to the generic
> > ALG_B to be established. Then when mo
On Fri, Feb 14, 2014 at 11:14:37AM -0800, Tim Chen wrote:
> We added the soft module dependency of various crypto algorithm's module alias
> to generic crypto algorithm's module. This loads hardware accelerated
> modules and uses them when available.
>
This is great, but have any of the module l
n the
rand_data buffer gets reused on the subsequent smaller-than-a-block request for
random data.
The fix is pretty easy, just re-code the for loop to make sure that
rand_data_valid gets incremented appropriately
Signed-off-by: Neil Horman
Reported-by: Stephan Mueller
CC: Stephan Mueller
CC:
On Fri, Sep 06, 2013 at 04:20:50PM -0700, Kees Cook wrote:
> Hi,
>
> I've tracked down a race condition and ref counting problem in the
> crypto API internals. We've been seeing it under Chrome OS, but it
> seems it's not isolated to just us:
>
> https://code.google.com/p/chromium/issues/detail?i
eas only touched when when booted in fips mode.
>
> This change should also go into 3.8-stable, to make the myriads of fips
> users on 3.8.x happy.
>
> Tested-by: Jan Stancek
> Tested-by: Jan Stodola
> CC: Herbert Xu
> CC: Neil Horman
> CC: "David S. Miller&
he extra primer bits.
>
> v3: extract_buf() can't be called with spinlock already held, so bring
> back some extra lock/unlock calls.
>
> CC: Herbert Xu
> CC: "David S. Miller"
> CC: Neil Horman
> CC: Matt Mackall
> CC: linux-crypto@vger.kernel.o
t; then pass along the value after that to the requester, so that consistency
> checks aren't being run against stale and possibly known data.
>
> CC: Herbert Xu
> CC: "David S. Miller"
> CC: Neil Horman
> CC: Matt Mackall
> CC: linux-crypto@vger.kernel.org
we
> compare key and seed to avoid looking at potentially unallocated mem.
>
> CC: Neil Horman
> CC: Stephan Mueller
> CC: Steve Grubb
> Signed-off-by: Jarod Wilson
Thanks Jarod. Adding Herbert to the cc list so he can pull this into the crypto
tree.
Acked-by: Neil Horman
they're now interpreting FIPS 140-2, section AS07.09 as requiring that
> the implementation itself must enforce the requirement. Easy fix, we
> just do a memcmp of key and seed in fips_cprng_reset and call it a day.
>
> CC: Neil Horman
> CC: Stephan Mueller
> CC: Steve G
On Mon, Sep 12, 2011 at 10:02:43AM -0400, Jarod Wilson wrote:
> Ted Ts'o wrote:
> >On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote:
> >>We're looking for a generic solution here that doesn't require
> >>re-educating every single piece of userspace. And anything done in
> >>userspace is
On Fri, Sep 09, 2011 at 03:08:03PM -0400, Eric Paris wrote:
> On Thu, Sep 8, 2011 at 12:13 PM, David Miller wrote:
> > From: Steve Grubb
>
> >> This patch does not _break_ all existing applications. If a system were
> >> under attack,
> >> they might pause momentarily, but they do not break. Pl
On Thu, Sep 08, 2011 at 09:11:12AM -0400, Steve Grubb wrote:
> On Thursday, September 08, 2011 08:52:34 AM Neil Horman wrote:
> > > to disk device - of course only if the device adds entropy into the
> > > primary pool when there are writes on the device.
> >
> >
On Thu, Sep 08, 2011 at 08:41:57AM +0200, Tomas Mraz wrote:
> On Wed, 2011-09-07 at 19:57 -0400, Neil Horman wrote:
> > On Wed, Sep 07, 2011 at 04:56:49PM -0400, Steve Grubb wrote:
> > > On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote:
> > > > Anyway,
On Wed, Sep 07, 2011 at 04:56:49PM -0400, Steve Grubb wrote:
> On Wednesday, September 07, 2011 04:37:57 PM Sasha Levin wrote:
> > On Wed, 2011-09-07 at 16:30 -0400, Steve Grubb wrote:
> > > On Wednesday, September 07, 2011 04:23:13 PM Sasha Levin wrote:
> > > > On Wed, 2011-09-07 at 16:02 -0400, S
On Wed, Sep 07, 2011 at 04:02:24PM -0400, Steve Grubb wrote:
> On Wednesday, September 07, 2011 03:27:37 PM Ted Ts'o wrote:
> > On Wed, Sep 07, 2011 at 02:26:35PM -0400, Jarod Wilson wrote:
> > > We're looking for a generic solution here that doesn't require
> > > re-educating every single piece of
On Wed, Sep 07, 2011 at 10:05:30PM +0300, Sasha Levin wrote:
> On Wed, 2011-09-07 at 14:26 -0400, Jarod Wilson wrote:
> > Sasha Levin wrote:
> > > On Wed, 2011-09-07 at 13:38 -0400, Jarod Wilson wrote:
> > >> Certain security-related certifications and their respective review
> > >> bodies have sai
On Sat, Jun 18, 2011 at 03:40:50PM -0700, H. Peter Anvin wrote:
> On 06/17/2011 01:28 PM, Matt Mackall wrote:
> >>
> >> The one use case that it is cryptographically insufficient for is to
> >> seed a new PRNG, which probably means it is unsuitable for being fed
> >> as-is into /dev/random.
> >
>
On Fri, Jun 17, 2011 at 02:51:31PM -0400, Jarod Wilson wrote:
> Matt Mackall wrote:
> >On Wed, 2011-06-15 at 10:49 -0400, Jarod Wilson wrote:
> >>Matt Mackall wrote:
> >>>On Tue, 2011-06-14 at 18:51 -0400, Jarod Wilson wrote:
> Matt Mackall wrote:
> >>...
> >But that's not even the point. E
On Fri, Jan 21, 2011 at 11:35:17PM +1100, Herbert Xu wrote:
> On Fri, Jan 21, 2011 at 07:09:50AM -0500, Neil Horman wrote:
> >
> > I take your point, but I'm not certain I agree that we are duplicating an
> > existing user interface. A cursory glance would say that we ar
On Fri, Jan 21, 2011 at 05:00:05PM +1100, Herbert Xu wrote:
> On Thu, Jan 20, 2011 at 06:34:40PM -0500, Neil Horman wrote:
> >
> > Herbert, Sorry to bug you about this, but are you still planning on pulling
> > this
> > now that Linus has the infrastructure scheduled fo
On Mon, Dec 13, 2010 at 04:25:14PM -0500, Neil Horman wrote:
> Change notes:
> Changed rng_rcvmsg to allocate a fixed size maximum temp block to store rng
> data
> when recvmsg is called. This should prevent malicious DoS from user space by
> tring to receive obscene amounts of
On Sat, Jan 08, 2011 at 03:23:04PM +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, Jan 7, 2011 at 2:04 PM, Neil Horman wrote:
>
> >> Btw, it doesn't have to be about performance per se. Does this allow
> >> people to use keys without actually _seeing_ those keys? Y
On Thu, Jan 06, 2011 at 02:13:17PM -0800, Linus Torvalds wrote:
> On Thu, Jan 6, 2011 at 1:39 PM, Herbert Xu
> wrote:
> > On Thu, Jan 06, 2011 at 01:23:19PM -0800, Linus Torvalds wrote:
> >>
> >> Explanations of interface. Code. Who uses it? What are the actual
> >> performance benefits on real c
ta is possible.
Tested successfully using NIST provided RNG vectors by myself:
Signed-off-by: Neil Horman
CC: Herbert Xu
CC: "David S. Miller"
---
crypto/Kconfig |9 ++
crypto/Makefile|1 +
crypto/algif_rng.c | 212
3 fil
On Mon, Dec 13, 2010 at 12:24:34PM -0500, Miloslav Trmac wrote:
> - "Neil Horman" wrote:
> > +static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
> > + struct msghdr *msg, size_t len, int flags)
> > +{
> > + struct sock *s
sible.
Tested successfully using NIST provided RNG vectors by myself:
Signed-off-by: Neil Horman
CC: Herbert Xu
CC: "David S. Miller"
---
crypto/Kconfig |9 +++
crypto/Makefile|1 +
crypto/algif_rng.c | 197
3 fil
On Mon, Nov 15, 2010 at 09:43:12AM +0100, Tomas Mraz wrote:
> On Fri, 2010-11-12 at 08:32 -0500, Dan Rosenberg wrote:
> > Hi Crypto people,
> >
> > I'm planning on submitting a patch that introduces a new %p format
> > specifier that obfuscates kernel pointers depending on privileges. This
> > c
On Fri, Nov 12, 2010 at 12:39:41PM -0500, Dan Rosenberg wrote:
> Thanks for your response.
>
> > >
> > Just use get_random_bytes, or initalize an instance of cprng with
> > get_random_bytes.
> >
>
> Will do.
>
> >
> > Depends on your goal, if you just wnat to hide the pointers, why not just
On Fri, Nov 12, 2010 at 08:32:01AM -0500, Dan Rosenberg wrote:
> Hi Crypto people,
>
> I'm planning on submitting a patch that introduces a new %p format
> specifier that obfuscates kernel pointers depending on privileges. This
> change is for security reasons - many networking protocols expose
>
On Tue, Aug 10, 2010 at 10:06:05PM -0400, Miloslav Trmac wrote:
> - "Neil Horman" wrote:
> > Ok, well, I suppose we're just not going to agree on this. I don't know how
> > else to argue my case, you seem to be bent on re-inventing the wheel
> > inst
On Tue, Aug 10, 2010 at 02:58:01PM -0400, Miloslav Trmac wrote:
> - "Neil Horman" wrote:
> > On Tue, Aug 10, 2010 at 11:36:16AM -0400, Miloslav Trmac wrote:
> > > I think it would be useful to separate thinking about the data
> > format and about the transmis
On Tue, Aug 10, 2010 at 03:10:12PM -0400, Steve Grubb wrote:
> On Tuesday, August 10, 2010 02:45:44 pm Neil Horman wrote:
> > On Tue, Aug 10, 2010 at 02:14:24PM -0400, Steve Grubb wrote:
> > > On Tuesday, August 10, 2010 01:57:40 pm Neil Horman wrote:
> > > > > >
On Tue, Aug 10, 2010 at 02:19:59PM -0400, Miloslav Trmac wrote:
> - "Neil Horman" wrote:
> > On Tue, Aug 10, 2010 at 12:57:43PM -0400, Miloslav Trmac wrote:
> > >
> > > - "Neil Horman" wrote:
> > >
> > >
On Tue, Aug 10, 2010 at 02:14:24PM -0400, Steve Grubb wrote:
> On Tuesday, August 10, 2010 01:57:40 pm Neil Horman wrote:
> > > > I'm not so sure I follow. how can you receive messages on a socket in
> > > > response to requests that were sent from a different
On Tue, Aug 10, 2010 at 12:57:43PM -0400, Miloslav Trmac wrote:
>
> - "Neil Horman" wrote:
>
> > On Tue, Aug 10, 2010 at 11:40:00AM -0400, Miloslav Trmac wrote:
> > > - "Neil Horman" wrote:
> > > > On Tue, Aug 10, 2010 at 10:47
On Tue, Aug 10, 2010 at 11:40:00AM -0400, Miloslav Trmac wrote:
> - "Neil Horman" wrote:
> > On Tue, Aug 10, 2010 at 10:47:14AM -0400, Miloslav Trmac wrote:
> > > - "Neil Horman" wrote:
> > > > On Tue, Aug 10, 2010 at 09:24:31AM -0400,
On Tue, Aug 10, 2010 at 11:36:16AM -0400, Miloslav Trmac wrote:
>
> - "Neil Horman" wrote:
> > On Mon, Aug 09, 2010 at 08:00:55PM -0400, Miloslav Trmac wrote:
> > > Is the proposed interface acceptable in the general approach (enums
> > for algorit
On Tue, Aug 10, 2010 at 10:47:14AM -0400, Miloslav Trmac wrote:
>
> - "Neil Horman" wrote:
> > On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> > > > Thats why I had suggested the use of a netlink protocol to manage this
> > > &g
On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> On Tuesday, August 10, 2010 08:46:28 am Neil Horman wrote:
> > Specifically, my concerns are twofold:
> >
> > 1) struct format. By passing down a structure as your doing through an
> > ioctl call, theres n
On Mon, Aug 09, 2010 at 08:00:55PM -0400, Miloslav Trmac wrote:
> - "Herbert Xu" wrote:
>
> > On Thu, Aug 05, 2010 at 10:17:53PM +0200, Miloslav Trmač wrote:
> > > Hello,
> > > following is a patchset providing an user-space interface to the kernel
> > > crypto
> > > API. It is based on the
On Thu, Aug 05, 2010 at 10:17:53PM +0200, Miloslav Trmač wrote:
> Hello,
> following is a patchset providing an user-space interface to the kernel crypto
> API. It is based on the older, BSD-compatible, implementation, but the
> user-space interface is different.
>
I only see patch 1/4 and 3/4.
On Sat, Mar 20, 2010 at 08:29:59PM +0800, Herbert Xu wrote:
> On Fri, Mar 19, 2010 at 10:23:25PM -0700, David Miller wrote:
> >
> > I hear what you're saying Herbert, but thinking about this a bit I
> > really think we should make this situation work instead of fail.
>
> I think the initial report
gt; used
> crypto/ansi_cprng.c:393: warning: ‘fips_cprng_reset’ defined but not used
>
> Signed-off-by: Jaswinder Singh Rajput
Yeah, looks good to me, thanks!
Acked-by: Neil Horman
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a m
On Mon, Oct 12, 2009 at 04:22:05PM +0200, Roel Kluin wrote:
> Op 12-10-09 16:07, Herbert Xu schreef:
> > On Mon, Oct 12, 2009 at 09:51:42AM -0400, Neil Horman wrote:
> > .
> >>> Or should this test be removed?
> >>>
> >>> diff --git a/crypto/ans
On Mon, Oct 12, 2009 at 11:07:53PM +0900, Herbert Xu wrote:
> On Mon, Oct 12, 2009 at 09:51:42AM -0400, Neil Horman wrote:
> .
> > > Or should this test be removed?
> > >
> > > diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
> > > index
>
> spin_lock_bh(&ctx->prng_lock);
No, you're quite right, its a harmless, but unneeded check. Herbert, could you
pull this into cryptodev please? Thank you.
Thanks for the patch Roel.
Acked-by: Neil Horman
Neil
> --
> To unsubscribe from this list: send the lin
Patch to add fips(ansi_cprng) alg, which is ansi_cprng plus a continuous test
Signed-off-by: Neil Horman
ansi_cprng.c | 79 ---
1 file changed, 70 insertions(+), 9 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
a wrapper algorithm. We
implement fips(ansi_cprng), which is exactly like the ansi_cprng, except that it
implements the continuous test on top of it.
Signed-off-by: Neil Horman
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@
On Thu, Sep 17, 2009 at 08:39:51AM -0700, Herbert Xu wrote:
> On Thu, Sep 17, 2009 at 08:43:51AM -0400, Neil Horman wrote:
> >
> > As Jarod mentioned, currently only the NIST certification vectors and, as a
> > result our testmgr vectors require disabling of the internal
On Wed, Sep 16, 2009 at 10:37:29PM -0500, Herbert Xu wrote:
> On Wed, Sep 16, 2009 at 12:04:56PM -0400, Neil Horman wrote:
> >
> > So the question is, how do I make this RNG fips compliant without
> > breaking some subset of users out there that rely on the predictability
patch 3/3: modify cprng to make contnuity check fips compliant and allow for a
disabling of the continuity test when the RNG is placed in FIPS mode
Signed-off-by: Neil Horman
ansi_cprng.c | 56 +++-
1 file changed, 51 insertions(+), 5
f the test they
are preforming.
Signed-off-by: Neil Horman
testmgr.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 6d5b746..89ea8c1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1470,6 +1470,8 @@ static int alg_test_cprng(const s
that it needs to respond to, it can opt to not register any
calls, and as a result a default handler will be registered for each which
universally returns EOPNOTSUPPORT.
Signed-off-by: Neil Horman
crypto/rng.c | 13 +
include/crypto/rng.h |
ed vectors).
Signed-off-by: Neil Horman
--
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
.
This patch augments the continuous test in the hardware RNG to enforce this
requirement, making the hardware RNG fips compliant (when operating in fips
mode).
Neil
Signed-off-by: Neil Horman
random.c | 28
1 file changed, 20 insertions(+), 8 deletions(-)
diff
On Sun, Sep 13, 2009 at 02:17:34PM +0200, Sebastian Andrzej Siewior wrote:
> * Neil Horman | 2009-09-12 12:44:11 [-0400]:
>
> >diff --git a/drivers/char/random.c b/drivers/char/random.c
> >index d8a9255..6700248 100644
> >--- a/drivers/char/random.c
> >+++ b/driv
use in the repetition
check, but not return it to the caller (opting instead to return the next n bit
block which passes the repetiiton check instead. This patch corrects that.
Neil
Signed-off-by: Neil Horman
random.c | 27 ---
1 file changed, 20 insertions(+), 7
return crypto_register_alg(&rng_alg);
> }
>
> static void __exit prng_mod_fini(void)
> --
> 1.5.4.2
>
>
Thanks!
Acked-by: Neil Horman
--
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
On Fri, Aug 14, 2009 at 09:13:55PM +1000, Herbert Xu wrote:
> On Fri, Aug 14, 2009 at 06:58:29AM -0400, Neil Horman wrote:
> >
> > Yeah, I suppose, it just seemed like a hack to me, since it really is a
> > logical
> > boolean, and we use it as such. Ok, I'll l
On Fri, Aug 14, 2009 at 01:13:40PM +1000, Herbert Xu wrote:
> On Thu, Aug 13, 2009 at 10:41:56AM -0400, Neil Horman wrote:
> >
> > Is there a good way to select a tristate from a bool? The logic is the
> > right
> > thing to do above, it just seems the mechanism
On Thu, Aug 13, 2009 at 09:29:55PM +1000, Herbert Xu wrote:
> On Fri, Jun 19, 2009 at 08:55:00AM -0400, Neil Horman wrote:
> >
> > Thanks! Thats definately an oversight. Likely I included it because I was
> > implementing it as part of the FIPS effort. The CPRNG defin
t;);
>
> --
> BOFH excuse #229:
>
> wrong polarity of neutron flow
>
Thanks!
Acked-by: Neil Horman
--
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
> > > .fips_allowed = 1,
> > > .suite = {
> >
> > Don't you use this vector for _all_ stdrngs now? krng for instance will
> > fail.
>
> Good cath!
>
Indeed, I didn't even think of that.
> What this really should
rng. This patch brings the two into line.
Signed-off-by: Neil Horman
testmgr.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index f9bea9d..3315a38 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1480,7 +1480,7 @@
On Wed, Jul 01, 2009 at 09:25:17AM +0200, Sebastian Andrzej Siewior wrote:
> * Neil Horman | 2009-06-30 20:06:48 [-0400]:
>
> >I think this looks better, yeah, have you tested this? If not, give it a
> >quick
> >run please, and I'll ack it.
> I've built it
On Tue, Jun 30, 2009 at 09:55:18PM +0200, Sebastian Andrzej Siewior wrote:
> As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
> to:
> |BUG: sleeping function called from invalid context at kernel/rwsem.c:21
> |in_atomic(): 1, irqs_disabled(): 0, pid: 4926, name: modprob
On Mon, Jun 29, 2009 at 11:45:08PM +0200, Sebastian Andrzej Siewior wrote:
> From: Sebastian Andrzej Siewior
>
> As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
> to:
> |BUG: sleeping function called from invalid context at kernel/rwsem.c:21
> |in_atomic(): 1, irqs_d
ink we may want to make this api accessible within interrupt context, but that
can probably wait until we have a user in said context, to find the best way to
do that. Herbert, can you apply this to your tree? Thanks!
Acked-by: Neil Horman
> ---
> crypto/ansi_cprng.c |9 -
>
On Mon, Jun 29, 2009 at 11:48:21PM +0200, Sebastian Andrzej Siewior wrote:
> * Sebastian Andrzej Siewior | 2009-06-29 23:45:08 [+0200]:
>
> >From: Sebastian Andrzej Siewior
> >
> >As reported by Eric Sesterhenn the re-allocation of the cipher in reset leads
>
> Neil, the patches are untested. Co
On Mon, Jun 29, 2009 at 04:07:04PM +0200, Sebastian Andrzej Siewior wrote:
> * Eric Sesterhenn | 2009-06-29 15:17:05 [+0200]:
>
> >[ 122.967099] BUG: sleeping function called from invalid context at
> >kernel/rwsem.c:21
> >[ 122.967398] in_atomic(): 1, irqs_disabled(): 0, pid: 4926, name:
> >mod
1 - 100 of 167 matches
Mail list logo
