On Sun, Apr 24, 2016 at 10:03:45AM +0200, Stephan Mueller wrote:
>
> I agree here. The only challenge with the current implementation is the time
> the fast_pool is to be mixed into an entropy pool. This requires a lock and
> quite some code afterwards.
This only happens no more than once every
I just discovered this huge conversation and am trying to read it all
and get caught up.
I know I should finish reading before I start writing, but too many ideas
are bubbling up.
> not the rest of Stephan's input handling code: the parity
> calculation and XORing the resulting single bit into t
On Tue, Apr 26, 2016 at 10:27:25AM +0900, Marcel Holtmann wrote:
>
> actually if we have support for ECDH P-256, then Bluetooth could be converted
> easily and we get an internal user of this API.
Great, then I would like to see the KPP patch come with an implementation
for that algorithm and a c
Hi Herbert,
>> Add key-agreement protocol primitives (kpp) API which allows to
>> implement primitives required by protocols such as DH and ECDH.
>> The API is composed mainly by the following functions
>> * set_params() - It allows the user to set the parameters known to
>> both parties involve
On Fri, Apr 15, 2016 at 10:25:15AM +0100, Salvatore Benedetto wrote:
> Add key-agreement protocol primitives (kpp) API which allows to
> implement primitives required by protocols such as DH and ECDH.
> The API is composed mainly by the following functions
> * set_params() - It allows the user to
On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
> That's far from a solution and I wouldn't recommend to anyone doing
> that. We cannot expect each and every program to do glibc's job. The
> purpose of a system call like getrandom is to simplify the complex use
> of /dev/ur
On Mon, Apr 25, 2016 at 09:06:03AM -0700, Andi Kleen wrote:
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
>
> https://lkml.org/lkml/2016/2/10/716
>
> Ignoring problems does not
> > > If it is the latter, can you explain where the scalability issue comes in?
> >
> > A single pool which is locked/written to does not scale. Larger systems
> > need multiple pools
>
> That would imply that even when you have a system with 1000 CPUs, you want to
> have a large amount of rand
Am Montag, 25. April 2016, 10:38:25 schrieb Andi Kleen:
Hi Andi,
> On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote:
> > Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
> >
> > Hi Andi,
> >
> > > Sandy Harris writes:
> > >
> > > There is also the third problem of horrib
On Mon, Apr 25, 2016 at 07:25:55PM +0200, Stephan Mueller wrote:
> Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
>
> Hi Andi,
>
> > Sandy Harris writes:
> >
> > There is also the third problem of horrible scalability of /dev/random
> > output on larger systems, for which patches are g
Am Montag, 25. April 2016, 09:06:03 schrieb Andi Kleen:
Hi Andi,
> Sandy Harris writes:
>
> There is also the third problem of horrible scalability of /dev/random
> output on larger systems, for which patches are getting ignored.
>
> https://lkml.org/lkml/2016/2/10/716
>
> Ignoring problems d
Sandy Harris writes:
There is also the third problem of horrible scalability of /dev/random
output on larger systems, for which patches are getting ignored.
https://lkml.org/lkml/2016/2/10/716
Ignoring problems does not make them go away.
-Andi
--
a...@linux.intel.com -- Speaking for myself o
The pf2vf_resp_wq is a global so it has to be created at init
and destroyed at exit, instead of per device.
Cc:
Tested-by: Suresh Marikkannu
Signed-off-by: Tadeusz Struk
---
drivers/crypto/qat/qat_common/adf_common_drv.h | 2 ++
drivers/crypto/qat/qat_common/adf_ctl_drv.c| 6 ++
dri
On 4/22/2016 6:45 PM, Kim Phillips wrote:
> On Thu, 21 Apr 2016 13:31:47 +
> Horia Ioan Geanta Neag wrote:
>
>> On 4/20/2016 3:04 PM, Christophe Leroy wrote:
>>> What's the best way to implement the selection of the proper descriptor
>>> type ?
>>> * We can duplicate the templates but it mean
On Fri, Apr 22, 2016 at 12:56:31PM +0300, Dan Carpenter wrote:
> ->src_nents and ->dst_nents are unsigned so they can't be less than
> zero. I fixed this by introducing a temporary "nents" variable.
>
> Fixes: d293b640ebd5 ('crypto: mxc-scc - add basic driver for the MXC SCC')
> Signed-off-by: Da
On Fri, Apr 22, 2016 at 02:15:22PM +0200, Krzysztof Kozlowski wrote:
> The BIT() macro is obvious and well known, so prefer to use it instead
> of crafted own macro.
>
> Signed-off-by: Krzysztof Kozlowski
Both applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Ke
On Thu, Apr 21, 2016 at 07:24:55PM +0300, Horia Geantă wrote:
> Provide hardware state import/export functionality, as mandated by
> commit 8996eafdcbad ("crypto: ahash - ensure statesize is non-zero")
>
> Cc: # 4.3+
> Reported-by: Jonas Eymann
> Signed-off-by: Horia Geantă
Applied to cryptode
On Wed, Apr 20, 2016 at 09:55:12AM -0500, Gary R Hook wrote:
> A DMA_ENGINE requires DMADEVICES in Kconfig
>
> Signed-off-by: Gary R Hook
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from
Hi Linus:
This push fixes a couple of regressions in the talitos driver
that were introduced back in 4.3. The first bug causes a crash
when the driver's AEAD functionality is used while the second
bug prevents its AEAD feature from working once you get past the
first bug.
Please pull from
git:
On Thu, Apr 21, 2016 at 09:14:51AM +0200, Steffen Klassert wrote:
> The network layer tries to allocate high order pages for skb_buff
> fragments, this leads to problems if we pass such a buffer to
> crypto because crypto assumes to have always order null pages
> in the scatterlists.
I don't under
Hello,
On 2016-04-22 14:15, Krzysztof Kozlowski wrote:
The tcrypt testing module on Exynos5422-based Odroid XU3/4 board failed on
testing 8 kB size blocks:
$ sudo modprobe tcrypt sec=1 mode=500
testing speed of async ecb(aes) (ecb-aes-s5p) encryption
test 0 (128 bit key,
On Mon, Apr 25, 2016 at 10:02 AM, Stephan Mueller wrote:
>> > One more item to consider: If you do not want to change to use
>> > getrandom(2), the LRNG provides you with another means.
>> The main problem is not about willing to switch to getrandom() or not,
>> but finding any system where getran
Am Montag, 25. April 2016, 09:55:14 schrieb Nikos Mavrogiannopoulos:
Hi Nikos,
> On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller
wrote:
> >> > ... DRBG is “minimally” seeded with 112^6 bits of entropy.
> >> > This is commonly achieved even before user space is initiated.
> >>
> >> Unfortunate
On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller wrote:
>> > ... DRBG is “minimally” seeded with 112^6 bits of entropy.
>> > This is commonly achieved even before user space is initiated.
>>
>> Unfortunately one of the issues of the /dev/urandom interface is the
>> fact that it may start providing
24 matches
Mail list logo
