ers ahash is the best interface.
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
ON_STACK set the CRYPTO_ALG_ASYNC flag to zero
when allocating the tfm.
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
value to use for AHASH_REQUEST_ON_STACK?
As I said to arrive at a fixed value you should examine all sync
ahash algorithms (e.g., all shash ones plus ahash ones marked as
sync if there are any).
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org
On Thu, Jul 12, 2018 at 08:33:24PM -0700, Kees Cook wrote:
> On Thu, Jul 12, 2018 at 5:40 PM, Herbert Xu
> wrote:
> > On Thu, Jul 12, 2018 at 06:02:26PM +0200, Arnd Bergmann wrote:
> >>
> >> Looking through some of the drivers, I found this interesting one:
> >
rivers are irrelevant.
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
_BIT_SIZE/8 == 128
This should be removed. We shouldn't allow generic or new crypto
algorithms in staging.
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.
ates on a single
block.
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
tfm, reqsize);
>
> What values might be expected here? It seems the entire blocksize
> needs to be included as well...
But otherwise yes these are the ones that count.
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
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: http://gondor.apa
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
_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
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 better
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 a
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 Xu <
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 Sat, Oct 07, 2017 at 10:51:42AM +0300, Gilad Ben-Yossef wrote:
> On Sat, Oct 7, 2017 at 6:05 AM, Herbert Xu <herb...@gondor.apana.org.au>
> wrote:
> > On Tue, Sep 05, 2017 at 03:38:40PM +0300, Gilad Ben-Yossef wrote:
> >>
> >> diff --git a/crypto/algif_has
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-space actually rely on EBUSY?
C
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ă <horia.gea...@nxp.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home
e are any
inadequacies, please comment.
Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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
AES_BLOCK_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 <herb...@gondor.apana.org.au>
Home Page: http://gondor.
changing the error case to use something other than
EBUSY instead?
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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
rator, 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 implementations that generat
ing to know whether your implementation of essiv
can also be used in that patchset. That would confirm that we're on
the right track.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert
d of the ambiguity.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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
s
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: Herbert Xu <herb...@gond
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 some p
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 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 <log...@deltatee.com>
> Cc: Herbert Xu <herb...@gondor.apana.org.au>
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
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 <gi...@benyossef.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.
erything 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 <herb...@gondor.apana.org.au>
Home Page: 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 <herb...@gondor.apana.org.au>:
> > What if the driver had hardware support for generating these IVs?
> > With your scheme this cannot be supported at all.
>
>
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 <herb...@gondor.apana.org.au>
Home Pa
ork
using IV generators similar to the ones used for IPsec.
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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.red
e sector at a time to it.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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
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 <herb...@gondor.apana.org.au>
Home Page: http://gon
ide of dm-crypt. You can register
these IV generators from there if you really want.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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
s 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 <herb...@gondor.apana.org.au>
Home Page: http://g
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 <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.ap
e allowed
> with mcryptd at the time mcryptd is spawning an algorithm.
>
> Link: http://marc.info/?l=linux-crypto-vger=148063683310477=2
> Cc: sta...@vger.kernel.org
> Reported-by: Mikulas Patocka <mpato...@redhat.com>
> Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com>
gorithm. This way the user would not be able
to access it at all since they 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
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 <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herb
; 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?
--
Em
e 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: Herbert Xu <herb...@gondor.apana.org.au>
<baolin.w...@linaro.org>
Nack. As I said before, please do it using explicit IV generators
like we do for IPsec.
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-de
hen the algorithm would
be called lmk(cbc(aes)) and it will take as its input one or more
sectors and for each sector it should generate an IV and operate
on it.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.
On Fri, Jun 03, 2016 at 03:10:31PM +0800, Baolin Wang wrote:
> On 3 June 2016 at 14:51, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> > On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote:
> >>
> >> If we move the IV generation into the crypto API,
coalesced then
it shouldn't have been split up in the first place. I'm nacking
the whole series.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
dm-devel mailing list
dm-devel@r
etwork stack for drivers that can't handle TSO?
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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 Mon, Apr 18, 2016 at 04:14:48PM +0800, Baolin Wang wrote:
> On 18 April 2016 at 16:04, Herbert Xu <herb...@gondor.apana.org.au> wrote:
> > On Mon, Apr 18, 2016 at 03:58:59PM +0800, Baolin Wang wrote:
> >>
> >> That depends on the hardware engine. Some cipher ha
can be merged then it should have stayed as one piece
rather than being fragmented.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
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
ypt can not get the hardware engine's attributes.
It has nothing to do with the hardware attributes. dm-crypt should
be sending maximal requests in the first place.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.
. The user always has more
information available than the underlying API. So it is totally
stupid to have the API try to extract information that the user
could have provided in the first place.
I'm not taking this patch-set.
Cheers,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home
bulk mode to help the crypto hardware drivers
> improve in efficiency.
Could you please explain why this merging can't be done in dm-crypt
instead?
Thanks,
--
Email: Herbert Xu <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au
On Sun, Jan 24, 2016 at 07:10:50PM +0100, Julia Lawall wrote:
> Maybe the goto on line 1726 needs a preceding mutex_unlock?
Good catch! Thanks.
---8<---
This patch replaces uses of ablkcipher and blkcipher with skcipher,
and the long obsolete hash interface with shash.
Signed-off-by: Herb
This patch replaces uses of the long obsolete hash interface with
ahash.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
drivers/scsi/iscsi_tcp.c| 54 ++--
drivers/scsi/iscsi_tcp.h|4 +--
drivers/scsi/libiscsi_tcp.c
This patch replaces uses of blkcipher with the new skcipher
interface.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
drivers/block/cryptoloop.c | 48 +++--
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers
This patch replaces uses of the long obsolete hash interface with
either shash (for non-SG users) or ahash.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
drivers/target/iscsi/iscsi_target.c | 86 ++
drivers/target/iscsi/iscsi_target_auth.c
The interfaces blkcipher and hash are obsolete. This patch replaces
them with skcipher and ahash respectively.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
drivers/staging/rtl8192e/rtllib_crypt_tkip.c | 99 ++-
drivers/staging/rt
This patch replaces uses of ablkcipher with skcipher.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
fs/ext4/crypto.c | 24 +++-
fs/ext4/crypto_fname.c | 32 +++-
fs/ext4/crypto_key.c
This patch replaces uses of the long obsolete hash interface with
ahash.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
include/net/tcp.h |6 +-
net/ipv4/tcp.c | 41 ++---
net/ipv4/tcp_fastopen.c |1 +
ne
This patch replaces uses of the long obsolete hash interface with
shash.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
drivers/nfc/s3fwrn5/firmware.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/nfc/s
This patch replaces uses of blkcipher with skcipher.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
security/keys/encrypted-keys/encrypted.c | 82 ++-
1 file changed, 50 insertions(+), 32 deletions(-)
diff --git a/security/keys/encrypte
This patch replaces uses of blkcipher with skcipher and the long
obsolete hash interface with shash.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
net/bluetooth/smp.c | 135
1 file changed, 63 insertions(+), 72 del
This patch replaces uses of blkcipher with skcipher.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
net/rxrpc/ar-internal.h |2
net/rxrpc/ar-key.c | 12 +--
net/rxrpc/rxkad.c | 172 +---
3 files change
This patch replaces uses of blkcipher with skcipher.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
net/ceph/crypto.c | 97 +++---
1 file changed, 56 insertions(+), 41 deletions(-)
diff --git a/net/ceph/crypto.c b/ne
This patch replaces uses of ablkcipher with skcipher.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
fs/f2fs/crypto.c | 24 +++-
fs/f2fs/crypto_fname.c | 32 +++-
fs/f2fs/crypto_key.c
This patch replaces uses of blkcipher with skcipher and the long
obsolete hash interface with ahash.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
net/wireless/lib80211_crypt_tkip.c | 99 -
net/wireless/lib80211_crypt_wep.c
This patch replaces uses of blkcipher with skcipher.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
drivers/usb/wusbcore/crypto.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/wusbcore/crypto.c b/drive
.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
net/xfrm/xfrm_algo.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index f07224d..250e567 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@
This patch replaces uses of the long obsolete hash interface with
shash.
Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au>
---
fs/nfsd/nfs4recover.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/fs/nfsd/nfs4recover.c b/f
101 - 171 of 171 matches
Mail list logo
