On Fri, 8 Dec 2017, David Howells wrote:
Mat Martineau <mathew.j.martin...@linux.intel.com> 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
)
+ goto error;
}
- ret = keyring_restrict(key_ref, link_reject ? NULL : type, restriction);
+ ret = keyring_restrict(key_ref, _type ? type : NULL, restriction);
kfree(restriction);
-
error:
key_ref_put(key_ref);
-
return ret;
}
--
2.15.0.531.g2ccb3012c9-goog
--
Mat Martineau
Intel OTC
els than v4.12. If I have
a chance I'll see if I can find a reproducer.
CONFIG_KEY_DH_OPERATIONS and use of mpi_powm() by KEYCTL_DH_COMPUTE goes
back to v4.7, when the MPI library was called directly. KPP was not
implemented yet.
--
Mat Martineau
Intel OTC
res, MPI base, MPI exp, MPI mod)
break;
e = ep[i];
c = BITS_PER_MPI_LIMB;
+
+ cond_resched();
}
/* We shifted MOD, the modulo reduction argument, left
MOD_SHIFT_CNT
--
2.15.0
--
Mat Martineau
Intel OTC
material well and choose between
crypto engines (including engines that did not support software fallback)
- that's when David put together his patches. David, is there help you
could use with the hardware asymmetric key subtype or other aspects of
keyctl crypto?
--
Mat Martineau
Intel OTC
On Fri, 11 Aug 2017, Andrew Zaborowski wrote:
HI,
On 11 August 2017 at 02:48, Mat Martineau
<mathew.j.martin...@linux.intel.com> wrote:
The last round of reviews for AF_ALG akcipher left off at an impasse around
a year ago: the consensus was that hardware key support was
you might only use the
socket for a brief time to do one verify or encrypt operation.
Given the efficiency and hardware key issues, AF_ALG seems to be
mismatched with asymmetric crypto. Have you looked at the proposed
keyctl() support for crypto operations?
Thanks,
--
Mat Martineau
Intel OTC
Herbert,
On Thu, 17 Nov 2016, Herbert Xu wrote:
On Wed, Nov 16, 2016 at 11:17:33AM -0800, Mat Martineau wrote:
Herbert -
Following commit 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is a NULL
dereference crash in algif_hash when recv() is called twice like this:
send(sk, data, len
719c9daea ]---
If I revert 493b2ed3f7603a15ff738553384d5a4510ffeb95, there is no crash.
Regards,
--
Mat Martineau
Intel OTC
--
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 htt
that, I've done a quick test of the patches using sendmsg() and
read() and found that they work as expected.
Thanks,
Mat
Reported-by: Mat Martineau <mathew.j.martin...@linux.intel.com>
Signed-off-by: Stephan Mueller <smuel...@chronox.de>
---
crypto/algif_
Stephan,
On Wed, 9 Nov 2016, Stephan Mueller wrote:
Am Montag, 31. Oktober 2016, 16:18:32 CET schrieb Mat Martineau:
Hi Mat,
My main concern is getting the semantics correct and consistent in a
single patch series. It would be a big problem to explain that AF_ALG AEAD
read and write works
Fix the single instance where a positive EINVAL was returned.
Signed-off-by: Mat Martineau <mathew.j.martin...@linux.intel.com>
---
crypto/dh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/dh.c b/crypto/dh.c
index 9d19360..ddcb528 100644
--- a/crypto/dh.c
Hi Stephan -
On Mon, 31 Oct 2016, Stephan Mueller wrote:
Am Freitag, 28. Oktober 2016, 15:21:19 CET schrieb Mat Martineau:
Hi Mat,
Please check the current patch (the one I sent to you as a pre-release did
not contain the fix for the decryption part -- the patch sent to the list
and what
Stephan,
On Fri, 28 Oct 2016, Stephan Mueller wrote:
Am Donnerstag, 27. Oktober 2016, 14:42:14 CEST schrieb Mat Martineau:
Hi Mat,
Stephan and Herbert,
On Thu, 27 Oct 2016, Stephan Mueller wrote:
Hi Herbert,
for this patch, I have updated the testing for libkcapi accordingly and
all
16
bytes were read.
I see how this is similar to the documented use of the dst buffer in
aead_request_set_crypt(), but it is not consistent with POSIX read()
semantics.
--
Mat Martineau
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body
Herbert -
On Thu, 22 Sep 2016, Herbert Xu wrote:
On Wed, Sep 21, 2016 at 04:39:30PM -0700, Mat Martineau wrote:
There was a regression in pkcs1pad signature verification, related
to signature verification, that you fixed in commit 27710b8ea3defcb:
https://git.kernel.org/cgit/linux/kernel
problem in the decrypt operation, which was not
adjusted for the leading zero changes. See pkcs1pad_decrypt_complete().
I haven't had a chance to test a fix yet, but with the final 4.8 release
coming up very soon I wanted to report the issue.
Regards,
--
Mat Martineau
Intel OTC
);
+(struct keyctl_kdf_params __user *)
arg5);
default:
return -EOPNOTSUPP;
Regards,
--
Mat Martineau
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
e,
.BI "key_serial_t " prime ", key_serial_t " base ", void **" _buffer ");"
+.sp
+.BI "long keyctl_dh_compute_kdf(key_serial_t " private ", key_serial_t " prime
,
+.BI "key_serial_t " base ", char *" kdfname ", char *" otherinfo ",
+.BI "size_t " otherinfolen ", char *" buffer ", size_t " buflen ");"
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH DESCRIPTION
.BR keyctl_dh_compute ()
@@ -64,6 +70,49 @@ places the data in it. If successful, a pointer to the
buffer is placed in
.IR *_buffer .
The caller must free the buffer.
.P
+.BR keyctl_dh_compute_kdf ()
+derives a key from a Diffie-Hellman shared secret according to the protocol
+specified in SP800-56A. The Diffie-Hellman computation is based on the same
+primitives as discussed
+for
+.BR keyctl_dy_compute ().
Minor typo: dy->dh
Regards,
--
Mat Martineau
Intel OTC
--
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
On Fri, 5 Aug 2016, Stephan Mueller wrote:
Am Donnerstag, 4. August 2016, 13:41:58 CEST schrieb Mat Martineau:
Hi Mat,
+
+long keyctl_dh_compute(struct keyctl_dh_params __user *params,
+ char __user *buffer, size_t buflen,
+ struct keyctl_kdf_params
he kernel.
+.P
+The KDF returns the requested number of bytes specified with the
+.I genlen
+or the
+.I buflen
+parameter depending on the invoked function.
+.P
+.I buffer
+and
+.I buflen
+specify the buffer into which the computed result will be placed.
+.P
+.BR keyctl_dh_compute_kdf_alloc ()
+is simi
(char __user *) arg3, (size_t) arg4,
-(void __user *) arg5);
+ (struct keyctl_kdf_params __user *)
arg5);
default:
return -EOPNOTSUPP;
Regards,
--
Mat Martineau
Intel OTC
--
To unsubscribe from this list
algorithm is
printed in /proc/keys, but is not returned by KEYCTL_PKEY_QUERY or
KEYCTL_DESCRIBE.
Does it make sense to add the information from key->type->describe() to
KEYCTL_PKEY_QUERY or KEYCTL_DESCRIBE? Or add something new like
KEYCTL_DESCRIBE_TYPE?
--
Mat Martineau
Int
Stephan,
On Fri, 15 Jul 2016, Stephan Mueller wrote:
Am Donnerstag, 14. Juli 2016, 17:45:59 schrieb Mat Martineau:
Hi Mat,
Signed-off-by: Stephan Mueller <smuel...@chronox.de>
---
include/uapi/linux/keyctl.h | 10 +
security/keys/Kconfig | 1 +
security/keys/dh.c
keyctl_dh_params __user *)
arg2,
(char __user *) arg3, (size_t) arg4,
-(void __user *) arg5);
+(struct keyctl_kdf_params __user *)
arg5);
default:
re
On Thu, 14 Jul 2016, Stephan Mueller wrote:
Am Mittwoch, 13. Juli 2016, 16:17:12 schrieb Mat Martineau:
Hi Mat,
---8<
Add the interface logic to support DH with KDF handling support.
The dh_compute code now allows the following options:
- no KDF support / output of raw DH sha
ivate @s
+expect_keyid privateid
+
+marker "COMPUTE DH SHARED SECRET"
+dh_compute $privateid $primeid $xaid
+expect_payload payload $shared
As I mentioned at the top, we'll need an 'expect_multiline' function that
handles values like $shared.
+
+marker "COMPUTE DERIVED KEY
On Fri, 8 Jul 2016, Tadeusz Struk wrote:
Hi Mat,
On 07/06/2016 12:38 PM, Mat Martineau wrote:
So it looks like the only thing that we need to return to the user in
this case is the return code. Do you agree?
The way verify_signature is implemented today, the only output is the
return code
On Tue, 5 Jul 2016, Tadeusz Struk wrote:
Hi Mat,
On 06/29/2016 11:43 AM, Mat Martineau wrote:
+ret = verify_signature(key, );
+if (!ret) {
+req->dst_len = sizeof(digest);
I think you fixed the BUG_ON() problem but there's still an issue with
the handling of the digest. Ch
cking for DH functionality"). I'll forward that
to you.
--
Mat Martineau
Intel OTC
--
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
a key in a TPM) can or can not provide the digest needed. Maybe this
is why the verify_signature hook in struct asymmetric_key_subtype is
optional.
+ scatterwalk_map_and_copy(digest, req->dst, 0, req->dst_len, 1);
+ }
+ kfree(src);
+ return ret;
+}
+
--
Ma
return n >= CRYPTO_MAX_ALG_NAME ? -EINVAL : 0;
+ }
+
+ if (strcmp(encoding, "raw") == 0) {
+ strcpy(alg_name, pkey->pkey_algo);
+ return 0;
+ }
+
+ return -ENOPKG;
+}
Regards,
--
Mat Martineau
Intel OTC
--
To unsubscri
Stephan and Tadeusz,
On Fri, 10 Jun 2016, Tadeusz Struk wrote:
On 06/09/2016 11:36 AM, Stephan Mueller wrote:
Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau:
Hi Mat, Tadeusz,
Ok, after checking the code again, I think that dropping that sanity check
should be ok given
a lot of trouble getting agreement on userspace access to
asymmetric ciphers and I think we could make some progress with in-person
discussion. (Mailing list discussion is also important because not
everyone concerned can attend the summit)
Thanks,
--
Mat Martineau
Intel OTC
--
To unsubscribe
ed)
+ goto unlock;
err might be uninitialised at this goto. Should it be set to something
like -EALREADY to indicate that data is already queued for a different
crypto op?
+unlock:
+ akcipher_data_wakeup(sk);
+ release_sock(sk);
+
+ return err ?: copied;
+}
Regards,
On Thu, 9 Jun 2016, Stephan Mueller wrote:
Am Donnerstag, 9. Juni 2016, 11:18:04 schrieb Mat Martineau:
Hi Mat,
Or is your concern that the user space interface restricts things too much
and thus prevents a valid use case?
The latter - my primary concern is the constraint this places
On Thu, 9 Jun 2016, Stephan Mueller wrote:
Am Mittwoch, 8. Juni 2016, 12:14:49 schrieb Mat Martineau:
Hi Mat,
On Wed, 8 Jun 2016, Stephan Mueller wrote:
Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau:
Hi Mat,
+ used = ctx->used;
+
+ /* convert iovecs of out
On Wed, 8 Jun 2016, Stephan Mueller wrote:
Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau:
Hi Mat,
+ used = ctx->used;
+
+ /* convert iovecs of output buffers into scatterlists */
+ while (iov_iter_count(>msg_iter)) {
+ /* make one iovec ava
if (err == -EBADMSG)
+ akcipher_put_sgl(sk);
+ goto unlock;
+ }
+
+ akcipher_put_sgl(sk);
+
+unlock:
+ for (i = 0; i < cnt; i++)
+ af_alg_free_sg(>rsgl[i]);
+
+ akcipher_wmem_wakeup(sk);
+ release_sock(s
On Thu, 26 May 2016, David Howells wrote:
Mat Martineau <mathew.j.martin...@linux.intel.com> 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/comp
On Wed, 25 May 2016, David Howells wrote:
Mat Martineau <mathew.j.martin...@linux.intel.com> 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
-off-by: Mat Martineau <mathew.j.martin...@linux.intel.com>
---
Documentation/security/keys.txt | 9 -
include/uapi/linux/keyctl.h | 5 +
security/keys/compat.c | 2 +-
security/keys/dh.c | 8 +++-
security/keys/internal.h| 5 +++--
securit
ure. We could future-proof KEYCTL_DH_COMPUTE by
adding a 5th arg, an optional pointer to KDF configuration (NAME and
LABEL). Or a separate KEYCTL_DH_COMPUTE_KDF command can be added later.
--
Mat Martineau
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto"
request *req)
...
+ ret = verify_signature(key, NULL, );
key->type->asym_verify_signature() is available as well.
Regards,
--
Mat Martineau
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.ke
On Thu, 12 May 2016, David Howells wrote:
Mat Martineau <mathew.j.martin...@linux.intel.com> wrote:
+ len = crypto_akcipher_maxsize(tfm);
+ info->key_size = len * 8;
+ info->max_data_size = len;
+ info->max_sig_size = len;
+ info->
-asn1.h
+
+clean-files+= pkcs8-asn1.c pkcs8-asn1.h
--
Mat Martineau
Intel OTC
--
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
+ info->max_sig_size = len;
+ info->max_enc_size = len;
+ info->max_dec_size = len;
If len > UINT16_MAX, should UINT16_MAX be reported as the max size?
Similar question for len*8 and key_size.
--
Mat Martineau
Intel OTC
--
To unsubscribe from this list: send the line &
check for NULL asym_eds_op before calling.
Regards,
--
Mat Martineau
Intel OTC
--
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
id keyctl_pkey_params_free(struct kernel_pkey_params *params)
+{
+ kfree(params->info);
+ key_put(params->key);
+ key_put(params->password);
+}
+
+enum {
+ Opt_err = -1,
+ Opt_enc,/* "enc=" eg. "enc=oaep" */
endoding->encoding
49 matches
Mail list logo
