In order to prepare for the addition of the asynchronous seeding call,
the invocation of seeding the DRBG is moved out into a helper function.
In addition, a block of memory is allocated during initialization time
that will be used as a scratchpad for obtaining entropy. That scratchpad
is used for
The kernel_pool is intended to be the in-kernel equivalent to the
blocking_pool, i.e. requests for random data may be blocked if
insufficient entropy is present.
The added API calls provide a synchronous function call
get_blocking_random_bytes where the caller is blocked.
In addition, an asynchro
Hi,
as of now, the DRBG is only seeded from get_random_bytes. In various
circumstances, the nonblocking_pool behind get_random_bytes may not be fully
seeded from hardware events at the time the DRBG requires to be seeded.
Based on the discussion in [1], the DRBG seeding is updated such that it
doe
Am Dienstag, 28. April 2015, 10:54:02 schrieb Herbert Xu:
Hi Herbert,
> On Tue, Apr 28, 2015 at 04:45:17AM +0200, Stephan Mueller wrote:
> > The use case I see goes along the lines of dm-crypt and Ext4 crypto, or
> > ecryptfs:
> >
> > For the key wrapping they all do, I am thinking about suggest
The kernel pool is intended to serve kernel-internal callers only.
Its purpose and usage is identical to the blocking_pool.
As the kernel_pool is not available to user space, user space cannot
directly interfere with the blocking behavior when obtaining
data from the kernel_pool. Thus, if entropy
The async seeding operation is triggered during initalization right
after the first non-blocking seeding is completed. As required by the
asynchronous operation of random.c, a callback function is provided that
is triggered by random.c once entropy is available. That callback
function performs the
During initialization, the DRBG now tries to allocate a handle of the
Jitter RNG. If such a Jitter RNG is available during seeding, the DRBG
pulls the required entropy/nonce string from get_random_bytes and
concatenates it with a string of equal size from the Jitter RNG. That
combined string is now
The CPU Jitter RNG provides a source of good entropy by
collecting CPU executing time jitter. The entropy in the CPU
execution time jitter is magnified by the CPU Jitter Random
Number Generator. The CPU Jitter Random Number Generator uses
the CPU execution timing jitter to generate a bit stream
whi
On Tue, Apr 28, 2015 at 04:45:17AM +0200, Stephan Mueller wrote:
>
> The use case I see goes along the lines of dm-crypt and Ext4 crypto, or
> ecryptfs:
>
> For the key wrapping they all do, I am thinking about suggesting KW as it has
> one advantage no other cipher currently has: it is an authe
On Tue, Apr 28, 2015 at 04:35:57AM +0200, Stephan Mueller wrote:
>
> In this case, shouldn't we just have a loop where:
>
> 1. from the given endpoint, we go a semiblock back
>
> 2. now we see how many bytes we get when fetching the SG list till the end,
>
> 3a. if answer from 2 is semiblock or
Am Dienstag, 28. April 2015, 09:09:41 schrieb Herbert Xu:
Hi Herbert,
> On Sun, Apr 26, 2015 at 12:07:31AM +0200, Stephan Mueller wrote:
> > Hi,
> >
> > Please note that this patch will conflict with the DRBG patch for
> > additional seeding sent earlier today. Both add test vectors in
> > testm
Am Dienstag, 28. April 2015, 09:10:47 schrieb Herbert Xu:
Hi Herbert,
> On Mon, Apr 27, 2015 at 04:34:19PM +0200, Stephan Mueller wrote:
> > Why do you think that will not work? I thought that the code works when
> > the
> > non-linear scatterlists are at least broken at an 8 byte boundary.
>
>
Bruce Allan wrote:
> Use ADF_DH895XCC_FW instead of duplicating the string "qat_895xcc.bin"
> when referring to the DH895xCC firmware.
>
> Signed-off-by: Bruce Allan
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubk
On Mon, Apr 27, 2015 at 04:58:51PM +0200, Stephan Mueller wrote:
>
> This memcmp implies that the final block->A from the decrypt is memcpy'ed to
> req->creq.info. I wanted to avoid any additional memcpy calls to not hurt
> performance even more.
I was hoping to directly use req->creq.info in th
On Mon, Apr 27, 2015 at 04:34:19PM +0200, Stephan Mueller wrote:
>
> Why do you think that will not work? I thought that the code works when the
> non-linear scatterlists are at least broken at an 8 byte boundary.
There is no guarantee that SG lists are set at 8-byte boundaries.
In fact, you need
On Sun, Apr 26, 2015 at 12:07:31AM +0200, Stephan Mueller wrote:
> Hi,
>
> Please note that this patch will conflict with the DRBG patch for
> additional seeding sent earlier today. Both add test vectors in
> testmgr.c between the existing hmac() and lrw() due to the ordering
> requirements of tes
> "Sagi" == Sagi Grimberg writes:
Sagi> The problem is that the HBA does not have the write_same
Sagi> functionality you introduce here, i.e. generate multiple same
Sagi> protection fields for a single data block.
Adding support to DIX would be problematic since it would essentially
turn a W
> "Akinobu" == Akinobu Mita writes:
Akinobu> This introduces crc_t10dif_update() which enables to calculate
Akinobu> CRC for a block which straddles multiple SG elements by calling
Akinobu> multiple times.
Looks good. We need this for the initiator side too.
Acked-by: Martin K. Petersen
-
Use ADF_DH895XCC_FW instead of duplicating the string "qat_895xcc.bin"
when referring to the DH895xCC firmware.
Signed-off-by: Bruce Allan
---
drivers/crypto/qat/qat_dh895xcc/adf_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/qat_dh895xcc/adf_drv.
On 04/27/2015 10:41 PM, Stephan Mueller wrote:
...
It seems you have the code already in mind, so please if you could write it
:-)
Ok, sure. I'll cook something by tomorrow morning.
Cheers,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a messa
Am Montag, 27. April 2015, 22:34:30 schrieb Daniel Borkmann:
Hi Daniel,
> On 04/27/2015 09:10 PM, Stephan Mueller wrote:
> ...
>
> > I posted the issue on the clang mailing list on April 10 -- no word so
> > far. I would interpret this as a sign that it is a no-issue for them.
>
> Hm. ;)
>
> H
On 04/27/2015 09:10 PM, Stephan Mueller wrote:
...
I posted the issue on the clang mailing list on April 10 -- no word so far. I
would interpret this as a sign that it is a no-issue for them.
Hm. ;)
Here's a bug report on the topic, gcc vs llvm:
https://llvm.org/bugs/show_bug.cgi?id=15495
Am Freitag, 10. April 2015, 16:50:22 schrieb Stephan Mueller:
Hi Stephan,
>Am Freitag, 10. April 2015, 16:46:04 schrieb Daniel Borkmann:
>
>Hi Daniel,
>
>>On 04/10/2015 04:36 PM, Stephan Mueller wrote:
>>> Am Freitag, 10. April 2015, 16:26:00 schrieb Hannes Frederic Sowa:
>>...
>>
I suspecte
Hi!
On Mon, Apr 27, 2015 at 07:16:22PM +0200, Martin Fuzzey wrote:
> Hi,
>
> I've been trying the Sahara crypto module on i.MX53 [mainline 3.19
> kernel + b251638c46a (crypto: sahara - use the backlog)]
>
> I tested using dm-crypt with AES-128:
> cryptsetup -v --key-size=128 luksFormat /dev/mmc
Hi,
I've been trying the Sahara crypto module on i.MX53 [mainline 3.19
kernel + b251638c46a (crypto: sahara - use the backlog)]
I tested using dm-crypt with AES-128:
cryptsetup -v --key-size=128 luksFormat /dev/mmcblk0p7
cryptsetup luksOpen /dev/mmcblk0p7 cryptotest
dd if=/dev/mapper/cryptot
Am Montag, 27. April 2015, 16:29:35 schrieb Herbert Xu:
Hi Herbert,
>On Sun, Apr 26, 2015 at 12:08:20AM +0200, Stephan Mueller wrote:
>> This patch implements the AES key wrapping as specified in
>> NIST SP800-38F and RFC3394.
>
>This is my attempt at turning kw into a givcipher. The encrypt
>pa
Am Montag, 27. April 2015, 16:26:07 schrieb Herbert Xu:
Hi Herbert,
>On Sun, Apr 26, 2015 at 12:08:20AM +0200, Stephan Mueller wrote:
>> +/*
>> + * Point to the end of the scatterlists to walk them
backwards.
>> + */
>> +src_walk.offset += src_nbyt
Am Montag, 27. April 2015, 14:56:09 schrieb Herbert Xu:
Hi Herbert,
>On Sat, Apr 25, 2015 at 05:40:41PM +0200, Stephan Mueller wrote:
>> +if (p->entropy_count <=
>> +p->poolinfo->poolfracbits / 4) {
>
>There appears to be a "3 *" mis
2015-04-26 19:07 GMT+09:00 Sagi Grimberg :
> On 4/25/2015 5:33 PM, Akinobu Mita wrote:
>>
>> sbc_dif_generate() and sbc_dif_verify() currently assume that each
>> SG element for data transfer memory doesn't straddle the block size
>> boundary.
>>
>> However, when using SG_IO ioctl, we can choose th
On Sun, Apr 26, 2015 at 12:08:20AM +0200, Stephan Mueller wrote:
> This patch implements the AES key wrapping as specified in
> NIST SP800-38F and RFC3394.
This is my attempt at turning kw into a givcipher. The encrypt
part is complete but untested as I gave up after finding the
reverse SG proble
On Sun, Apr 26, 2015 at 12:08:20AM +0200, Stephan Mueller wrote:
>
> + /*
> + * Point to the end of the scatterlists to walk them backwards.
> + */
> + src_walk.offset += src_nbytes;
> + dst_walk.offset += dst_nbytes;
This doesn't work.
Christophe Leroy wrote:
> Using sendfile with below small program to get MD5 sums of some files,
> it appear that big files (over 64kbytes with 4k pages system) get a
> wrong MD5 sum while small files get the correct sum.
> This program uses sendfile() to send a file to an AF_ALG socket
> for hash
32 matches
Mail list logo
