On Tue, Mar 16, 2021 at 04:05:58PM -0600, Rob Herring wrote:
> On Tue, Mar 09, 2021 at 01:50:03AM +0530, Vaibhav Gupta wrote:
> > From: Peter Ujfalusi
> >
> > Add the AM64 version of sa2ul to the compatible list.
> >
> > [v_gu...@ti.com: Conditional dma-coherent requirement, clocks]
> > Signed-o
On 3/12/21 8:01 AM, Herbert Xu wrote:
On Thu, Feb 25, 2021 at 01:27:13PM -0500, Thara Gopinath wrote:
+static int
+qce_aead_async_req_handle(struct crypto_async_request *async_req)
+{
+ struct aead_request *req = aead_request_cast(async_req);
+ struct qce_aead_reqctx *rctx = aead
On 3/12/21 8:02 AM, Herbert Xu wrote:
On Thu, Mar 04, 2021 at 01:41:15PM -0500, Thara Gopinath wrote:
Yes it did. The last patch adds fallback for unsupported cases and
this will make it pass the fuzz tests.
Please include this information in the next round.
I will. Thanks!
Thanks,
This patch fixes the following checkpatch.pl warnings:
crypto/jitterentropy.c:600: WARNING: Comparisons should place the constant on
the right side of the test
crypto/jitterentropy.c:681: WARNING: Comparisons should place the constant on
the right side of the test
crypto/jitterentropy.c:772: WAR
Ahmad,
On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct caam_blob_priv *blobifier;
Who is using this pointer too?
Otherwise I'd suggest marking it static.
> module_param_named(source, trusted_key_source, charp, 0
Ahmad,
On Tue, Mar 16, 2021 at 6:24 PM Ahmad Fatoum wrote:
>
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key
On Wed, Mar 10, 2021 at 10:54:57AM +0530, Bhupesh Sharma wrote:
> Newer qcom chips support newer versions of the qce IP, so add
> new compatible strings for qcom-qce (in addition to the existing
> "qcom,crypto-v5.1").
>
> With [1], Thara tried to add the support for new compatible strings,
> but w
On Tue, Mar 09, 2021 at 01:50:03AM +0530, Vaibhav Gupta wrote:
> From: Peter Ujfalusi
>
> Add the AM64 version of sa2ul to the compatible list.
>
> [v_gu...@ti.com: Conditional dma-coherent requirement, clocks]
> Signed-off-by: Peter Ujfalusi
> Signed-off-by: Vaibhav Gupta
> ---
> .../devicet
Herbert,
if you could queue patches 1-9 in a topic branch, that would be great!
Regards,
Stefan
On 3/16/21 5:07 PM, Stefan Berger wrote:
This series of patches adds support for x509 certificates signed by a CA
that uses NIST P384, P256 or P192 keys for signing. It also adds support for
Add support for using elliptic curve keys for signing modules. It uses
a NIST P384 (secp384r1) key if the user chooses an elliptic curve key
and will have ECDSA support built into the kernel.
Note: A developer choosing an ECDSA key for signing modules has to
manually delete the signing key (rm cer
From: Saulo Alessandre
Prepare the x509 parser to accept NIST P384 certificates and add the
OID for ansip384r1, which is the identifier for NIST P384.
Summary of changes:
* crypto/asymmetric_keys/x509_cert_parser.c
- prepare x509 parser to load NIST P384
* include/linux/oid_registry.h
- ad
Add support for IMA signature verification for EC keys. Since SHA type
of hashes can be used by RSA and ECDSA signature schemes we need to
look at the key and derive from the key which signature scheme to use.
Since this can be applied to all types of keys, we change the selection
of the encoding t
From: Saulo Alessandre
Register NIST P384 as an akcipher and extend the testmgr with
NIST P384-specific test vectors.
Summary of changes:
* crypto/ecdsa.c
- add ecdsa_nist_p384_init_tfm
- register and unregister P384 tfm
* crypto/testmgr.c
- add test vector for P384 on vector of tests
*
From: Saulo Alessandre
Add the parameters for the NIST P384 curve and define a new curve ID
for it. Make the curve available in ecc_get_curve.
Summary of changes:
* crypto/ecc_curve_defs.h
- add nist_p384 params
* include/crypto/ecdh.h
- add ECC_CURVE_NIST_P384
* crypto/ecc.c
- change e
From: Saulo Alessandre
Add the math needed for NIST P384 and adapt certain functions'
parameters so that the ecc_curve is passed to vli_mmod_fast. This
allows to identify the curve by its name prefix and the appropriate
function for fast mmod calculation can be used.
Summary of changes:
* crypt
Add support for parsing the parameters of a NIST P256 or NIST P192 key.
Enable signature verification using these keys. The new module is
enabled with CONFIG_ECDSA:
Elliptic Curve Digital Signature Algorithm (NIST P192, P256 etc.)
is A NIST cryptographic standard algorithm. Only signature verif
This series of patches adds support for x509 certificates signed by a CA
that uses NIST P384, P256 or P192 keys for signing. It also adds support for
certificates where the public key is one of this type of a key. The math
for ECDSA signature verification is also added as well as the math for fast
Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, which is not the case.
Cc: David Howells
Cc: keyri...@vger.kernel.org
Signed-off-by: Stefan Berger
Reviewed-by: Tianjia Zhang
Tested-by: Tianjia Zh
Add support for parsing of x509 certificates that contain ECDSA keys,
such as NIST P256, that have been signed by a CA using any of the
current SHA hash algorithms.
Cc: David Howells
Cc: keyri...@vger.kernel.org
Signed-off-by: Stefan Berger
---
v7->v8:
- do not detect key algo using parse_OID
Add OIDs for ECDSA with SHA224/256/384/512.
Signed-off-by: Stefan Berger
Acked-by: Jarkko Sakkinen
---
include/linux/oid_registry.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index 4462ed2c18cd..b504e2f36b
On Tue, Mar 16, 2021 at 06:01:18PM +0100, Ahmad Fatoum wrote:
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> The CAAM does crypto acceleration, hardware number generation and
> has a blob mechanism for encapsulatio
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.
Its blob mechanism can AES encrypt/decrypt user data using a unique
never-disclosed device-specific key. There has been multiple
discussions on how to represent this within th
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.
The CAAM does crypto acceleration, hardware number generation and
has a blob mechanism for encapsulation/decapsulation of sensitive material.
This blob mechanism depends on a
For cases a trusted key source already sources the kernel RNG, we can
use get_random_bytes_wait to get the random data for key material.
Make the get_random callback optional to allow sources to make use of
this.
Signed-off-by: Ahmad Fatoum
---
To: James Bottomley
To: Jarkko Sakkinen
To: Mimi
The CAAM can be used to protect user-defined data across system reboot:
- When the system is fused and boots into secure state, the master
key is a unique never-disclosed device-specific key
- random key is encrypted by key derived from master key
- data is encrypted using the random key
On Tue, 16 Mar 2021 at 13:28, Thomas Backlund wrote:
>
>
> Den 16.3.2021 kl. 14:15, skrev Thomas Backlund:
> >
> > Den 16.3.2021 kl. 12:17, skrev Ard Biesheuvel:
> >> On Tue, 16 Mar 2021 at 10:21, Thomas Backlund wrote:
> >>> Den 16.3.2021 kl. 08:37, skrev Ard Biesheuvel:
> Please consider b
From: Zihao Tang
Fix the following coccicheck warning:
drivers/char/hw_random/core.c:399:8-16: WARNING: use scnprintf or sprintf.
Signed-off-by: Zihao Tang
Signed-off-by: Jay Fang
---
drivers/char/hw_random/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ch
Den 16.3.2021 kl. 14:15, skrev Thomas Backlund:
>
> Den 16.3.2021 kl. 12:17, skrev Ard Biesheuvel:
>> On Tue, 16 Mar 2021 at 10:21, Thomas Backlund wrote:
>>> Den 16.3.2021 kl. 08:37, skrev Ard Biesheuvel:
Please consider backporting commit
86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
Den 16.3.2021 kl. 12:17, skrev Ard Biesheuvel:
> On Tue, 16 Mar 2021 at 10:21, Thomas Backlund wrote:
>> Den 16.3.2021 kl. 08:37, skrev Ard Biesheuvel:
>>> Please consider backporting commit
>>>
>>> 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
>>> crypto: x86/aes-ni-xts - use direct calls to and 4-w
On Tue, 16 Mar 2021 at 10:21, Thomas Backlund wrote:
>
> Den 16.3.2021 kl. 08:37, skrev Ard Biesheuvel:
> > Please consider backporting commit
> >
> > 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
> > crypto: x86/aes-ni-xts - use direct calls to and 4-way stride
> >
> > to stable. It addresses a rather
Den 16.3.2021 kl. 08:37, skrev Ard Biesheuvel:
> Please consider backporting commit
>
> 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
> crypto: x86/aes-ni-xts - use direct calls to and 4-way stride
>
> to stable. It addresses a rather substantial retpoline-related
> performance regression in the AES-NI
31 matches
Mail list logo
