/geniv.h
Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org>
---
drivers/md/dm-crypt.c | 1894 ++--
include/crypto/geniv.h | 47 ++
2 files changed, 1402 insertions(+), 539 deletions(-)
create mode 100644 include/crypto/geniv.h
diff --git a/drivers
cessed in parallel and is freed in the async callback.
4. Changed allocation for sub-requests using mempool
v1 --> v2
--
1. dm-crypt changes to process larger block sizes (one segment in a bio)
2. Incorporated changes w.r.t. comments from Herbert.
Binoy Jayan (1):
crypto: Add IV g
Hi Herbert,
On 8 February 2017 at 13:02, Gilad Ben-Yossef <gi...@benyossef.com> wrote:
> On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan <binoy.ja...@linaro.org> wrote:
>> ===
>> dm-crypt optimiza
On 8 February 2017 at 13:02, Gilad Ben-Yossef wrote:
>
> Ran Bonnie++ on it last night (Luks mode, plain64, Qemu Virt platform
> Arm64) and it works just fine.
>
> Tested-by: Gilad Ben-Yossef
>
Hi Gilad,
Thank you for testing it. Do you have access to
eed in the async callback.
4. Changed allocation for sub-requests using mempool
v1 --> v2
--
1. dm-crypt changes to process larger block sizes (one segment in a bio)
2. Incorporated changes w.r.t. comments from Herbert.
Binoy Jayan (1):
crypto: Add IV generation algorithms
drivers
/geniv.h
Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org>
---
drivers/md/dm-crypt.c | 1891 ++--
include/crypto/geniv.h | 47 ++
2 files changed, 1399 insertions(+), 539 deletions(-)
create mode 100644 include/crypto/geniv.h
diff --git a/drivers
Hi Gilad,
On 18 January 2017 at 20:51, Gilad Ben-Yossef wrote:
> I have some review comments and a bug report -
Thank you very much for testing this on ARM and for the comments.
> I'm pretty sure this needs to be
>
> n2 = bio_segments(ctx->bio_out);
Yes you are right,
Hi Ondrej,
On 12 January 2017 at 18:29, Ondrej Mosnacek wrote:
> This patch converts dm-crypt to use bulk requests when invoking skcipher
> operations, allowing the crypto drivers to process multiple sectors at once,
> while reducing the overhead caused by the small sector
Hi Milan,
On 13 January 2017 at 17:31, Ondrej Mosnáček wrote:
> 2017-01-13 11:41 GMT+01:00 Herbert Xu :
>> On Thu, Jan 12, 2017 at 01:59:52PM +0100, Ondrej Mosnacek wrote:
>>> the goal of this patchset is to allow those skcipher API users that
Hi Gilad,
On 19 January 2017 at 15:17, Gilad Ben-Yossef wrote:
> I tried adding sg_init_table() where I thought it was appropriate and
> it didn't resolve the issue.
>
> For what it's worth, my guess is that the difference between our
> setups is not related to Arm but to
On 28 November 2016 at 18:17, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Nov 21, 2016 at 03:40:09PM +0530, Binoy Jayan wrote:
>> Currently, the iv generation algorithms are implemented in dm-crypt.c.
>> The goal is to move these algorithms from the dm layer to
Hi Herbert,
On 29 November 2016 at 12:58, Herbert Xu wrote:
> But that begs the question, who is supposed to use crypto_geniv_set_ctx?
> I thought it was dm-crypt but your patch doesn't contain any uses
> of it at all.
No one is using it as of now. It was just a
ypt_fun
cryptsetup luksRemoveKey /dev/sdb
This seems to work well. The file system mounts successfully and the files
written to in the file system remain persistent across reboots.
Binoy Jayan (1):
crypto: Add IV generation algorithms
crypto/Kconfig|8 +
crypto/Makefile
and tcw. These templates are to be configured
and has to be invoked as:
crypto_alloc_skcipher("plain(cbc(aes))", 0, 0);
crypto_alloc_skcipher("essiv(cbc(aes))", 0, 0);
...
from the dm layer.
Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org>
---
crypto/Kconfig
ayer, each cipher
instance set with a unique subkey (part of the bigger master key) and
these instances themselves do not have access to each other's instances
or contexts. This way, a single instance cannot encryt/decrypt a whole bio.
This has to be fixed.
Not-signed-off-by: Binoy Jayan <b
-t ext4 /dev/mapper/crypt_fun /mnt
<-- Use the encrypted file system -->
umount /mnt
cryptsetup luksClose crypt_fun
cryptsetup luksRemoveKey /dev/sdb
This seems to work well. The file system mounts successfully and the files
written to in the file system remain persistent across reboots.
Hi Milan,
Thank you for the reply.
On 13 December 2016 at 15:31, Milan Broz wrote:
> I really do not think the disk encryption key management should be moved
> outside of dm-crypt. We cannot then change key structure later easily.
Yes, I agree. but the key selection based
Hi Milan,
On 13 December 2016 at 15:31, Milan Broz wrote:
> I think that IV generators should not modify or read encrypted data directly,
> it should only generate IV.
I was trying to find more information about what you said and how a
iv generator should be written. I saw
Hi Gilad,
On 3 January 2017 at 19:53, Gilad Ben-Yossef wrote:
> Good idea. I wanted to test the patch but alas it does not apply cleanly.
> You seem to have a blank line at the end of files and other small
> transgressions that makes checkpatch grumpy.
I think that is
On 2 January 2017 at 12:23, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote:
>>
>> Even if ciphers are allocated this way, all the encryption requests
>> for cbc should still go through IV generators? So that
Hi Herbert,
On 30 December 2016 at 15:57, Herbert Xu wrote:
> This is just a matter of structuring the key for the IV generator.
> The IV generator's key in this case should be a combination of the
> key to the underlying CBC plus the set of all keys for the IV
>
Hi Herbert,
On 2 January 2017 at 12:23, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> On Mon, Jan 02, 2017 at 12:16:45PM +0530, Binoy Jayan wrote:
>
> Right. The actual number of underlying tfms that do the work
> won't change compared to the status quo. We'r
: add ability to use keys from the kernel key retention service
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 understa
At a high level the goal is to maximize the size of data blocks that get passed
to hardware accelerators, minimizing the overhead from setting up and tearing
down operations in the hardware. Currently dm-crypt itself is a big blocker as
it manually implements ESSIV and similar algorithms which
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.
>
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
On 6 March 2017 at 20:08, Gilad Ben-Yossef wrote:
>
> I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and
> on Arm using CryptoCell hardware accelerator.
>
> There was no difference in performance between 512 and 4096 bytes
> cluster size on the x86_64 (800
/geniv.h
Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org>
---
drivers/md/dm-crypt.c | 1916 ++--
include/crypto/geniv.h | 47 ++
2 files changed, 1424 insertions(+), 539 deletions(-)
create mode 100644 include/crypto/geniv.h
diff --git a/drivers
sts using mempool
v1 --> v2
--
1. dm-crypt changes to process larger block sizes (one segment in a bio)
2. Incorporated changes w.r.t. comments from Herbert.
Binoy Jayan (1):
crypto: Add IV generation algorithms
drivers/md/dm-crypt.c | 1916 ++---
Hi Milan,
On 10 April 2017 at 19:30, Milan Broz wrote:
Thank you for the reply.
> Well, it is good that there is no performance degradation but it
> would be nice to have some user of it that proves it is really
> working for your hw.
I have been able to get access to a
it was written for.
The underlying IV generator 'essiv-aes-du512-dx' generates IV for
every 512 byte blocks.
Signed-off-by: Binoy Jayan <binoy.ja...@linaro.org>
---
drivers/md/dm-crypt.c|5 +-
drivers/staging/ccree/Makefile |2 +-
drivers/staging/ccree/essiv.c
process larger block sizes (one segment in a bio)
2. Incorporated changes w.r.t. comments from Herbert.
Binoy Jayan (2):
crypto: Add IV generation algorithms
crypto: Multikey template for essiv
drivers/md/dm-crypt.c| 1940 +++---
drivers/staging
/decrypt a sector are processed
sequentially. Asynchronous requests if processed in parallel, are freed
in the async callback. The storage space for the initialization vectors
are allocated in the iv generator implementations.
Interface to the crypto layer - include/crypto/geniv.h
Signed-off-by: Binoy
33 matches
Mail list logo