xxhash is currently implemented as a self-contained module in /lib.
This patch enables that module to be used as part of the generic kernel
crypto framework. It adds a simple wrapper to the 64bit version.
I've also added test vectors (with help from Nick Terrell). The upstream
xxhash code is teste
Am Mittwoch, 29. Mai 2019, 22:21:50 CEST schrieb Richard Weinberger:
Hi Richard,
> Stephan,
>
> - Ursprüngliche Mail -
>
> >> I've seen that it does actually work the other way around, since
> >> crypto_init_shash_ops_async() in crypto/shash.c takes care of translating
> >> calls from a
On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
>
> So what about the other places that also pass an IV located next to the data,
> like crypto/ccm.c and crypto/adiantum.c? If we're actually going to make
> this a
> new API requirement, then we need to add a debugging option that ma
On Thu, May 30, 2019 at 12:48:43AM +0200, Richard Weinberger wrote:
> Some crypto accelerators allow working with secure or hidden keys.
> This keys are not exposed to Linux nor main memory. To use them
> for a crypto operation they are referenced with a device specific id.
>
> This patch adds a n
Some crypto accelerators allow working with secure or hidden keys.
This keys are not exposed to Linux nor main memory. To use them
for a crypto operation they are referenced with a device specific id.
This patch adds a new flag, CRYPTO_TFM_REQ_REF_KEY.
If this flag is set, crypto drivers should tr
DCP allows working with secure keys. These keys can reside in a
protected memory region of the crypto accelerator, burned in
eFuses or being an internal chip key. To use these keys a key
reference is transferred to the chip instead of a AES key.
For DCP these references can be:
0x00 to 0x03: Key sl
On Wed, 29 May 2019 at 22:27, Eric Biggers wrote:
>
> On Wed, May 29, 2019 at 08:10:56PM +0300, Iuliana Prodan wrote:
> > The generic GCM driver should ensure that whatever it passes into
> > scatterlists is safe for non-cache coherent DMA.
> > The issue was seen while running GCM on CAAM driver.
On 29.05.19 г. 22:55 ч., Eric Biggers wrote:
> Hi Nikolay, some more comments from another read through. Sorry for not
> noticing these in v2.
>
> On Wed, May 29, 2019 at 06:48:26PM +0300, Nikolay Borisov wrote:
>> +static int xxhash64_update(struct shash_desc *desc, const u8 *data,
>> +
On Wed, May 29, 2019 at 08:10:56PM +0300, Iuliana Prodan wrote:
> The generic GCM driver should ensure that whatever it passes into
> scatterlists is safe for non-cache coherent DMA.
> The issue was seen while running GCM on CAAM driver. But, since CAAM
> does not support GHASH on i.MX6, only CTR s
Stephan,
- Ursprüngliche Mail -
>> I've seen that it does actually work the other way around, since
>> crypto_init_shash_ops_async() in crypto/shash.c takes care of translating
>> calls from ahash to shash and that's how the *-generic drivers are usable
>> through the ahash API.
>
> The c
Hi Nikolay, some more comments from another read through. Sorry for not
noticing these in v2.
On Wed, May 29, 2019 at 06:48:26PM +0300, Nikolay Borisov wrote:
> +static int xxhash64_update(struct shash_desc *desc, const u8 *data,
> + unsigned int length)
> +{
> + struct x
The Jitter RNG implementation is updated to comply with upstream version
2.1.2. The change covers the following aspects:
* Time variation measurement is conducted over the LFSR operation
instead of the XOR folding
* Invcation of stuck test during initialization
* Removal of the stirring function
The generic GCM driver should ensure that whatever it passes into
scatterlists is safe for non-cache coherent DMA.
The issue was seen while running GCM on CAAM driver. But, since CAAM
does not support GHASH on i.MX6, only CTR skcipher part of the GCM is
offloaded.
The skcipher request received by C
Pascal Van Leeuwen a écrit :
> Quick question regarding how to configure out code depending on a
CONFIG_xxx
> switch. As far as I understood so far, the proper way to do this is
not by
> doing an #ifdef but by using a regular if with IS_ENABLED like so:
>
> if (IS_ENABLED(CONFIG_PCI)) {
> }
>
>
xxhash is currently implemented as a self-contained module in /lib.
This patch enables that module to be used as part of the generic kernel
crypto framework. It adds a simple wrapper to the 64bit version.
I've also added test vectors (with help from Nick Terrell). The upstream
xxhash code is teste
On Wed, May 22, 2019 at 1:55 PM Eric Biggers wrote:
>
> On Wed, May 22, 2019 at 01:47:07PM -0700, Thomas Garnier wrote:
> > On Mon, May 20, 2019 at 9:06 PM Eric Biggers wrote:
> > >
> > > On Mon, May 20, 2019 at 04:19:26PM -0700, Thomas Garnier wrote:
> > > > diff --git a/arch/x86/crypto/sha256-a
Am Mittwoch, 29. Mai 2019, 16:04:47 CEST schrieb David Gstir:
Hi David,
> Hi!
>
> I've done some testing with hardware acceleration of hash functions
> and noticed that, when using the synchronous message digest API (shash),
> some drivers are not usable. In my case the CAAM driver for SHA256.
>
Hi!
I've done some testing with hardware acceleration of hash functions
and noticed that, when using the synchronous message digest API (shash),
some drivers are not usable. In my case the CAAM driver for SHA256.
Using the asynchronous interface (ahash), everything works as expected.
Looking at th
On Sat, May 25, 2019 at 5:10 AM Eric Biggers wrote:
> On Tue, May 21, 2019 at 12:00:34PM +0200, Ondrej Mosnacek wrote:
> > This patch adds new socket options to AF_ALG that allow setting key from
> > kernel keyring. For simplicity, each keyring key type (logon, user,
> > trusted, encrypted) has it
19 matches
Mail list logo
