Hmm, fair, I hadn't considered the desire to pre-cache keys with the
rest, in which case I suppose the existing API is likely about as good
as you'd need (+/- duplicative extra tfm overhead, which annoys me, but
likely isn't actually worth worrying about). I'll retract my criticism
until I've writt
On Fri, Jul 28, 2017 at 4:00 PM, Matt Corallo wrote:
>
> Even worse, when I'm looking at tcpcrypt, not adding undue complication,
> or, really, overhead, is a pretty important goal for something in the
> tcp stack (especially for someone who doesn't know the TCP stack, and
> avoiding complexity is
Yea, and while I understand this API is very useful for hardware
accelerated (and, more often, secured) crypto and generally being very
neatly pluggable, its, IMO, significantly less useful for many key
agreement uses-cases.
At least in the ever-more-used pattern of doing temporary key agreement
f
On Fri, Jul 28, 2017 at 09:52:57PM +0800, Herbert Xu wrote:
> On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote:
> > On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote:
> > > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote:
> > > >
> > > > Since there are two dif
On Fri, Jul 28, 2017 at 03:53:55PM +0200, Stephan Müller wrote:
>
> I would add the common service code to crypto/af_alg.c or do you prefer a
> separate or different file?
af_alg.c is OK.
> As the copy-AAD patch is also outstanding, in which order would you like to
> receive the patches (first
On Mon, Jul 17, 2017 at 03:16:02PM -0500, Gary R Hook wrote:
> This series accomplishes the following:
>
> - Fix RSA support in the base CCP driver
> - Add the akcipher_set_reqsize() function
> - Enable RSA support in the crypto layer
> - Allow for a larger RSA modulus in a version 5 CCP
>
>
Am Freitag, 28. Juli 2017, 15:49:36 CEST schrieb Herbert Xu:
Hi Herbert,
> All patches applied. Yes please post follow-up patches to clean
> up as necessary.
Thank you. I will do that asap.
I would add the common service code to crypto/af_alg.c or do you prefer a
separate or different file?
On Mon, Jul 17, 2017 at 03:00:49PM -0500, Gary R Hook wrote:
> Some updates this year have not had copyright dates changed in modified
> files. Correct this for 2017.
>
> Signed-off-by: Gary R Hook
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP
On Sun, Jul 16, 2017 at 07:22:06PM +0200, Jason A. Donenfeld wrote:
> Otherwise, we might be seeding the RNG using bad randomness, which is
> dangerous. The one use of this function from within the kernel -- not
> from userspace -- is being removed (keys/big_key), so that call site
> isn't relevant
On Fri, Jul 14, 2017 at 01:15:36PM +0200, Corentin Labbe wrote:
> On Fri, Jun 23, 2017 at 02:48:37PM +0800, Herbert Xu wrote:
> > On Mon, Jun 19, 2017 at 09:55:24AM +0200, Corentin Labbe wrote:
> > >
> > > Since there are two different user of "crypto engine + ablkcipher", it
> > > will be not eas
On Sun, Jun 25, 2017 at 05:12:13PM +0200, Stephan Müller wrote:
> Hi Herbert,
>
> Changes v11:
> - algif_skcipher: remove len < ctx->used in recvmsg as requested by Herbert
> and verified by the latest test code in libkcapi.
> - algif_skcipher/algif_aead: simplify _recvmsg error code path
>
> W
On Thu, Jul 13, 2017 at 03:32:25PM +0200, Lionel Debieve wrote:
> This set of patches adds a new crypto driver for STMicroelectronics stm32 HW.
> This drivers uses the crypto API and provides with HW-enabled md5, sha1,
> sha224, sha256 hash based algorithms.
> It makes use of the crypto engine to s
On Thu, Jul 13, 2017 at 05:21:01AM -0400, Xulin Sun wrote:
> kill_fq removes a complete frame queue, it needs to free the qman_fq
> in the last. Else kmemleak will report the below warning:
>
> unreferenced object 0x800073085c80 (size 128):
> comm "cryptomgr_test", pid 199, jiffies 429493785
On Thu, Jul 13, 2017 at 03:06:30PM +0200, Lionel Debieve wrote:
> This set of patches update the STM32 CRC driver.
> It contains two corrections and one global Kconfig rework.
> First correction is about the relaxed usage in scope of arm
> platform usage, second about a unbind driver issue.
> Last
Hi Thiago,
On Thu, 2017-07-06 at 19:17 -0300, Thiago Jung Bauermann wrote:
> Even though struct evm_ima_xattr_data includes a fixed-size array to hold a
> SHA1 digest, most of the code ignores the array and uses the struct to mean
> "type indicator followed by data of unspecified size" and tracks
Mogens Lauridsen wrote:
> Hi,
>
> The direction used in dma_unmap_sg in aes calc in sahara.c is wrong.
> This result in the cache not being invalidated correct when aes
> calculation is done and result is dma'ed to memory.
> This is seen as sporadic wrong result from aes calc.
>
> Thanks,
> Moge
On Wed, Jul 26, 2017 at 01:07:34AM +0100, Ard Biesheuvel wrote:
>
> > On 26 Jul 2017, at 00:36, Giovanni Cabiddu
> > wrote:
> >
> > Hi Ard,
> >
> >> On Fri, Jul 21, 2017 at 04:42:38PM +0100, Ard Biesheuvel wrote:
> >> +static int crypto_scomp_init_tfm(struct crypto_tfm *tfm)
> >> +{
> >> +
On Fri, Jul 28, 2017 at 06:46:03AM +, Horia Geantă wrote:
>
> If I am to add a new driver, would it be possible and/or advisable to
> use skcipher?
It should be OK. Let me know if you have any issues with the API.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
Hi Linus:
This push fixes the following issues:
- Remove broken dt bindings in inside-secure.
- Fix authencesn crash when used with digest_null.
- Fix cavium/nitrox firmware path.
- Fix SHA3 failure in brcm.
- Fix Kconfig dependency for brcm.
Please pull from
git://git.kernel.org/pub/scm/linu
On Fri, Jul 28, 2017 at 09:59:41AM +0530, Suniel Mahesh wrote:
> On Friday 28 July 2017 01:18 AM, Dan Carpenter wrote:
> > On Thu, Jul 27, 2017 at 05:27:33PM +0300, Gilad Ben-Yossef wrote:
> >> + new_drvdata->cc_base = devm_ioremap_resource(&plat_dev->dev,
> >> +
Hi, Marcel, Kyle,
On 07/17/2017 09:17 PM, Marcel Holtmann wrote:
Hi Kyle,
I am confused about several things in the new key agreement code.
net/bluetooth/smp.c in two places generates random bytes for the
private_key argument to
net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests t
21 matches
Mail list logo