e crypto-engine?
>
> What do you mean by the crypto-engine?
crypto-engine is the generic queueing mechanism that any crypto
driver can use to implement the queueing.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubk
ocated within the crypto request
object. That's why we have the reqsize field to indicate how much
memory could be needed per request.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing li
t away. We could mark the
known broken ones (or the known working ones) and then dm-crypt
can allocate only those using the types/mask to crypto_alloc.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-deve
posed to do any real work in IRQ handlers. All
the substantial work should be postponed to softirq context.
Why do you need to do work in hard IRQ context?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel
errupt.
Yes you are absolutely right. In general high-performance work
should be carried out in softirq context. That's how the networking
stack works for example.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pub
NHERITED_FLAGS (CRYPTO_ALG_ASYNC |
> CRYPTO_ALG_ALLOCATES_MEMORY)
Any reason why you need to renumber NOLOAD? If not please keep
the existing values.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
reqmanager.c | 12 ++--
> drivers/crypto/cavium/cpt/request_manager.h |2 ++
> 3 files changed, 9 insertions(+), 6 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Without the backlog flag, if the hardware queue is full the request
will simply be dropped, which is appropriate in the network stack
with IPsec where congestion can be dealt with at the source.
Block layer on the other hand should always use the backlog flag
and stop sending more requests to the
struct aead_alg *alg;
> + u32 mask;
> int err;
>
> algt = crypto_get_attr_type(tb);
> if (IS_ERR(algt))
> return PTR_ERR(algt);
Then we could remove this bit.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~he
pto_algt_inherited_mask,
e.g.,
u32 mask;
int err;
err = crypto_algt_inherited_mask(tb, CRYPTO_ALG_TYPE_SHASH);
if (err < 0)
return err;
mask = err;
This could then be used to simplify other templates too, such as
gcm.
Thanks,
--
000 from working).
> Please take a look at v2. Thanks!
Looks good. Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
| 1 +
> drivers/md/dm-crypt.c | 17 ++-
> include/crypto/algapi.h | 25 ++--
> include/crypto/internal/geniv.h | 2 +-
> include/linux/crypto.h| 36 +-
> 62 files changed, 562 insertions(+), 405 deletions(-)
Patches 1-6 applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
extra memory as needed.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Tue, Oct 27, 2020 at 05:41:55AM +1100, Herbert Xu wrote:
>
> The point is that people rebuilding their kernel can end up with a
> broken system. Just set a default on EBOIV if dm-crypt is on.
That's not enough as it's an existing option. So we need to
add a new Kconfig op
nk a lot of dm-crypt users don't want to bloat their kernels with
> random
> legacy algorithms.
The point is that people rebuilding their kernel can end up with a
broken system. Just set a default on EBOIV if dm-crypt is on.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.a
BOIV
> default to dm-crypto Kconfig option value does solves the problem, or
> have I missed something?
Oh I'm mistaken then. I thought it was an existing option. If
it's a new option then a default depending on dm-crypt should be
sufficient.
Thanks,
--
Email: Herbert Xu
Home Pag
ypto. I think as long as drivers/md
is the only user of the said code then having it in drivers/md should
be fine.
However, if we end up using/reusing the same code for others such as
fs/crypto then it might make more sense to have them in crypto.
Cheers,
--
Email: Herbert Xu
H
number so that's
presumably why 64 bits is sufficient. Do you forsee a case where
we need 128-bit block numbers?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, Jun 20, 2019 at 09:13:25AM +0800, Herbert Xu wrote:
> On Wed, Jun 19, 2019 at 06:04:17PM -0700, Eric Biggers wrote:
> >
> > > +#define ESSIV_IV_SIZEsizeof(u64) // IV size of the outer
> > > algo
> > > +#define MAX_INNER_IV_SIZE
n order to take advantage of this.
My preference would be to encode the sector size into the key.
Hardware that can only support some sector sizes can use fallbacks
as usual.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
ome along and fix it later.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
it could
serve as an example for future implementations.
What do the dm-crypt people think? Are you ever going to need
processing in units other than 4K?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
tor sizes can use a
fallback.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
makes sense.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
#x27;s implementation itself.
AFAICS this is using the same key as the actual data. So why
don't you combine it with the actual data when encrypting/decrypting?
That is, add a block at the front of the actual data containing
the little-endian byte offset and then use an IV of zero.
Cheers,
--
l data containing
> > the little-endian byte offset and then use an IV of zero.
> >
>
> That would only work for encryption.
True. So this doesn't obviate the need to access the single-block
cipher. But the code probably should still do it that way for
encryption for perform
he driver.
But the whole point of XTS is that it supports sizes that are
not multiples of the block size. So implementing it without
supporting ciphertext stealing is just wrong.
So let's fix the generic implementation rather than breaking
the caam driver.
Thanks,
--
Email: Herbert
via the existing cts template, and add
> support for wrapping XTS to it.
XTS without stealing should be renamed as XEX. Sure you can then
wrap it inside cts to form xts but the end result needs to be called
xts.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herber
essions for ARM. We could rename the existing xts to a
new name (xek perhaps) and add xts into the cts template as
a wrapper around xek.
That way you don't have to touch the ARM code at all and it
should just work.
PS should we mark xek or whatever it's called as internal so
it isn&#
ne by one).
But if you were going to volunteer to change them all in one swoop
then it wouldn't matter.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
the one for CBC as implemented by the current CTS template.
The template is just a name. The implementation can do whatever it
wants for each instance. So obviously we would employ a different
implementation for xts compared to cbc.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herb
rce the implementation cannot do that.
You simply use the underlying xts for the first n - 2 blocks and
do the last two by hand.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
rformance. This means whatever wrapper we invent around xex()
> (or whatever we call it) should go out of its way to ensure that the
> common, non-CTS case does not regress in performance, and the special
> handling is only invoked when necessary (which will be never).
Agreed.
Cheers,
--
Emai
does* implement the cipher text stealing properly, just to be able to boast
> about IEEE P1619 compliance ...)
If your hardware supports XTS properly then you wouldn't even need
to use this new template. You would directly export the xts
interface.
Cheers,
--
Email: Herbert Xu
Home Pa
an what is currently being supported by dm-crypt.
Similary for the skcipher case, given
essiv(cbc(X),Y,Z)
is it ever possible for X != Y? If not then we should just make the
algorithm name essiv(X,Z).
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> > algorithm name essiv(X,Z).
> >
>
> Same problem. We'd need to instantiate the skcipher and parse the cra_name.
>
> Perhaps we should introduce a crypto API call that infers the cra_name
> from a cra_driver_name?
You don't need to do that. Just copy wh
atchwork you need to put the new
Subject in the email headers.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
fact is that this is an interface that we export to user-space
and we must NEVER break that. So if your driver is breaking this
interface then your driver is broken and needs to be fixed.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
gt; >
>
> Yeah, that makes sense. But we have h/w drivers that instantiate
> authenc(X,Y) in its entirety, and passing those driver names is
> something that is supported today, so we can't just remove that.
Sure, we only need to impose a restriction on the cra_name, not
on the driver name.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
channel so we can
tear down the top-level instance when a better underlying spawn
implementation is added to the system.
For these two algorithms, we don't really care about their performance
to do such a tear-down since they only operate on small pieces of
data.
Therefore just keep things sim
refore the TFM allocation. What is the problem?
IOW the presence of the block cipher and unkeyed hash does not
affect the creation of the instance object.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel m
s similar to fallbacks.
In fact we don't check any gemoetry on the fallbacks at all.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
+ goto out_drop_skcipher;
> + }
Holding a reference to this algorithm for the life-time of the
instance is not nice. How about just doing a lookup as you were
doing before with crypto_alg_mod_lookup and getting the cra_name
from that?
Thanks,
--
Email: Herbert Xu
Home Page: http://gon
On Mon, Aug 19, 2019 at 05:14:25PM +0300, Ard Biesheuvel wrote:
>
> OK, but it should be the cra_driver_name not the cra_name. Otherwise,
> allocating essiv(cbc(aes),sha256-generic) may end up using a different
> implementation of sha256, which would be bad.
I agree.
Thanks,
--
Em
n, but then
> just implement proper crypto API module that accelerates particular cipher.
I agree. Please take a look at the recent ESSIV patches on
linux-crypto and build multi-block operations on top of them
which can then be implemented by the hardware.
Cheers,
--
Email: Herbert Xu
Home P
On Wed, Aug 21, 2019 at 04:57:41PM +0900, boojin.kim wrote:
>
> Can you tell me which patch you mentioned? Is this?
> https://patches.linaro.org/project/linux-crypto/list/?series=22762
Yes this is the one.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert
support is the offloading of encryption/decryption
over many sectors.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
| 663
> 3 files changed, 692 insertions(+)
Acked-by: Herbert Xu
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
e the bulk of my
> testing
> - some cosmetic tweaks to the ESSIV template skcipher setkey function
> to align it with the aead one
> - add a test case for essiv(cbc(aes),aes,sha256)
> - add an accelerated implementation for arm64 that combines the IV
> derivation and the actua
Something else to keep mind is the potential to reuse IV generators.
Recently a patch has been proposed for fscrypt that also makes
use of essiv (search for "fscrypt: Add support for AES-128-CBC").
It would be great if we could reuse the same code for both dm-crypt
and fscrypt.
Chee
mentation of IV
> generators would be eventually needed.
Again I don't see the problem here. IV generators are supposed
to return the IV to the caller so that it can be transmitted.
For example, the IV generated in IPsec is explicitly transmitted.
Here we just need to store the IV.
Cheer
On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> Very straightforward conversion to the new function in the caam driver
> and shash library.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Herbert Xu
> Cc: "David S. Miller"
> ---
>
On Thu, Apr 27, 2017 at 09:45:57AM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 09:56 PM, Herbert Xu wrote:
> > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> >> Very straightforward conversion to the new function in the caam driver
> >> an
On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote:
>
>
> On 28/04/17 12:30 AM, Herbert Xu wrote:
> > You are right. Indeed the existing code looks buggy as they
> > don't take sg->offset into account when doing the kmap. Could
> > you send me s
EBUSY in that case is
a fatal error.
So this API can't be used without backlog.
We could introduce a flag to indicate whether we want backlog or not,
or maybe we should change our API so that in the non-backlog case we
return something other than EBUSY.
Opinions?
Thanks,
--
Email: Her
et rid of the ambiguity.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
our implementation of essiv
can also be used in that patchset. That would confirm that we're on
the right track.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
f a
hardware IV generator, just as there is no way to judge the quality
of hardware RNG without looking at its internal structure.
But that doesn't mean that we shouldn't support them if they exist.
In any case, this scenario already exists today with IPsec where
we have multiple hardware im
in the backlog to -EIOCBQUEUED, thus resolving both
> issues.
>
> Signed-off-by: Gilad Ben-Yossef
So you're changing the success case from EBUSY to EIOCBQUEUED.
This results in a lot of churn as you have to change every single
driver and caller.
How about changing the error case to us
_SIZE);
>
> or
>
> crypto_xor(keystream, src, nbytes);
> memcpy(dst, keystream, nbytes);
What keeping crypto_xor as it is and adding a new entry point for
the 4-argument case?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.ap
there are any
inadequacies, please comment.
Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
tcrypt: test 5 (384 bit key, 16 byte blocks):
> caam_jr 802.jr: key size mismatch
> tcrypt: setkey() failed flags=20
> [...]
>
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http:
error ever to the user, do the translation here.
> + */
> +static inline int crypto_user_err(int err)
> +{
> + if (err == -EAGAIN)
> + return -EBUSY;
> +
> + return err;
I don't see the need to carry along this baggage. Does anyone
in user-spac
On Sat, Oct 07, 2017 at 10:51:42AM +0300, Gilad Ben-Yossef wrote:
> On Sat, Oct 7, 2017 at 6:05 AM, Herbert Xu
> wrote:
> > On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
> >>
> >> diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
>
On Sun, Oct 15, 2017 at 10:19:45AM +0100, Gilad Ben-Yossef wrote:
>
> Changes from v8:
> - Remove the translation of EAGAIN return code to the
> previous return code of EBUSY for the user space
> interface of algif as no one seems to rely on it as
> requested by Herbert
On Tue, Oct 17, 2017 at 02:55:21PM +0300, Gilad Ben-Yossef wrote:
>
> Would you mind if we used ENOSPC instead of E2BIG?
>
> "No space left on device" seems more appropriate than
> "Argument list too long".
It's fine by me.
Thanks,
--
Email: Herbert X
ast tests the crypto users via testmgr and
> tcrypt but I do note that I do not have access to some
> of the HW whose drivers are modified nor do I claim I was
> able to test all of the corner cases.
>
> The patch set is based upon linux-next release tagged
> next-20171017.
All
GFP_NOIO.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
rypto API has the same check. This
all goes back to
commit 4f3e797ad07d52d34983354a77b365dfcd48c1b4
Author: Herbert Xu
Date: Mon Feb 9 14:22:14 2009 +1100
crypto: scatterwalk - Avoid flush_dcache_page on slab pages
It's illegal to call flush_dcache_page on slab pages on a numb
why flush_kernel_dcache_page() needs so much logic around it
> before complicating the general kernel users.
>
> I would like to see it go away if possible.
This thread may be related:
https://lwn.net/Articles/240249/
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herb
is now legal to call flush_dcache_page on slab pages we
no longer need to do the check in the Crypto API.
Reported-by: Ira Weiny
Signed-off-by: Herbert Xu
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index c837d0775474..7af08174a721 100644
--- a/include/crypto/scatte
cka
Date: Thu Jul 9 23:20:41 2020 -0700
crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY
So this should no longer be an issue with an up-to-date kernel.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.t
M situations where drivers that must allocate memory on each
request may lead to dead-lock so it's not really targeted at qat.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm
qat in stable (possibly only
when DM_CRYPT is enabled/modular). The patches in question while
good may have too wide an effect for the stable kernel series.
Giovanni, could you send Greg a Kconfig patch to do that?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PG
rk too.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
nge in the set that fixes the problem.
>
> Did this go anywhere? I'm still not seeing it in any of the stable trees.
It's in the cryptodev tree which should hit mainline when the merge
window opens.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: h
n Wang
Nack. As I said before, please do it using explicit IV generators
like we do for IPsec.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
hanks.
Of course you would do CBC in 512-byte blocks, but my point is that
you should do this in a crypto API algorithm, rather than dm-crypt
as we do now. Once you implement that then dm-crypt can treat
every algorithm as if they supported bulk processing.
Cheers,
--
Email: Her
; dm-crypt have supplied one high efficiency way. I think these are
> really top level how to use the crypro APIs, does that need to move
> into crypto laryer? Thanks.
I have already explained to you how you can piggy-back off dm-crypt's
allocation, so what's the problem?
--
Ema
newctx, len);
> + return geniv_setkey_init_ctx(&ctx->data);
> +}
I think we should be able to do without adding another API for this.
Can we instead put the information into the key and/or the IV?
Also it would really help if you could attach a patch for dm-crypt
that goes along
; procedure etc.
>
> https://lkml.org/lkml/2016/11/21/168
Sorry, I don't know how I missed that :)
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.
Thanks,
--
Email: Herbert Xu
Home P
t until it's actually
needed. In any case, if there was a need for such information we
should try to embed it into either the key (per-tfm) or the IV
(per-request) as appropriate.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~h
can only request for non-internal
algorithms.
Basically you want to check at the start of mcryptd_create_hash
that the INTERNAL bit is set on both the type and mask as returned
by crypto_get_attr_type.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http:/
er to the simd model of creating new
algorithms. So I'd like to see patch for the next merge window
that converted mcryptd and its users to something similar to what
we do in crypto/simd.c.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apan
llowed
> with mcryptd at the time mcryptd is spawning an algorithm.
>
> Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2
> Cc: sta...@vger.kernel.org
> Reported-by: Mikulas Patocka
> Signed-off-by: Tim Chen
Patch applied. Thanks.
--
Email: Her
start doing the IO. I'm not sure how big a problem that is but
if it is bad enough to affect performance, we can look into adding
some form of partial completion to the crypto API.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org
generators into the crypto API
does not mean the dm-crypt team giving up control over them. You
could continue to keep them within the dm-crypt code base and
still register them through the normal crypto API mechanism.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana
outside of dm-crypt. You can register
these IV generators from there if you really want.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
be a combination of the
key to the underlying CBC plus the set of all keys for the IV
generator itself. It should then allocate the required number of
tfms as is currently done by crypt_alloc_tfms in dm-crypt.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: ht
an feed more than one sector at a time to it.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
ramework
using IV generators similar to the ones used for IPsec.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
the for n sectors the
first n*ivsize bytes would be the IV, and the actual plaintext
or ciphertext would follow.
With such a definition you could either generate the IVs in dm-crypt
or have them generated in the IV generator.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~h
On Tue, Jan 17, 2017 at 12:20:02PM +0100, Ondrej Mosnáček wrote:
> 2017-01-13 15:29 GMT+01:00 Herbert Xu :
> > What if the driver had hardware support for generating these IVs?
> > With your scheme this cannot be supported at all.
>
> That's true... I'm starting to
everything transparently
and the IV is actually part of the cipher text for the AEAD op.
IOW it would be trivial to extend our current IPsec IV generators
to handle multiple packets as the IVs are embedded with the cipher
text.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondo
On Tue, Feb 14, 2017 at 08:21:45AM +0200, Gilad Ben-Yossef wrote:
> Fix a single letter typo in api-skcipher.rst.
>
> Signed-off-by: Gilad Ben-Yossef
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au
How about verifying digest_size in the ahash API when algorithms
are registered?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
with a request size of
I think this patch is on the wrong track. The stack requests are
only ever meant to be used for synchronous algorithms (IOW shash
algorithms) and were a quick-and-dirty fix for legacy users.
So either check SHASH_MAX_REQSIZE or just convert the users to
kmalloc or even b
_std_req
> 384 rctx
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Cc: Herbert Xu
> Cc: "David S. Miller"
> Cc: linux-cry...@vger.kernel.org
> Signed-off-by: Kees Cook
This has the same issue
On Tue, Jun 26, 2018 at 10:02:31AM -0700, Kees Cook wrote:
>
> There is no SHASH_MAX_REQSIZE?
>
> As for users of AHASH_REQUEST_ON_STACK, I see:
These users are only using the top-level ahash interface. The
underlying algorithms must all be shas.
Cheers,
--
Email: Herbert Xu
Hom
nous. In fact, if they're not then they're buggy.
Therefore it makes no sense to use the general skcipher request
size as a threshold. You should look at synchronous skcipher
algorithms only.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: ht
1 - 100 of 197 matches
Mail list logo
