Hi,
The following patch set is aimed to increase the performance of the CTR
DRBG, especially when assembler implementations of the CTR AES mode are
available.
The patch set increases the performance by 10% for random numbers of 16 bytes
and reaches 450% for random numbers reaching 4096 bytes
Hardware cipher implementation may require aligned buffers. All buffers
that potentially are processed with a cipher are now aligned.
At the time of the allocation of the memory, we have not yet allocated
the cipher implementations. Hence, we cannot obtain the alignmask for
the used cipher yet.
The CTR DRBG update function performs a full CTR AES operation including
the XOR with "plaintext" data. Hence, remove the XOR from the code and
use the CTR mode to do the XOR.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 30 +-
1 file
The TFM object maintains the key for the CTR DRBG.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/crypto/drbg.c b/crypto/drbg.c
index 8ceb716..ded8638 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@
The CTR DRBG derives its random data from the CTR that is encrypted with
AES.
This patch now changes the CTR DRBG implementation such that the
CTR AES mode is employed. This allows the use of steamlined CTR AES
implementation such as ctr-aes-aesni.
Unfortunately there are the following subtile
Am Dienstag, 14. Juni 2016, 00:16:11 schrieb Andrew Zaborowski:
Hi Andrew,
> Hi,
>
> On 8 June 2016 at 21:14, Mat Martineau
>
> wrote:
> > On Wed, 8 Jun 2016, Stephan Mueller wrote:
> >> What is your concern?
> >
> > Userspace must allocate larger buffers
On 06/14/2016 12:09 AM, Kevin Hilman wrote:
> Hi Neil,
>
> Neil Armstrong writes:
>
>> Signed-off-by: Neil Armstrong
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git
On Mon, Jun 13, 2016 at 07:10:26PM +, Dey, Megha wrote:
>
> > In the current implementation, the inner algorithm is called directly, and
> > we use the outer algorithm's callback. We do not use the callback in inner
> > algorithm. We are actually calling the child functions directly and the
Hi Herbert,
Herbert Xu writes:
> On Fri, Jun 10, 2016 at 10:21:52AM +0200, Neil Armstrong wrote:
>> Add support for the Amlogic Meson SoCs Hardware Random generator as a
>> hw_random char driver.
>> The generator is a single 32bit wide register.
>> Also adds the
* Implement MPI based Diffie-Hellman under kpp API
* Test provided uses data generad by OpenSSL
Signed-off-by: Salvatore Benedetto
---
crypto/Kconfig | 8 ++
crypto/Makefile | 2 +
crypto/dh.c | 189
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_secret() - It allows the user to set his secret, also
referred to as his private key, along with the
Hi Herb,
the following patchset introduces a new API for abstracting key-agreement
protocols such as DH and ECDH. It provides the primitives required for
implementing
the protocol, thus the name KPP (Key-agreement Protocol Primitives).
Regards,
Salvatore
Changed from v7:
* API change: merge
-Original Message-
From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
Sent: Monday, June 13, 2016 1:22 AM
To: Dey, Megha
Cc: tim.c.c...@linux.intel.com; da...@davemloft.net;
linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.org; Yu, Fenghua
On Mon, Jun 13, 2016 at 08:00:33PM +0200, Stephan Mueller wrote:
>
> 1. The ChaCha20 is seeded with 256 bits (let us assume it is full entropy)
>
> 2. The ChaCha20 block operation shuffles the 256 bits of entropy over the 512
> bit state -- already here we see that after shuffling, the entropy
Am Montag, 13. Juni 2016, 11:48:37 schrieb Theodore Ts'o:
Hi Theodore,
> /*
> @@ -1254,15 +1423,26 @@ static ssize_t extract_entropy_user(struct
> entropy_store *r, void __user *buf, */
> void get_random_bytes(void *buf, int nbytes)
> {
> + __u8 tmp[CHACHA20_BLOCK_SIZE];
> +
> #if
On a system with a 4 socket (NUMA) system where a large number of
application threads were all trying to read from /dev/urandom, this
can result in the system spending 80% of its time contending on the
global urandom spinlock. The application should have used its own
PRNG, but let's try to help
From: Stephan Mueller
The Hyper-V Linux Integration Services use the VMBus implementation for
communication with the Hypervisor. VMBus registers its own interrupt
handler that completely bypasses the common Linux interrupt handling.
This implies that the interrupt entropy
If we have a hardware RNG and are using the in-kernel rngd, we should
use this to initialize the non-blocking pool so that getrandom(2)
doesn't block unnecessarily.
Cc: sta...@kernel.org
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 16 +++-
1 file changed,
Since systemd is consistently using /dev/urandom before it is
initialized, we can't see the other potentially dangerous users of
/dev/urandom immediately after boot. So print the first ten such
complaints instead.
Cc: sta...@kernel.org
Signed-off-by: Theodore Ts'o
---
From: Eric Biggers
get_random_long() reads from the get_random_int_hash array using an
unsigned long pointer. For this code to be guaranteed correct on all
architectures, the array must be aligned to an unsigned long boundary.
Cc: sta...@kernel.org
Signed-off-by: Eric
The CRNG is faster, and we don't pretend to track entropy usage in the
CRNG any more.
Signed-off-by: Theodore Ts'o
---
crypto/chacha20_generic.c | 61
drivers/char/random.c | 374 +-
include/crypto/chacha20.h | 1 +
Signed-off-by: Theodore Ts'o
---
drivers/char/random.c | 54 ++-
1 file changed, 49 insertions(+), 5 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d640865..963a6a9 100644
--- a/drivers/char/random.c
On Fri, Jun 10, 2016 at 10:21:52AM +0200, Neil Armstrong wrote:
> Add support for the Amlogic Meson SoCs Hardware Random generator as a
> hw_random char driver.
> The generator is a single 32bit wide register.
> Also adds the Meson GXBB SoC DTSI node and corresponding DT bindings.
>
> Changes
On Fri, Jun 10, 2016 at 04:47:02PM +1000, Anton Blanchard wrote:
> From: Anton Blanchard
>
> When calling ppc-xlate.pl, we pass it either linux-ppc64 or
> linux-ppc64le. The script however was expecting linux64le, a result
> of its OpenSSL origins. This means we aren't obeying
On Wed, Jun 08, 2016 at 02:56:39PM +0200, Linus Walleij wrote:
> The hash buffer is really HASH_BLOCK_SIZE bytes, someone
> must have thought that memmove takes n*u32 words by mistake.
> Tests work as good/bad as before after this patch.
>
> Cc: Joakim Bech
> Reported-by:
On Wed, Jun 08, 2016 at 02:47:47AM +0530, Bhaktipriya Shridhar wrote:
> alloc_workqueue replaces deprecated create_workqueue().
>
> The workqueue device_reset_wq has workitem _data->reset_work per
> adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for
> PF2VF responses has workitem
Am Montag, 13. Juni 2016, 17:37:14 schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jun 10, 2016 at 07:56:57AM +0200, Stephan Mueller wrote:
> > Hardware cipher implementation may require aligned buffers. All buffers
> > that potentially are processed with a cipher are now aligned.
> >
> > At the time
On Fri, Jun 10, 2016 at 07:56:57AM +0200, Stephan Mueller wrote:
> Hardware cipher implementation may require aligned buffers. All buffers
> that potentially are processed with a cipher are now aligned.
>
> At the time of the allocation of the memory, we have not yet allocated
> the cipher
On Wed, Jun 08, 2016 at 12:45:47PM +0100, Salvatore Benedetto wrote:
>
> Having said that, are you OK with as far as the interface goes
> to only merge set_param and set_key, and keeping the rest as it is?
> For the implementation of DH and ECDH I'll merge the two operations
> functions into one
On Wed, Jun 08, 2016 at 09:16:52AM +0100, Giovanni Cabiddu wrote:
>
> +static void *scomp_map(struct scatterlist *sg, unsigned int len,
> +gfp_t gfp_flags)
> +{
> + void *buf;
> +
> + if (sg_is_last(sg))
> + return kmap_atomic(sg_page(sg)) + sg->offset;
30 matches
Mail list logo