On Thu, Dec 22, 2016 at 04:25:12PM +0530, Binoy Jayan wrote:
>
> > It doesn't have to live outside of dm-crypt. You can register
> > these IV generators from there if you really want.
>
> Sorry, but I didn't understand this part.
What I mean is that moving the IV generators into the crypto API
d
On 21-12-2016 14:24, Herbert Xu wrote:
> On Mon, Dec 19, 2016 at 04:08:11PM +0530, Harsh Jain wrote:
>> Hi Herbert,
>>
>> TLS default mode of operation is MAC-then-Encrypt for Authenc algos.
>> Currently framework only supports EtM used in IPSec. User space
>> programs like openssl cannot use af-
Hannes Frederic Sowa wrote:
> A lockdep test should still be done. ;)
Adding might_lock() annotations will improve coverage a lot.
> Yes, that does look nice indeed. Accounting for bits instead of bytes
> shouldn't be a huge problem either. Maybe it gets a bit more verbose in
> case you can't sat
On 22.12.2016 22:11, George Spelvin wrote:
>> I do tend to like Ted's version in which we use batched
>> get_random_bytes() output. If it's fast enough, it's simpler and lets
>> us get the full strength of a CSPRNG.
>
> With the ChaCha20 generator, that's fine, although note that this abandons
>
Hi Cyrille,
[auto build test WARNING on cryptodev/master]
[also build test WARNING on next-20161222]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto
> I do tend to like Ted's version in which we use batched
> get_random_bytes() output. If it's fast enough, it's simpler and lets
> us get the full strength of a CSPRNG.
With the ChaCha20 generator, that's fine, although note that this abandons
anti-backtracking entirely.
It also takes locks, so
On 22.12.2016 20:56, Andy Lutomirski wrote:
> It's also not quite clear to me why userspace needs to be able to
> calculate the digest on its own. A bpf(BPF_CALC_PROGRAM_DIGEST)
> command that takes a BPF program as input and hashes it would seem to
> serve the same purpose, and that would allow t
On Thu, Dec 22, 2016 at 11:34 AM, Alexei Starovoitov
wrote:
> On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote:
>> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
>> wrote:
>>> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>>>
>>> We don't prevent ebpf programs being load
On Thu, Dec 22, 2016 at 07:08:37PM +0100, Hannes Frederic Sowa wrote:
> I wasn't concerned about performance but more about DoS resilience. I
> wonder how safe half md4 actually is in terms of allowing users to
> generate long hash chains in the filesystem (in terms of length
> extension attacks ag
On Thu, Dec 22, 2016 at 9:25 AM, Andy Lutomirski wrote:
> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
> wrote:
>> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>>
>> We don't prevent ebpf programs being loaded based on the digest but
>> just to uniquely identify loaded progr
On Thu, Dec 22, 2016 at 11:24 AM, George Spelvin
wrote:
>> Having slept on this, I like it less. The problem is that a
>> backtracking attacker doesn't just learn H(random seed || entropy_0 ||
>> secret || ...) -- they learn the internal state of the hash function
>> that generates that value. T
> Having slept on this, I like it less. The problem is that a
> backtracking attacker doesn't just learn H(random seed || entropy_0 ||
> secret || ...) -- they learn the internal state of the hash function
> that generates that value. This probably breaks any attempt to apply
> security propertie
Hi Cyrille,
[auto build test ERROR on cryptodev/master]
[also build test ERROR on next-20161222]
[cannot apply to v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Cyrille-Pitchen/crypto
On Mon, Dec 19, 2016 at 10:20:45AM +0800, Ryder Lee wrote:
> Add DT bindings documentation for the crypto driver
>
> Signed-off-by: Ryder Lee
> ---
> .../devicetree/bindings/crypto/mediatek-crypto.txt | 27
> ++
> 1 file changed, 27 insertions(+)
> create mode 100644
> Doc
On Thu, Dec 22, 2016 at 5:59 PM, Hannes Frederic Sowa
wrote:
> We don't prevent ebpf programs being loaded based on the digest but
> just to uniquely identify loaded programs from user space and match up
> with their source.
Okay, so in that case, a weak hashing function like SHA1 could result
in
On Thu, Dec 22, 2016 at 7:08 PM, Hannes Frederic Sowa
wrote:
> I wasn't concerned about performance but more about DoS resilience. I
> wonder how safe half md4 actually is in terms of allowing users to
> generate long hash chains in the filesystem (in terms of length
> extension attacks against ha
On 22.12.2016 16:54, Theodore Ts'o wrote:
> On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote:
>> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
>> wrote:
>>> following up on what appears to be a random subject: ;)
>>>
>>> IIRC, ext4 code by default still uses half_md4 for
On Thu, 2016-12-22 at 09:25 -0800, Andy Lutomirski wrote:
> On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
> wrote:
> > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
> > >
> > > You mean:
> > >
> > > commit 7bd509e311f408f7a5132fcdde2069af65fa05ae
> > > Author: Daniel Borkmann
On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa
wrote:
> On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
>> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
>> wrote:
>> > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
>> > > Hi Hannes,
>> > >
>> > > On Thu, Dec
On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote:
> On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
> wrote:
> > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
> > > Hi Hannes,
> > >
> > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
> > > wrote:
> > > > IPv6
On Thu, Dec 22, 2016 at 8:28 AM, Jason A. Donenfeld wrote:
> Hi all,
>
> I don't know what your design requirements are for this. It looks like
> you're generating some kind of crypto digest of a program, and you
> need to avoid collisions. If you'd like to go with a PRF (keyed hash
> function) th
Hi all,
this series of patches has been based and tested on next-20161222 with
CRYPTO_MANAGER_DISABLED_TESTS not set.
The series adds support to the hmac(shaX) algorithms first, then combines
both the Atmel SHA and AES hardware accelerators to implement
authenc(hmac(shaX),Y(aes)) algorithms as
This is a transitional patch: it creates the atmel_sha_find_dev() function,
which will be used in further patches to share the source code responsible
for finding a Atmel SHA device.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 15 +++
1 file changed, 11 insertions
This patch is a transitional patch. It updates atmel_sha_done_task() to
make it more generic. Indeed, it adds a new .resume() member in the
atmel_sha_dev structure. This hook is called from atmel_sha_done_task()
to resume processing an asynchronous request.
Signed-off-by: Cyrille Pitchen
---
dri
This patch is a transitional patch. It splits the atmel_sha_handle_queue()
function. Now atmel_sha_handle_queue() only manages the request queue and
calls a new .start() hook from the atmel_sha_ctx structure.
This hook allows to implement different kind of requests still handled by
a single queue.
This patch simply defines a helper function to test the 'Data Ready' flag
of the Status Register. It also gives a chance for the crypto request to
be processed synchronously if this 'Data Ready' flag is already set when
polling the Status Register. Indeed, running synchronously avoid the
latency of
This patch adds a simple function to perform data transfer with the DMA
controller.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 116 +
1 file changed, 116 insertions(+)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel
This patch fixes the value returned by atmel_aes_handle_queue(), which
could have been wrong previously when the crypto request was started
synchronously but became asynchronous during the ctx->start() call.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-aes.c | 7 +--
1 file change
This patch defines an alias macro to SHA_MR_MODE_PDC, which is not suited
for DMA usage.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha-regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/atmel-sha-regs.h b/drivers/crypto/atmel-sha-regs.h
index deb0b0b15096..8d
When VERBOSE_DEBUG is defined and SHA_FLAGS_DUMP_REG flag is set in
dd->flags, this patch prints the register names and values when performing
IO accesses.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 110 -
1 file changed, 108 inser
This patch adds a simple function to perform data transfer with PIO, hence
handled by the CPU.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 90 ++
1 file changed, 90 insertions(+)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/cr
This patch modifies the SHA_FLAGS_SHA* flags: those algo flags are now
organized as values of a single bitfield instead of individual bits.
This allows to reduce the number of bits needed to encode all possible
values. Also the new values match the SHA_MR_ALGO_SHA* values hence
the algorithm bitfie
This patchs allows to combine the AES and SHA hardware accelerators on
some Atmel SoCs. Doing so, AES blocks are only written to/read from the
AES hardware. Those blocks are also transferred from the AES to the SHA
accelerator internally, without additionnal accesses to the system busses.
Hence, t
This patch adds support to the hmac(shaX) algorithms.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha-regs.h | 4 +
drivers/crypto/atmel-sha.c | 598 +++-
2 files changed, 601 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/atmel-s
On Thu, Dec 22, 2016 at 5:30 PM, Theodore Ts'o wrote:
> I'd do this first, as one set. Adding a new file to crypto is
> unlikely to cause merge conflicts.
Ack.
>
>> 2. convert char/random to use siphash. to: ted ts'o's random-next
>
> I'm confused, I thought you had agreed to the batched chacha
On Thu, Dec 22, 2016 at 05:16:47PM +0100, Jason A. Donenfeld wrote:
> Could you offer a bit of advice on how to manage dependencies between
> patchsets during merge windows? I'm a bit new to the process.
>
> Specifically, we how have 4 parts:
> 1. add siphash, and use it for some networking code.
Hi all,
I don't know what your design requirements are for this. It looks like
you're generating some kind of crypto digest of a program, and you
need to avoid collisions. If you'd like to go with a PRF (keyed hash
function) that uses some kernel secret key, then I'd strongly suggest
using Keyed-B
This patch simply defines a helper function to test the 'Data Ready' flag
of the Status Register. It also gives a chance for the crypto request to
be processed synchronously if this 'Data Ready' flag is already set when
polling the Status Register. Indeed, running synchronously avoid the
latency of
This is a transitional patch: it creates the atmel_sha_find_dev() function,
which will be used in further patches to share the source code responsible
for finding a Atmel SHA device.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 15 +++
1 file changed, 11 insertions
This patchs allows to combine the AES and SHA hardware accelerators on
some Atmel SoCs. Doing so, AES blocks are only written to/read from the
AES hardware. Those blocks are also transferred from the AES to the SHA
accelerator internally, without additionnal accesses to the system busses.
Hence, t
Hi Ted,
On Thu, Dec 22, 2016 at 4:58 PM, Theodore Ts'o wrote:
> Can we do this as a separate series, please? At this point, it's a
> completely separate change from a logical perspective, and we can take
> in the change through the random.git tree.
>
> Changes that touch files that are normally
This patch is a transitional patch. It updates atmel_sha_done_task() to
make it more generic. Indeed, it adds a new .resume() member in the
atmel_sha_dev structure. This hook is called from atmel_sha_done_task()
to resume processing an asynchronous request.
Signed-off-by: Cyrille Pitchen
---
dri
This patch fixes the value returned by atmel_aes_handle_queue(), which
could have been wrong previously when the crypto request was started
synchronously but became asynchronous during the ctx->start() call.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-aes.c | 7 +--
1 file change
When VERBOSE_DEBUG is defined and SHA_FLAGS_DUMP_REG flag is set in
dd->flags, this patch prints the register names and values when performing
IO accesses.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 110 -
1 file changed, 108 inser
This patch adds a simple function to perform data transfer with PIO, hence
handled by the CPU.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 90 ++
1 file changed, 90 insertions(+)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/cr
This patch modifies the SHA_FLAGS_SHA* flags: those algo flags are now
organized as values of a single bitfield instead of individual bits.
This allows to reduce the number of bits needed to encode all possible
values. Also the new values match the SHA_MR_ALGO_SHA* values hence
the algorithm bitfie
This patch defines an alias macro to SHA_MR_MODE_PDC, which is not suited
for DMA usage.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha-regs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/atmel-sha-regs.h b/drivers/crypto/atmel-sha-regs.h
index deb0b0b15096..8d
This patch adds support to the hmac(shaX) algorithms.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha-regs.h | 4 +
drivers/crypto/atmel-sha.c | 598 +++-
2 files changed, 601 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/atmel-s
This patch adds a simple function to perform data transfer with the DMA
controller.
Signed-off-by: Cyrille Pitchen
---
drivers/crypto/atmel-sha.c | 116 +
1 file changed, 116 insertions(+)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel
This patch is a transitional patch. It splits the atmel_sha_handle_queue()
function. Now atmel_sha_handle_queue() only manages the request queue and
calls a new .start() hook from the atmel_sha_ctx structure.
This hook allows to implement different kind of requests still handled by
a single queue.
Hi all,
this series of patches has been based and tested on next-20161222 with
CRYPTO_MANAGER_DISABLED_TESTS not set.
The series adds support to the hmac(shaX) algorithms first, then combines
both the Atmel SHA and AES hardware accelerators to implement
authenc(hmac(shaX),Y(aes)) algorithms as
On Wed, Dec 21, 2016 at 6:07 PM, Andy Lutomirski wrote:
> On Wed, Dec 21, 2016 at 5:13 PM, George Spelvin
> wrote:
>> As a separate message, to disentangle the threads, I'd like to
>> talk about get_random_long().
>>
>> After some thinking, I still like the "state-preserving" construct
>> that's
On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa
wrote:
> On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
>> Hi Hannes,
>>
>> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
>> wrote:
>> > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
>> > You don't
On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote:
> I find this compelling. We'll have one csprng for both
> get_random_int/long and for /dev/urandom, and we'll be able to update
> that silly warning on the comment of get_random_int/long to read
> "gives output of either rdrand qu
On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
> wrote:
> > following up on what appears to be a random subject: ;)
> >
> > IIRC, ext4 code by default still uses half_md4 for hashing of filenames
> > in the htree. siphash
On Thu, Dec 22, 2016 at 4:51 PM, Hannes Frederic Sowa
wrote:
> This algorithm should be a non-seeded algorithm, because the hashes
> should be stable and verifiable by user space tooling. Thus this would
> need a hashing algorithm that is hardened against pre-image
> attacks/collision resistance,
On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote:
> Hi Hannes,
>
> On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
> wrote:
> > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
> > You don't want to give people new IPv6 addresses with the same stable
> > secr
Hi Hannes,
On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa
wrote:
> IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI.
> You don't want to give people new IPv6 addresses with the same stable
> secret (across reboots) after a kernel upgrade. Maybe they lose
> connectivity
On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote:
> > As a first step, I'm considering adding a patch to move halfmd4.c
> > inside the ext4 domain, or at the very least, simply remove it from
> > linux/cryptohash.h. That'll th
On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote:
> As a first step, I'm considering adding a patch to move halfmd4.c
> inside the ext4 domain, or at the very least, simply remove it from
> linux/cryptohash.h. That'll then leave the handful of bizarre sha1
> usages to consider.
Specifica
On Thu, Dec 22, 2016 at 4:05 PM, Hannes Frederic Sowa
wrote:
> This change would need a new version of the ext4 super block, because
> you should not change existing file systems.
Right.
As a first step, I'm considering adding a patch to move halfmd4.c
inside the ext4 domain, or at the very leas
On 22.12.2016 14:10, Jason A. Donenfeld wrote:
> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
> wrote:
>> following up on what appears to be a random subject: ;)
>>
>> IIRC, ext4 code by default still uses half_md4 for hashing of filenames
>> in the htree. siphash seems to fit this use ca
From: Xin Zeng
The unsigned long type for init_status and start_status in
service_hndl are not long enough to represent more than 64
acceleration devices. Use an array instead.
Signed-off-by: Xin Zeng
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/adf_cfg_common.h | 1 +
d
Initialize dh.base.cra_flags before registering the dh algorithm.
Without this fix, the registration of the dh algorithm might fail
if the qat driver is restarted.
Signed-off-by: Sushil Kumar
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/qat_asym_algs.c | 1 +
1 file changed
From: Pablo Marcos Oltra
Remove leading zeros in pci function number to be consistent
with output from lspci.
Signed-off-by: Pablo Marcos Oltra
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_c3xxx/adf_drv.c | 2 +-
drivers/crypto/qat/qat_c3xxxvf/adf_drv.c| 2 +-
drivers/c
Some accelerators of the c62x series have only two bars.
This patch skips BAR0 if the accelerator does not have it.
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_c62x/adf_drv.c | 2 +-
drivers/crypto/qat/qat_common/adf_accel_devices.h | 1 +
2 files changed, 2 insertions
Zero embedded ram in DH85x devices. This is not
needed for newer generations as it is done by HW.
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/qat_hal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_hal.c
b/drivers
Replace BIT(0) macro with proper definition in pf2vf path
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/adf_vf_isr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_vf_isr.c
b/drivers/crypto/qat/qat_common/adf_vf_isr.
From: Ahsan Atta
Signed-off-by: Ahsan Atta
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/adf_sriov.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_sriov.c
b/drivers/crypto/qat/qat_common/adf_sriov.c
index 9320ae1.
From: Ahsan Atta
Signed-off-by: Ahsan Atta
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/adf_dev_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qat/qat_common/adf_dev_mgr.c
b/drivers/crypto/qat/qat_common/adf_dev_mgr.c
index b3ebb2
Guys,
so was it fixed or not?
I can not compile current git kernel:
linux-2.6$ git desc
v4.9-11937-g52bce91165e5
linux-2.6$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
linux-2.6$ git log --oneline arch/sparc/include/asm/topo
Cc Herbert and linux-crypto on this
https://marc.info/?l=linux-kernel&m=148226084823926
On (12/20/16 19:53), Sven Schmidt wrote:
>
> This patch updates the crypto modules using LZ4 compression to work with the
> new LZ4 kernel module version.
>
> Signed-off-by: Sven Schmidt <4ssch...@informat
On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa
wrote:
> following up on what appears to be a random subject: ;)
>
> IIRC, ext4 code by default still uses half_md4 for hashing of filenames
> in the htree. siphash seems to fit this use case pretty good.
I saw this too. I'll try to address it
Hi Ted,
On Thu, 2016-12-22 at 00:41 -0500, Theodore Ts'o wrote:
> On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote:
> >
> > Funny -- while you guys were sending this back & forth, I was writing
> > my reply to Andy which essentially arrives at the same conclusion.
> > Given that
Hi Herbert,
On 22 December 2016 at 14:25, Herbert Xu wrote:
> On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote:
>>
>> By the move everything to cryptoAPI we are basically introducing some
>> strange mix
>> of IV and modes there, I wonder how this is going to be maintained.
>> Anyway, H
-Original Message-
From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
Sent: Thursday, December 22, 2016 10:59 AM
To: Binoy Jayan
Cc: Milan Broz; Oded Golombek; Ofir Drang; Arnd Bergmann; Mark Brown; Alasdair
Kergon; David S. Miller; private-...@linaro.org; dm-de...@redhat.com;
linux-
On Thu, Dec 22, 2016 at 01:55:59PM +0530, Binoy Jayan wrote:
>
> > Support of bigger block sizes would be unsafe without additional mechanism
> > that provides
> > atomic writes of multiple sectors. Maybe it applies to 4k as well on some
> > devices though...)
>
> Did you mean write to the crypt
On Tue, Dec 13, 2016 at 11:01:08AM +0100, Milan Broz wrote:
>
> By the move everything to cryptoAPI we are basically introducing some strange
> mix
> of IV and modes there, I wonder how this is going to be maintained.
> Anyway, Herbert should say if it is ok...
Well there is precedent in how do t
Hi Milan,
On 21 December 2016 at 18:17, Milan Broz wrote:
> So the core problem is that your crypto accelerator can operate efficiently
> only
> with bigger batch sizes.
Thank you for the reply. Yes, that would be rather an improvement when having
bigger block sizes.
> How big blocks your cry
> True, but it's called get_random_int(), and it seems like making it
> stronger, especially if the performance cost is low to zero, is a good
> thing.
If it's cheap enough, I don't mind. But it's documented as being
marginal-quality, used where speed is more important.
In particular, it's *not*
80 matches
Mail list logo
