> -Original Message-
> From: Eric Biggers
> Sent: Saturday, August 10, 2019 12:05 AM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
> generation
>
> On Fri, Aug 09, 2019 at 0
On Fri, Aug 09, 2019 at 09:33:14PM +, Pascal Van Leeuwen wrote:
> Real life designs require all kinds of trade-offs and compromises.
> If you want to make something twice as expensive, you'd better have a
> really solid reason for doing so. So yes, I do believe it is useful to
> be sceptical a
> -Original Message-
> From: Eric Biggers
> Sent: Friday, August 9, 2019 10:56 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
> generation
>
> On Fri, Aug 09, 2019 at 0
On Fri, Aug 09, 2019 at 08:29:59PM +, Pascal Van Leeuwen wrote:
> >
> > There's no proof that other attacks don't exist.
> >
> As you can't prove something doesn't exist ...
Of course you can, that's what the security proofs for crypto constructions
always do. They prove that no efficient at
> -Original Message-
> From: Eric Biggers
> Sent: Friday, August 9, 2019 7:17 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
> generation
>
> On Fri, Aug 09, 2019 at 0
linux-
> > cry...@vger.kernel.org; herb...@gondor.apana.org.au; a...@redhat.com;
> > snit...@redhat.com;
> > dm-de...@redhat.com
> > Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
> > generation
> >
> > On Thu, Aug 08, 2019 at 01:23:10PM +, Pasc
..@redhat.com
> Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
> generation
>
> On Thu, Aug 08, 2019 at 01:23:10PM +, Pascal Van Leeuwen wrote:
> > > -Original Message-
> > > From: Milan Broz
> > > Sent: Thursday, August 8, 20
t - reuse eboiv skcipher for IV
> generation
>
> (trim cc)
>
> >
> > > > > In your case, we are not dealing with known plaintext attacks,
> > > > >
> > > > Since this is XTS, which is used for disk encryption, I would argue
> > >
;
> > ebigg...@kernel.org;
> > a...@redhat.com; snit...@redhat.com; dm-de...@redhat.com;
> > gmazyl...@gmail.com
> > Subject: Re: [RFC PATCH v2] md/dm-crypt - reuse eboiv skcipher for IV
> > generation
> >
> > On Wed, 7 Aug 2019 at 16:52, Pascal V
Two different users of ESSIV (encrypted salt|sector IV) implement the
algorithm using bare shash and cipher transform. This is not a huge
deal, since the algorithm is fairly simple, but it does require us to
keep the cipher interface public. Since the cipher interface is often
used incorrectly, and
IV generation is done only at AEAD level.
Support in ablkcipher is not needed, thus remove the dead code.
Link:
https://www.mail-archive.com/search?l=mid&q=20160901101257.ga3...@gondor.apana.org.au
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg.c |
IV generation is done only at AEAD level.
Support in ablkcipher is not needed, thus remove the dead code.
Link:
https://www.mail-archive.com/search?l=mid&q=20160901101257.ga3...@gondor.apana.org.a
Signed-off-by: Horia Geantă
---
drivers/crypto/caam/caamalg_desc.c | 81
dri
On Mon, May 7, 2018 at 2:29 PM, Stephan Mueller wrote:
> Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> ah... so if I have hardware that can implement say, seqiv, I can
>> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are
>> right, it will be used
Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
> ah... so if I have hardware that can implement say, seqiv, I can
> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are
> right, it will be used?
That is the question I cannot fully answer. Seqiv is a templat
On Mon, May 7, 2018 at 2:02 PM, Stephan Mueller wrote:
> Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> Hi,
>>
>> A quick question: am I correct in my understanding that there is now
>> no automatic IV generation support for
Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
> Hi,
>
> A quick question: am I correct in my understanding that there is now
> no automatic IV generation support for either skcipher nor aead?
> And if I'm wrong, can someone point to an exam
Hi,
A quick question: am I correct in my understanding that there is now
no automatic IV generation support for either skcipher nor aead?
And if I'm wrong, can someone point to an example of a driver that
implements either, as all the ones I see are the deprecated ablkcipher
interface.
BTW
ger block sizes
> > ===
> >
> > Currently, the iv generation algorithms are implemented in dm-crypt.c. The
> > goal
> > is to move these algorithms from the dm layer to the kernel crypto layer by
> > implementing them as template ciphers so they can be used in relat
On Thu, May 18, 2017 at 01:40:38PM +0200, Ondrej Mosnacek wrote:
>
> > Actually I think this one can probably easily handled in the crypto
> > layer. All we need is to add a multikey template that sits on top
> > of an underlying IV generator. The multikey instance can then accept
> > a key lengt
Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
>
> Currently, the iv generation algorithms are im
===
dm-crypt optimization for larger block sizes
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move
Just for reference. Not for merging.
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of
it into multiple keys.
Also with the LMK mode, there is a similar optional key appendix,
which is of the same size as the other subkeys.
>> b) New AEAD functionality; random IV generator.
>> The soon-to-be-added AEAD functionality in dm-crypt
>> introduces a ne
st in request-based dm-crypt. It is a hack
to work-around limitations in crypto IV generation.
I agree. This is why I've said I'm interested in a high performance
dm-crypt,
not "request based dm-crypt". They are trying to solve the same
problem but
with the wrong solution and
es it difficult to help - which is a shame since I am interested
in enabling higher performance
of dm-crypt when using HW based crypto transformation myself.
I have absolutely no interest in request-based dm-crypt. It is a hack
to work-around limitations in crypto IV generation.
I agree. This i
erested
>> in enabling higher performance
>> of dm-crypt when using HW based crypto transformation myself.
>
> I have absolutely no interest in request-based dm-crypt. It is a hack
> to work-around limitations in crypto IV generation.
I agree. This is why I've said I
terest in request-based dm-crypt. It is a hack
to work-around limitations in crypto IV generation.
If "google" is foolish enough to deploy out-of-tree request-based
dm-crypt in their android kernel then they are easily capable of
reverting the commit in question to prop up their shor
Add CryptoCell IV hardware generation support.
This patch adds the needed support to drive the HW but does not expose
the ability via the kernel crypto API yet.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/Makefile | 2 +-
drivers/staging/ccree/ssi_buffer_mgr.c | 2 +
Add CryptoCell IV hardware generation support.
This patch adds the needed support to drive the HW but does not expose
the ability via the kernel crypto API yet.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/Makefile | 2 +-
drivers/staging/ccree/ssi_buffer_mgr.c | 2 +
e with IV generation support
a few days back. The hardware I was having before did not have IV
generation support. Will be able to come up with numbers after making
it work with the new one.
> FYI - with patch that increases dmcrypt sector size to 4k
> I can see improvement in speed usually in 5-15
On 04/07/2017 12:47 PM, Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
...
> Tests with dd [direct i/o]
>
> Sequent
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code
===
dm-crypt optimization for larger block sizes
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move
New AEAD functionality; random IV generator.
> The soon-to-be-added AEAD functionality in dm-crypt
> introduces a new IV generator that generates IVs randomly and stores
> them as sector metadata. This means IV generation cannot be handled
> solely in the driver. Also, additional AEAD imple
On Thu, Apr 06 2017 at 5:29am -0400,
Herbert Xu wrote:
> On Fri, Mar 10, 2017 at 02:44:26PM +0100, Ondrej Mosnacek wrote:
> > Hi all,
> >
> > I was tasked to post a summary the whole dm-crypt IV generation
> > problem and all the suggested solutions along with thei
On Fri, Mar 10, 2017 at 02:44:26PM +0100, Ondrej Mosnacek wrote:
> Hi all,
>
> I was tasked to post a summary the whole dm-crypt IV generation
> problem and all the suggested solutions along with their drawbacks, so
> here it goes...
Thanks for the summary. It looks good to me.
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 MB loop file system)
On Fri, Mar 10 2017 at 8:44am -0500,
Ondrej Mosnacek wrote:
> Hi all,
>
> I was tasked to post a summary the whole dm-crypt IV generation
> problem and all the suggested solutions along with their drawbacks, so
> here it goes...
Thanks for the summary.
...
> 2. Res
Hi all,
I was tasked to post a summary the whole dm-crypt IV generation
problem and all the suggested solutions along with their drawbacks, so
here it goes...
PROBLEM STATEMENT:
Currently, dm-crypt uses a fixed 512-byte sector size and handles
en-/decrypting of a bio by submitting a separate
On Wed, Mar 1, 2017 at 5:38 PM, Milan Broz wrote:
>
> On 03/01/2017 02:04 PM, Milan Broz wrote:
>> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
>> ...
>>
>>> I can certainly understand if you don't wont to take the patch until
>>> we have results with
>>> dm-crypt itself but the difference betw
On Wed, Mar 1, 2017 at 3:21 PM, Ondrej Mosnacek wrote:
> 2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef :
>
> Wouldn't adopting a bulk request API (something like what I tried to
> do here [1]) that allows users to supply multiple messages, each with
> their own IV, fulfill this purpose? That way, we
On 03/01/2017 02:04 PM, Milan Broz wrote:
> On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
> ...
>
>> I can certainly understand if you don't wont to take the patch until
>> we have results with
>> dm-crypt itself but the difference between 8 separate invocation of
>> the engine for 512
>> bytes
2017-03-01 13:42 GMT+01:00 Gilad Ben-Yossef :
> It really is an observation about overhead of context switches between
> dm-crypt and
> whatever/wherever you handle crypto - be it an off CPU hardware engine
> or a bunch
> of parallel kernel threads running on other cores. You really want to
> burst
On 03/01/2017 01:42 PM, Gilad Ben-Yossef wrote:
...
> I can certainly understand if you don't wont to take the patch until
> we have results with
> dm-crypt itself but the difference between 8 separate invocation of
> the engine for 512
> bytes of XTS and a single invocation for 4KB are pretty big
that do not support own IV
> >> generators.
> >>
> >
> > AFAIK the problem that we are trying to solve is that if the IV is
> > generated outside the crypto API
> > domain than you are forced to have an invocation of the crypto API per
> > each block
that there is a potential
>> to speedup things even for crypt drivers that do not support own IV
>> generators.
>>
>
> AFAIK the problem that we are trying to solve is that if the IV is
> generated outside the crypto API
> domain than you are forced to have an invo
that if the IV is
generated outside the crypto API
domain than you are forced to have an invocation of the crypto API per
each block because you
need to provide the IV for each block.
By putting the IV generation responsibility in the Crypto API we open
the way to do a single invocation
of the
On 02/22/2017 07:12 AM, Binoy Jayan wrote:
>
> I was wondering if this is near to be ready for submission (apart from
> the testmgr.c
> changes) or I need to make some changes to make it similar to the IPSec
> offload?
I just tried this and except it registers the IV for every new device again,
ger block sizes
>> ===
>>
>> Currently, the iv generation algorithms are implemented in dm-crypt.c. The
>> goal
>> is to move these algorithms from the dm layer to the kernel crypto layer by
>> implementing them as template ciphers
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 a device having crypt
On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan wrote:
> ===
> dm-crypt optimization for larger block sizes
> ===
>
> Currently, th
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code
===
dm-crypt optimization for larger block sizes
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move
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 other options or the sto
On Thu, Jan 19, 2017 at 6:42 AM, Binoy Jayan wrote:
> 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.
My pleasure. Thanks for writing the code :-)
>
>>> +
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, that was a typo :)
>> +
Hi Binoy,
On Wed, Jan 18, 2017 at 11:40 AM, 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 the kernel
> crypto layer by implementing them as template ciphers so they can be
> im
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code
===
GENIV Template cipher
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move these algorithms from
Hi Binoy,
2016-12-13 9:49 GMT+01:00 Binoy Jayan :
> Currently, the iv generation algorithms are implemented in dm-crypt.c.
> The goal is to move these algorithms from the dm layer to the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemented in
if the overall scheme is supported by the hardware
> then we can feed more than one sector at a time to it.
I was thinking of continuing to have the iv generation algorithms as template
ciphers instead of regular 'skcipher' as it is easier to inherit the parameters
from the underlyin
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 because there were some key
Hi Binoy,
On Tue, Dec 13, 2016 at 02:19: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 the kernel
> crypto layer by implementing them as template ciphers so th
On 2 January 2017 at 12:23, Herbert Xu 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 should mean,
>> create one instance of IV generator using
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 should mean,
> create one instance of IV generator using 'crypto_alloc_skcipher'
> and create tfms_count ins
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
> generator itself. It should the
On Thu, Dec 29, 2016 at 02:53:25PM +0530, Binoy Jayan wrote:
>
> When we keep these in dm-crypt and if more than one key is used
> (it is actually more than one parts of the original key),
> there are more than one cipher instance created - one for each
> unique part of the key. Since the crypto re
Hi Herbert,
Sorry for the delayed response, I was busy with testing dm-crypt
with bonnie++ for regressions. I tried to find some alternative
way to keep the IV algorithms' registration in the dm-crypt.
Also there were some changes done in dm-crypt keys structure too
recently.
c538f6e dm crypt: ad
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
to be maintained.
>> Anyway, Herbert should say if it is ok...
>
> Well there is precedent in how do the IPsec IV generation. In
> that case the IV generators too are completely specific to that
> application, i.e., IPsec. However, the way structured it allowed
> us to have one
edent in how do the IPsec IV generation. In
that case the IV generators too are completely specific to that
application, i.e., IPsec. However, the way structured it allowed
us to have one single entry path from the IPsec stack into the
crypto layer regardless of whether you are using AEAD
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 two examples of IV ge
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 on sector number rest
On 12/13/2016 09:49 AM, 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 the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemented in
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be
implemented in hardware for performance. As part of this patchset, the
iv-generation code
===
GENIV Template cipher
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move these algorithms from
On Tue, Nov 29, 2016 at 01:16:46PM +0530, Binoy Jayan wrote:
>
> No one is using it as of now. It was just a thought to pass context
> information, instead of making it part of the context which is shared
> among dm-crypt and geniv.
OK in that case we should just get rid of it until it's actually
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 thought to pass context
informati
On Tue, Nov 29, 2016 at 10:15:40AM +0530, Binoy Jayan wrote:
>
> Thank you for the reply. The dm-crypt changes are also included as
> part of this patchset. It has been tested for functionality as well.
> More information can be found in the cover letter including the test
> procedure etc.
>
> htt
On 28 November 2016 at 18:17, Herbert Xu 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 the kernel
>> crypto layer by
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 the kernel
> crypto layer by implementing them as template ciphers so they can be used
>
===
GENIV Template cipher
===
Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
is to move these algorithms from
Currently, the iv generation algorithms are implemented in dm-crypt.c.
The goal is to move these algorithms from the dm layer to the kernel
crypto layer by implementing them as template ciphers so they can be used
in relation with algorithms like aes, and with multiple modes like cbc,
ecb etc. As
On 05/20/2016 06:31 PM, Herbert Xu wrote:
On Fri, May 20, 2016 at 10:50:38AM -0500, Gary R Hook wrote:
Why is (or should) setting geniv (be) required?
crypto_givcipher_default() appears to call crypto_default_geniv() if
the geniv member
is NULL. That function returns "eseqiv" or "chainiv" (und
On Fri, May 20, 2016 at 10:50:38AM -0500, Gary R Hook wrote:
>
> Why is (or should) setting geniv (be) required?
>
> crypto_givcipher_default() appears to call crypto_default_geniv() if
> the geniv member
> is NULL. That function returns "eseqiv" or "chainiv" (under certain
> conditions). If an
>
On 05/19/2016 11:19 PM, Herbert Xu wrote:
Denis B wrote:
My algs struct now looks like this:
static struct crypto_alg pp_crypto_algs[] = {
{
.cra_name = "authenc(hmac(sha256),cbc(aes))",
.cra_driver_name = "pp_crypto_cbc_hmac_sha256",
.cra_priority = 1, /**TODO set to high
Denis B wrote:
> My algs struct now looks like this:
>
> static struct crypto_alg pp_crypto_algs[] = {
> {
> .cra_name = "authenc(hmac(sha256),cbc(aes))",
> .cra_driver_name = "pp_crypto_cbc_hmac_sha256",
> .cra_priority = 1, /**TODO set to highest values after
> implementing enc
__
> From: Denis B
> Sent: Wednesday, May 18, 2016 5:21 PM
> To: Catalin Vasile
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: IV generation in cryptographic driver in AEAD
>
> Forgive my dumbness, but in:
>
> .cra_type
Inline comments
From: Denis B
Sent: Wednesday, May 18, 2016 5:21 PM
To: Catalin Vasile
Cc: linux-crypto@vger.kernel.org
Subject: Re: IV generation in cryptographic driver in AEAD
Forgive my dumbness, but in:
.cra_type = &crypto_aead_
Denis B wrote:
> Forgive my dumbness, but in:
>
> .cra_type = &crypto_aead_type,
> .cra_u = {
>.aead = {
>.setkey = pp_crypto_aead_setkey,
>.setauthsize = pp_crypto_aead_setauthsize,
>.decrypt = pp_crypto_aead_dec,
>
e see the ASCII art at
[1]. The IV generation is done with the seqiv component. So, you driver can
implement all of the logic of GCM, but pull the IV generation from the C
implementation provided by the kernel crypto API.
[1] http://www.chronox.de/crypto-API/ch02s07.html
>
> What if m
(or set to NULL)?
On Wed, May 18, 2016 at 4:56 PM, Catalin Vasile wrote:
> Inline comments.
>
>
> From: linux-crypto-ow...@vger.kernel.org
> on behalf of Denis B
> Sent: Wednesday, May 18, 2016 3:06 PM
> To: linux-crypto@vger
Inline comments.
From: linux-crypto-ow...@vger.kernel.org
on behalf of Denis B
Sent: Wednesday, May 18, 2016 3:06 PM
To: linux-crypto@vger.kernel.org
Subject: IV generation in cryptographic driver in AEAD
Hello,
In AEAD mode (or in any case, in IPSec
Hello,
In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel
versions prior to 4.2 the cryptographic driver is expected to generate
an IV.
What if my driver is unable to generate an IV?
Thanks,
Dennis.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
t
This patch makes use of the new common IV generation code.
Signed-off-by: Herbert Xu
---
crypto/echainiv.c | 230 --
1 file changed, 18 insertions(+), 212 deletions(-)
diff --git a/crypto/echainiv.c b/crypto/echainiv.c
index 02d0543
This patch adds some common IV generation code currently duplicated
by seqiv and echainiv. For example, the setkey and setauthsize
functions are completely identical.
Signed-off-by: Herbert Xu
---
crypto/aead.c | 205 +++-
include/crypto
This patch makes use of the new common IV generation code.
Signed-off-by: Herbert Xu
---
crypto/seqiv.c | 92 ++---
1 file changed, 36 insertions(+), 56 deletions(-)
diff --git a/crypto/seqiv.c b/crypto/seqiv.c
index b55c685..9c4490b
result is a lot of
black magic all spread out through the crypto stack. You just have
to take a look at the complexity in crypto/authenc.c to know what
I'm talking about (not to mention crypto/authencesn.c).
Another wart in the system is IV generation. This is exclusively
used by IPsec. Howeve
Hi,
In geode-aes, there is not any IV generation mechanism. In fact IV is
delivered to geode-aes's
registered algorithms, from upper layers.For example in case of
"cbc-aes-geode" algorithm,
from cbc wrapper ("cbc.c") via walk->iv:
blkcipher_walk_init(&
Hi all,
I could'nt understand the mechanism of IV generation in geode-aes. Can
someone explain it in easy to understand manner?
Thanks a lot.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More ma
1 - 100 of 109 matches
Mail list logo
