Re: [PATCH] X.509: unpack RSA signatureValue field from BIT STRING

Maciej S. Szmigiero wrote: > + if (!strcmp(ctx->cert->sig->pkey_algo, "rsa")) { I'm going to change this to '== 0' rather than '!'. David

[RFC PATCH] KEYS: Use individual pages in big_key for crypto buffers [ver #3]

use a monolithic buffer unless the kernel itself wants to access the data. Fixes: 13100a72f40f ("Security: Keys: Big keys stored encrypted") Reported-by: Paul Bunyan <pbun...@redhat.com> Signed-off-by: David Howells <dhowe...@redhat.com> cc: Kirill Mari

Re: [RFC PATCH] KEYS: Use individual pages in big_key for crypto buffers [ver #2]

Eric Biggers wrote: > memset() after vunmap(), and also when buf->virt can be NULL? I had > suggested: > > if (buf->virt) { > memset(buf->virt, 0, buf->nr_pages * PAGE_SIZE); > vunmap(buf->virt); > } Sorry, yes. I don't

[RFC PATCH] KEYS: Use individual pages in big_key for crypto buffers [ver #2]

use a monolithic buffer unless the kernel itself wants to access the data. Fixes: 13100a72f40f ("Security: Keys: Big keys stored encrypted") Reported-by: Paul Bunyan <pbun...@redhat.com> Signed-off-by: David Howells <dhowe...@redhat.com> cc: Kirill Mari

Re: [RFC PATCH] KEYS: Use individual pages in big_key for crypto buffers

Eric Biggers wrote: > If big_key_alloc_buffer() fails to allocate one of the pages then some of > the pages may still be NULL here, causing __free_page() to crash. You need > to check for NULL first. Ah, yes. I incorrectly used free_page() first - and that does check for

[RFC PATCH] KEYS: Use individual pages in big_key for crypto buffers

use a monolithic buffer unless the kernel itself wants to access the data. Fixes: 13100a72f40f ("Security: Keys: Big keys stored encrypted") Reported-by: Paul Bunyan <pbun...@redhat.com> Signed-off-by: David Howells <dhowe...@redhat.com> cc: Kirill Mari

Re: [PATCH 8/9] X.509: remove dead code that set ->unsupported_sig

Eric Biggers wrote: > The X.509 parser is guaranteed to set cert->sig->pkey_algo and > cert->sig->hash_algo, since x509_note_pkey_algo() is a mandatory action > in the X.509 ASN.1 grammar, and it returns an error code if an > unrecognized AlgorithmIdentifier is given rather

Re: [PATCH 6/9] PKCS#7: remove unnecessary check for NULL sinfo->sig->hash_algo

Eric Biggers wrote: > The PKCS#7 parser is guaranteed to set ->sig->hash_algo for every > SignerInfo, since pkcs7_sig_note_digest_algo() is a mandatory action in > the PKCS#7 ASN.1 grammar, and it returns an error code if an > unrecognized DigestAlgorithmIdentifier is given

Re: [PATCH 4/9] X.509: fix BUG_ON() when hash algorithm is unsupported

Eric Biggers wrote: > The X.509 parser mishandles the case where the certificate's signature's > hash algorithm is not available in the crypto API. In this case, > x509_get_sig_params() doesn't allocate the cert->sig->digest buffer; this > part seems to be intentional.

Re: [PATCH 0/9] PKCS#7 / X.509 fixes and cleanups

I presume you don't have this in a git tree somewhere that I can pull? David

Re: kernel failure while loading X.509 certificate

If this happened during boot, it could be that you have an X.509 cert for which the digest algorithm isn't built into the kernel. David

Re: [PATCH] KEYS: reject NULL restriction string when type is specified

Mat Martineau wrote: > Since this fixes the bug for the asymmetric key type and ensures that other > key types won't make the same mistake, I agree this is the way to fix it. I > did not find any issues in the patch. Can I put that down as a Reviewed-by?

Re: [PATCH] X.509: fix printing uninitialized stack memory when OID is empty

I wonder if all -EBADMSG returns here should just print "(badoid)" into the buffer. David

Re: [PATCH] X.509: fix comparisons of ->pkey_algo

Eric Biggers wrote: > if (strcmp(x509->pub->pkey_algo, sinfo->sig->pkey_algo)) Can you make this strcmp(...) != 0? I know it may seem picky, but checking strcmp() in this way kind of inverts the true/false thing. Thanks, David

Re: [PATCH] crypto: rsa - fix buffer overread when stripping leading zeroes

Eric Biggers <ebigge...@gmail.com> wrote: > In rsa_get_n(), if the buffer contained all 0's and "FIPS mode" is > enabled, we would read one byte past the end of the buffer while > scanning the leading zeroes. Fix it by checking 'n_sz' before '!*ptr'. Reviewed

Re: [PATCH] crypto: rsa - fix buffer overread when stripping leading zeroes

Hi Herbert, Are you going to take this? David

Re: [PATCH v2] lib/mpi: call cond_resched() from mpi_powm() loop

Eric Biggers wrote: > This probably should be grouped with my series "crypto: dh - input validation > fixes", as this is also a fix for Diffie-Hellman. I was actually expecting > Herbert Xu to take these patches, as Diffie-Hellman is now part of the crypto > API

Re: [PATCH v2] lib/mpi: call cond_resched() from mpi_powm() loop

Eric Biggers wrote: > On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the > largest permitted inputs (16384 bits), the kernel spends 10+ seconds > doing modular exponentiation in mpi_powm() without rescheduling. If all > threads do it, it locks up the

Re: general protection fault in asn1_ber_decoder

Eric Biggers wrote: > Hi David, you just beat me to it, but I don't think this is the best way to > fix the problem. The length check just needs to be rewritten to not > overflow. Also it seems there is another broken length check later in the > function. How about this:

Re: general protection fault in asn1_ber_decoder

70620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is attached. See https://goo.gl/kgGztJ > for information about syzkaller reproducers Does the attached patch fix it for you? David --- commit 41f31a32d918a97dba2ec589d24b5252

Re: [PATCH 1/3] crypto: dh_helper - return unsigned int for dh_data_size()

Tudor Ambarus wrote: > -static inline int dh_data_size(const struct dh *p) > +static inline unsigned int dh_data_size(const struct dh *p) > { > return p->key_size + p->p_size + p->g_size; > } If this is a problem, do you need to do range checking? David

[GIT PULL] KEYS: Fixes and crypto fixes

Hi James, Can you pull these and pass them on to Linus. There are two sets of patches here: (1) A bunch of core keyrings bug fixes from Eric Biggers. (2) Fixing big_key to use safe crypto from Jason A. Donenfeld. There are more patches to come from Eric, but I haven't reviewed at them yet,

Re: [PATCH v2] X.509: Fix error code in x509_cert_parse()

Herbert Xu wrote: > Patch applied. Thanks. Note that I've passed this on to James to pass on to Linus along with a bunch of other patches. David

Re: [PATCH v3 05/13] security/keys: ensure RNG is seeded before use

Jason A. Donenfeld wrote: > + key->serial = get_random_u32() >> 1; If this may sleep, it must be interruptible. David

Re: [PATCH v2 10/11] crypto: KEYS: check err on akcipher maxsize

Tudor Ambarus <tudor.amba...@microchip.com> wrote: > crypto_akcipher_maxsize() returns minimum length for output buffer > or error code if key hasn't been set. > > Signed-off-by: Tudor Ambarus <tudor.amba...@microchip.com> Reviewed-by: David Howells <dhowe...@redhat.com>

Re: [PATCH] X.509: Fix error code in x509_cert_parse()

Dan Carpenter wrote: > cert->pub->key = kmemdup(ctx->key, ctx->key_size, GFP_KERNEL); > - if (!cert->pub->key) > + if (!cert->pub->key) { > + ret = -ENOMEM; > goto error_decode; > + } Put the "ret = -ENOMEM" line before the

Re: [PATCH 0/5] KEYS: fixes for new keyctl_dh_compute() KDF extension

Stephan, Eric Biggers wrote: > This patch series fixes several bugs in the KDF extension to > keyctl_dh_compute() currently sitting in keys-next: a way userspace could > cause an infinite loop, two ways userspace could cause the use of > uninitialized memory, a

Re: [PATCH 3/5] KEYS: DH: don't feed uninitialized result memory into KDF

Eric Biggers wrote: > > > By the way: do we really need this in the kernel at all, given that it's > > > just doing some math on data which userspace has access to? > > > > It is the question about how we want the keys subsystem to operate. The DH > > shared secret shall

Re: [PATCH 5/6] MODSIGN: Export module signature definitions.

Mimi Zohar wrote: > On Tue, 2017-04-18 at 17:17 -0300, Thiago Jung Bauermann wrote: > > IMA will use the module_signature format for append signatures, so export > > the relevant definitions and factor out the code which verifies that the > > appended signature trailer

Re: [PATCH v6] DH support: add KDF handling support

Pulled.

Re: [PATCH v5] KEYS: add SP800-56A KDF support for DH

Pulled.

Re: [PATCH v5] DH support: add KDF handling support

Stephan Mueller wrote: > this patch changes the documentation, the naming of the variables > and the test case to refer to the variable name of a hashname > instead of kdfname to match the current kernel implementation. It's also needs an update to man1/keyctl.1. David

Re: [PATCH v5] DH support: add KDF handling support

Stephan Mueller wrote: > + struct keyctl_dh_params params = { .private = private, That doesn't compile. I think you meant ".priv". David

Re: [PATCH -next] crypto: asymmetric_keys - Fix error return code on failure

Wei Yongjun wrote: > --- a/crypto/asymmetric_keys/public_key.c > +++ b/crypto/asymmetric_keys/public_key.c > @@ -184,8 +184,10 @@ static int software_key_eds_op(struct kernel_pkey_params > *params, > return PTR_ERR(tfm); > > req =

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > David, are these encrypted keys ever exported anywhere? If not, could > the code use a mode that doesn't need padding? ecryptfs uses them, I think. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a

Re: [PATCH v2] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > > - sg_set_buf(_out[1], pad, sizeof pad); > > + sg_set_buf(_out[1], empty_zero_page, 16); > > My fix here is obviously bogus (I meant to use ZERO_PAGE(0)), but what > exactly is the code trying to do? The old code makes no sense. It's

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > I don't know whether you're right, but that sounds a bit silly to me. > This is a *tiny* amount of memory. Assuming a 1MiB kernel image in 4K pages, that gets you back a couple of pages I think - useful if you've only got a few MiB of RAM. David --

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > After all, rodata is ordinary memory, is backed by struct page, etc. Is that actually true? I thought some arches excluded the kernel image from the page struct array to make the array consume less memory. David -- To unsubscribe from this list:

[PATCH 2/2] sign-file: Fix inplace signing when src and dst names are both specified

while ((n = BIO_read(bm, buf, sizeof(buf))), n > 0) { ERR(BIO_write(bd, buf, n) < 0, "%s", dest_name); } ... Signed-off-by: Alex Yashchenko <alexhoppus...@gmail.com> Signed-off-by: David Howells <dhowe...@redhat.com> ---

[PATCH 1/2] crypto: asymmetric_keys: set error code on failure

el.org/show_bug.cgi?id=188891 Signed-off-by: Pan Bian <bianpan2...@163.com> Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/public_key.c |1 + 1 file changed, 1 insertion(+) diff --git a/crypto/asymmetric_keys/public_key.c b/crypto/asymmetric_keys/

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

Andy Lutomirski wrote: > +static const char zero_pad[16] = {0}; Isn't there a global page of zeros or something that we can share? Also, you shouldn't explicitly initialise it so that it stays in .bss. > - sg_set_buf(_out[1], pad, sizeof pad); > + sg_set_buf(_out[1],

Re: [PATCH 1/1] crypto: asymmetric_keys: set error code on failure

Pan Bian wrote: > outlen = crypto_akcipher_maxsize(tfm); > output = kmalloc(outlen, GFP_KERNEL); > - if (!output) > + if (!output) { > + ret = -ENOMEM; > goto error_free_req; > + } This is preferred: + ret =

[PATCH 0/2] KEYS: Fixes [ver #3]

Hi James, Can you pull these patches please and pass them on to Linus? They include the following: (1) Fix mpi_powm()'s handling of a number with a zero exponent [CVE-2016-8650]. (2) Fix double free in X.509 error handling. Ver #3: - Integrate my and Andrey's patches for mpi_powm() and

[PATCH 2/2] mpi: Fix NULL ptr dereference in mpi_powm() [ver #3]

it;a=patch;h=6e1adb05d290aeeb1c230c763970695f4a538526 Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Signed-off-by: David Howells <dhowe...@redhat.com> cc: Dmitry Kasatkin <dmitry

[PATCH 1/2] X.509: Fix double free in x509_cert_parse() [ver #3]

+0x260/0x5f0 [] SyS_add_key+0x199/0x2a0 [] entry_SYSCALL_64_fastpath+0x1e/0xad Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api") Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> Cc: <sta...@vger.kernel.org> Signed-off-by:

How best to {en,de}crypt between sk_buff and iov_iter?

Is there a good way to encrypt data held in an iov_iter directly into an sk_buff and decrypt data held in an sk_buff back into an iov_iter? What I would like to avoid is: (a) Invoking skb_cow_data() to potentially take an unnecessary copy of the data I shouldn't need to change, but I need

Re: [PATCH] DH support: add KDF handling support

Mat Martineau wrote: > > Though, shall I stuff the wrapper code back into the existing dh_compute > > functions or can I leave them as separate functions? > > I'm not sure. In the existing code there's one keyctl wrapper per keyctl > command. A combined

[PATCH 3/3] KEYS: Fix for erroneous trust of incorrectly signed X.509 certs

pted). Reported-by: Petko Manolov <pet...@mip-labs.com> Signed-off-by: Mat Martineau <mathew.j.martin...@linux.intel.com> Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/restrict.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cr

[PATCH 1/3] PKCS#7: Fix panic when referring to the empty AKID when DEBUG defined

56 02 e8 d0 91 d6 ff 4d 8b 3c 24 4d 85 ff 0f [ 459.060535] RIP [] pkcs7_verify+0x72c/0x7f0 [ 459.063040] RSP [ 459.065456] CR2: [ 459.075998] ---[ end trace c15f0e897cda28dc ]--- Signed-off-by: Lans Zhang <jia.zh...@windriver.com> Signed-off-by: David Howells <dh

[PATCH 2/3] pefile: Fix the failure of calculation for digest

access to internal content) Signed-off-by: Lans Zhang <jia.zh...@windriver.com> Tested-by: Dave Young <dyo...@redhat.com> Signed-off-by: David Howells <dhowe...@redhat.com> Cc: Baoquan He <b...@redhat.com> Cc: Vivek Goyal <vgo...@redhat.com> cc: ke...@lists.infradead.

[PATCH 0/3] KEYS: Miscellaneous fixes

Hi James, Here are three miscellaneous fixes: (1) Fix a panic in some debugging code in PKCS#7. This can only happen by explicitly inserting a #define DEBUG into the code. (2) Fix the calculation of the digest length in the PE file parser. This causes a failure where there should

Re: [V2][PATCH 1/2] PKCS#7: Fix kernel panic when referring to the empty AuthorityKeyIdentifier

Lans Zhang wrote: > Let me know if I need to add this comment to commit header. I've done that. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [V2][PATCH 1/2] PKCS#7: Fix kernel panic when referring to the empty AuthorityKeyIdentifier

Lans Zhang wrote: > This fix resolves the following kernel panic if the empty > AuthorityKeyIdentifier employed. It should be noted that this is only an issue if DEBUG is #defined at the top of pkcs7_verify.c as the crash happens in a pr_debug() statement. David -- To

Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]

Herbert Xu wrote: > > The problem is that if I'm to produce consistency with, say, the TPM > > interface, then I have to deal in wrapped/padded data - leastways as far > > as I can tell from reading the docs. > > So the TPM device is accessed through the same

Re: [PATCH 5/8] KEYS: Provide software public key query function [ver #2]

Herbert Xu wrote: > IOW exporting the raw RSA might make sense because the key may > not be visible to user-space, or that the RSA might be implemented > in hardware offload, but there is no sane reason to export pkcs1pad. The problem is that if I'm to produce

[PATCH 5/8] KEYS: Provide software public key query function [ver #2]

Provide a query function for the software public key implementation. This permits information about such a key to be obtained using query_asymmetric_key() or KEYCTL_PKEY_QUERY. Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/public_key.c

[PATCH 4/8] KEYS: Make the X.509 and PKCS7 parsers supply the sig encoding type [ver #2]

Make the X.509 and PKCS7 parsers fill in the signature encoding type field recently added to the public_key_signature struct. Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/pkcs7_parser.c |1 + crypto/asymmetric_keys/x509_cert_parser.c

[PATCH 0/8] KEYS: keyctl operations for asymmetric keys [ver #2]

=pkey David --- David Howells (8): KEYS: Provide key type operations for asymmetric key ops KEYS: Provide keyctls to drive the new key type ops for asymmetric keys KEYS: Provide missing asymmetric key subops for new key type ops KEYS: Make the X.509 and PKCS7 parsers supply the sig e

[PATCH 3/8] KEYS: Provide missing asymmetric key subops for new key type ops [ver #2]

kernel_pkey_params *params, const void *data, void *enc); The public_key_signature struct gains an encoding field to carry the encoding for verify_signature(). Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/crypto/asymmetric-keys.txt

[PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]

. Verification returns 0 on success. Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/security/keys.txt | 111 + include/uapi/linux/keyctl.h | 25 +++ security/keys/Makefile |1 security/keys/compat.c | 18 ++ security/keys/inte

[PATCH 6/8] KEYS: Allow the public_key struct to hold a private key [ver #2]

then need to select the appropriate crypto function to set the key. Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/public_key.c | 14 -- include/crypto/public_key.h |1 + 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/

[PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver #2]

DER | \ keyctl padd asymmetric foo @s Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/crypto/asymmetric-keys.txt |2 crypto/asymmetric_keys/Kconfig | 10 ++ crypto/asymmetric_keys/Makefile | 13 ++ crypto/asymmetric_keys/pkcs

[PATCH 7/8] KEYS: Implement encrypt, decrypt and sign for software asymmetric key [ver #2]

t;/tmp/dec # cmp data /tmp/dec # keyctl pkey_sign $j 0 data enc=pkcs1 hash=sha1 >/tmp/sig # keyctl pkey_verify $j 0 data /tmp/sig enc=pkcs1 hash=sha1 # Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/publ

[PATCH 0/8] KEYS: keyctl operations for asymmetric keys

=pkey David --- David Howells (8): KEYS: Provide key type operations for asymmetric key ops KEYS: Provide keyctls to drive the new key type ops for asymmetric keys KEYS: Provide missing asymmetric key subops for new key type ops KEYS: Make the X.509 and PKCS7 parsers supply the sig e

Re: KEYS: Use skcipher for big keys

to push it > through cryptodev so I can carry on with the removal of blkcipher. As long as it only touches the big_key code inside keyrings, I think that's fine. Acked-by: David Howells <dhowe...@redhat.com> -- To unsubscribe from this list: send the line "unsubscribe linux-crypto&

Re: [PATCH] KEYS: Add placeholder for KDF usage with DH

Hi James, > Could you pass this along to Linus as soon as possible, please? This > alters a new keyctl function added in the current merge window to allow for > a future extension planned for the next merge window. Is this likely to go to Linus before -rc2? If not, we'll need to do things

[PATCH] KEYS: Add placeholder for KDF usage with DH

ed-off-by: Mat Martineau <mathew.j.martin...@linux.intel.com> Signed-off-by: Stephan Mueller <smuel...@chronox.de> Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/security/keys.txt |5 - security/keys/compat.c |2 +- security/keys/

Re: [PATCH] KEYS: Add optional key derivation parameters for DH

Mat Martineau wrote: > +struct keyctl_kdf_params { > + char *name; > + __u8 reserved[32]; /* Reserved for future use, must be 0 */ > +}; > + > #endif /* _LINUX_KEYCTL_H */ > diff --git a/security/keys/compat.c b/security/keys/compat.c > index

Re: key retention service: DH support

Mat Martineau wrote: > Since the KDF patches are not yet merged, I'm not sure of the best way to > accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by > adding a 5th arg, an optional pointer to KDF configuration (NAME and > LABEL). If we

Re: key retention service: DH support

Stephan Mueller wrote: > With the new DH support for the key retention service, support for DH derived > keys pops up. > > The implementation in security/keys/dh.c returns the DH shared secret > straight > to the user space caller. > > I implemented a KDF with that

Re: [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver 3]

Mat Martineau wrote: > > # PKCS#7 message handling > > Update to PKCS#8 I guess I've typed PKCS#7 too many times :-) David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More

Re: [RFC PATCH 5/8] KEYS: Provide software public key query function [ver 3]

Mat Martineau wrote: > > + len = crypto_akcipher_maxsize(tfm); > > + info->key_size = len * 8; > > + info->max_data_size = len; > > + info->max_sig_size = len; > > + info->max_enc_size = len; > > + info->max_dec_size = len; > > If len >

Re: [PATCH RESEND v5 0/6] crypto: algif - add akcipher

Tadeusz Struk wrote: > This is the same v5 version as before rebased on top of > http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl I've just reposted this. The interface you're using should be the same, I think, but the details

[RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver 3]

. Verification returns 0 on success. Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/security/keys.txt | 111 + include/uapi/linux/keyctl.h | 26 +++ security/keys/Makefile |1 security/keys/compat.c | 15 ++ security/keys/inte

[RFC PATCH 4/8] KEYS: Make the X.509 and PKCS7 parsers supply the sig encoding type [ver 3]

Make the X.509 and PKCS7 parsers fill in the signature encoding type field recently added to the public_key_signature struct. Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/pkcs7_parser.c |1 + crypto/asymmetric_keys/x509_cert_parser.c

[RFC PATCH 1/8] KEYS: Provide key type operations for asymmetric key ops [ver 3]

the data and the signature instead and get an error value (or 0) as the only result on the expectation that this may well be how a hardware crypto device may work. Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/security/keys.txt

[RFC PATCH 3/8] KEYS: Provide missing asymmetric key subops for new key type ops [ver 3]

that can be used to pass a pointer to a logon key carrying a password to unlock the key. Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/crypto/asymmetric-keys.txt | 31 +++- crypto/asymmetric_keys/asymmetric_keys.h |3 + crypto/asymmetric_keys/asymmetric_type.c

[RFC PATCH 5/8] KEYS: Provide software public key query function [ver 3]

Provide a query function for the software public key implementation. This permits information about such a key to be obtained using query_asymmetric_key() or KEYCTL_PKEY_QUERY. Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/public_key.c

[RFC PATCH 6/8] KEYS: Allow the public_key struct to hold a private key [ver 3]

then need to select the appropriate crypto function to set the key. Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/public_key.c | 14 -- include/crypto/public_key.h |1 + 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/

[RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver 3]

DER | \ keyctl padd asymmetric foo @s Signed-off-by: David Howells <dhowe...@redhat.com> --- Documentation/crypto/asymmetric-keys.txt |2 crypto/asymmetric_keys/Kconfig | 10 ++ crypto/asymmetric_keys/Makefile | 13 ++ crypto/asymmetric_keys/pkcs

[RFC PATCH 7/8] KEYS: Implement encrypt, decrypt and sign for software asymmetric key [ver 3]

t;/tmp/dec # cmp data /tmp/dec # keyctl pkey_sign $j 0 data enc=pkcs1 hash=sha1 >/tmp/sig # keyctl pkey_verify $j 0 data /tmp/sig enc=pkcs1 hash=sha1 # Signed-off-by: David Howells <dhowe...@redhat.com> --- crypto/asymmetric_keys/publ

[RFC PATCH 0/8] KEYS: keyctl operations for asymmetric keys [ver 3]

anges needed can be found here: http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/log/?h=pkey David --- David Howells (8): KEYS: Provide key type operations for asymmetric key ops KEYS: Provide keyctls to drive the new key type ops for asymmetric keys K

Re: RSA/MPI handling issues and keyctl access to public key keyrings

Tadeusz Struk wrote: > > (2) rsa-pkcs1pad needs to indicate what the maximum content size is, given > > the minimum possible padding for the specified hash type (ie. a > > particular OID). > > The user needs to use crypto_akcipher_maxsize(tfm) to get the

Re: [PATCH] lib: asn1_decoder - add MODULE_LICENSE("GPL")

Tudor Ambarus wrote: > A kernel taint results when loading the rsa_generic module: > > root@(none):~# modprobe rsa_generic > asn1_decoder: module license 'unspecified' taints kernel. > Disabling lock debugging due to kernel taint > > "Tainting" of the kernel is

Re: [RFC PATCH 2/5] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys

I've pushed a fix to #include in keyctl_pkey.c into the git tree. David -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Tadeusz Struk wrote: > I think the problem is that pkcs1pad template needs CRYPTO_MANAGER, but > your configuration doesn't enable CRYPTO_MANAGER. Could you try this > please: > > diff --git a/crypto/Kconfig b/crypto/Kconfig > index 93a1fdc..1d33beb 100644 > ---

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

(cc'ing Tadeusz as he did the pkcs1 padding function) Jamie Heilman wrote: > > > Problem loading in-kernel X.509 certificate (-2) > > > > ENOENT? Hmmm... The only place that is generated is in the crypto layer. > > That suggests missing crypto of some sort. > >

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

> Problem loading in-kernel X.509 certificate (-2) ENOENT? Hmmm... The only place that is generated is in the crypto layer. That suggests missing crypto of some sort. The attached patch enables some debugging in some relevant files if you can try applying it to your kernel. David --- diff

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Jamie Heilman wrote: > I usually build my kernels to require module signatures and use > automatic signing. As of v4.6-rc1 I'm getting this on boot: > > Problem loading in-kernel X.509 certificate (-2) > > I bisected that to commit

[RFC PATCH] KEYS: Provide keyctls to do public key operations [ver #2]

Here's v2 of the patch with the reported errors fixed. It's still untested by me, however. David --- KEYS: Provide keyctls to do public key operations From: David Howells <dhowe...@redhat.com> Provide keyctl functions to do public key operations (sign, verify, encrypt and d

Re: [RFC PATCH] KEYS: Provide keyctls to do public key operations

Mat Martineau wrote: > > The interface for the active ops is a bit clunky as the syscall interface > > doesn't provide sufficient argument space to pass everything I need to > > specify. Some basic integer arguments are specified in a struct and more > >

Re: [RFC PATCH] KEYS: Provide keyctls to do public key operations

Tadeusz Struk wrote: > > --- a/crypto/asymmetric_keys/signature.c > > +++ b/crypto/asymmetric_keys/signature.c > > Since this file implements the enc/dec operations also > should it be renamed to crypto/asymmetric_keys/public_key_ops.c > or something similar?

[RFC PATCH] KEYS: Provide keyctls to do public key operations

-off-by: David Howells <dhowe...@redhat.com> --- Documentation/security/keys.txt | 105 + crypto/asymmetric_keys/pkcs7_parser.c |1 crypto/asymmetric_keys/public_key.c | 38 +++ crypto/asymmetric_keys/signature.c| 150 +

Re: [PATCH v4 6/7] crypto: KEYS - add generic handlers to symmetric key type

Tadeusz Struk wrote: > +/** > + * asymmetric_key_verify_signature - invoke verify signature operation on a > key > + *of the asymmetric subtype > + * @key: key from the system keyring > + * @sig: signature to verify > + * > + * return: 0

Re: [PATCH] PKCS#7: fix missing break on OID_sha224 case

unintentional missing break. > > Fixes: 07f081fb5057 ("PKCS#7: Add OIDs for sha224, sha284 and sha512 hash > algos and use them") > Cc: <sta...@vger.kernel.org> # 4.2+ > Signed-off-by: Colin Ian King <colin.k...@canonical.com> Acked-by: David Howells <dhowe...@redha

Re: [PATCH v3 7/7] crypto: AF_ALG - add support for key_id

Tadeusz Struk wrote: > + keyring = request_key(_type_asymmetric, key_name, NULL); > + > + err = -ENOKEY; > + if (IS_ERR(keyring)) > + goto out; > + > + pkey = keyring->payload.data[asym_crypto]; NAK. This is liable to crash in future. You

Re: [PATCH] security: integrity: Remove select to deleted option PUBLIC_KEY_ALGO_RSA

Andreas Ziegler wrote: > Commit d43de6c780a8 ("akcipher: Move the RSA DER encoding check to > the crypto layer") removed the Kconfig option PUBLIC_KEY_ALGO_RSA, > but forgot to remove a 'select' to this option in the definition of > INTEGRITY_ASYMMETRIC_KEYS. > > Let's

Re: Left-over select to PUBLIC_KEY_ALGO_RSA

Andreas Ziegler wrote: > As the corresponding option is gone, the select statement can safely be > removed. Should I prepare a simple patch for that? Please. > I detected this by using scripts/checkkconfigsymbols on today's and > yesterday's linux-next trees (i.e.,

[GIT PULL] KEYS: Miscellaneous bits for security/next

next Arnd Bergmann (1): modsign: hide openssl output in silent builds Codarren Velvindron (1): v2 linux-next scripts/sign-file.c Fix LibreSSL support Colin Ian King (1): PKCS#7: fix unitialized boolean 'want' David Howells (10): KEYS: Add an alloc

Re: [PATCH] PKCS#7: fix unitialized boolean 'want'

Colin King wrote: > The boolean want is not initialized and hence garbage. The default should > be false (later it is only set to true on tne sinfo->authattrs check). > > Found with static analysis using CoverityScan > > Signed-off-by: Colin Ian King

  1   2   3   4   >