Jarkko Sakkinen wrote:
> + spin_lock_irqsave(&key_graveyard_lock, flags);
> + list_splice_init(&key_graveyard, &graveyard);
> + spin_unlock_irqrestore(&key_graveyard_lock, flags);
I would wrap this bit in a check to see if key_graveyard is empty so that we
can avoid disabling irqs an
Herbert Xu wrote:
> Personally I don't think the argument above holds water. With
> IPsec we had a similar issue of authenticating untrusted peers
> using public key cryptography. In that case we successfully
> delegated the task to user-space and it is still how it works
> to this day.
It tra
as the epilogue so that
> the OID can be simply copied to the blob.
>
> Signed-off-by: Jarkko Sakkinen
Reviewed-by: David Howells
Jarkko Sakkinen wrote:
> There's no reason to encode OID_TPMSealedData at run-time, as it never
> changes.
>
> Replace it with the encoded version, which has exactly the same size:
>
> 67 81 05 0A 01 05
>
> Include OBJECT IDENTIFIER (0x06) tag and length as the epilogue so that
> the OID
Jarkko Sakkinen wrote:
> On Tue May 21, 2024 at 9:18 PM EEST, James Bottomley wrote:
> ...
> You don't save a single byte of memory with any constant that dictates
> the size requirements for multiple modules in two disjoint subsystems.
I think James is just suggesting you replace your limit arg
Varad Gautam wrote:
> The test harness is available at [5].
Can you add this to the keyutils testsuite?
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/keyutils.git
David
Varad Gautam wrote:
> + Opt_slen, /* "slen=" eg. "slen=32" */
"slen" seems a bit unobvious. Maybe "saltlen=..."?
David
Richard Weinberger wrote:
> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum wrote:
> > keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
>
> Is there a reason why we can't pass the desired backend name in the
> trusted key parameters?
> e.g.
> keyctl add trusted $KEYNAME "backendtype caam
: fix kernel doc interface issue
Alexander A. Klimov (1):
encrypted-keys: Replace HTTP links with HTTPS ones
David Howells (1):
certs: Fix blacklist flag type confusion
Denis Efremov (1):
security/keys: use kvfree_sensitive()
Gabriel Krisman Bertazi (1):
watch_queue: Drop
: fix kernel doc interface issue
Alexander A. Klimov (1):
encrypted-keys: Replace HTTP links with HTTPS ones
David Howells (1):
certs: Fix blacklist flag type confusion
Denis Efremov (1):
security/keys: use kvfree_sensitive()
Gabriel Krisman Bertazi (1):
watch_queue: Drop
Herbert Xu wrote:
> > No idea. It seems straightforward enough, at least on the keyrings side,
> > that
> > I was going to add it.
>
> In that case please wait for the discussion on how we handle curves
> to be finalised.
Sure. Will do.
David
Herbert Xu wrote:
> > Should I defer it till the next merge window?
>
> Is there any specific reason why this has to be in the current
> one?
No idea. It seems straightforward enough, at least on the keyrings side, that
I was going to add it.
David
Herbert Xu wrote:
> > Herbert wants the first patch to go through the crypto tree. Maybe all of
> > them should proceed by that route if Herbert is willing?
>
> I'm not actually all that fussed about where it goes through. It's
> just the first patch happens to touch an area that is still unde
Mickaël Salaün wrote:
> It doesn't contain Jarkko's Tested-by and Reviewed-by tags though.
I can add that in the merge.
David
Stefan Berger wrote:
> 1) the whole series goes through the crypto tree
>
> 2) I make the OIDs addition patch 1 that both keyrings and crypto take
> separately?
The first might be easiest, but 2 is okay also. You'll just need to give
myself and Herbert separate branches to pull, rooted on the
Stefan Berger wrote:
> v6->v7:
> - Moved some OID defintions to patch 1 for bisectability
> - Applied R-b's
But I can't now apply 2-4 without patch 1.
David
Mimi Zohar wrote:
> > > Do you have a branch you want me to pull or did you want me to take just
> > > patches 2-4?
> >
> > Please take it from the mailing list. If there are requests for more
> > changes on the crypto level, I will send another series. I personally am
> > waiting for some sor
Stefan Berger wrote:
> From: Stefan Berger
>
> 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.
>
> Signed-off-by: Stefan Berger
> Cc: Da
Vitaly Chikunov wrote:
> > +static inline
> > +const struct public_key *asymmetric_key_public_key(const struct key *key)
> > +{
> > + return key->payload.data[asym_crypto];
> > +}
>
> I wonder why use this accessor which does nothing else, because in all
> other places payload.data[asym_crypto
Hi Mickaël,
Do you have a public branch somewhere I can pull from?
David
Hi Mickaël,
I could pull your patches (unless Jarkko wants to), but can you please drop
the patches that are also in my keys-misc branch lest one or other (or both)
of our branches get dropped in the next merge window due to conflicts?
Ideally, can you base your branch on my keys-misc branch?
Stefan Berger wrote:
> > This (sub)set is intended to go through the keyrings tree or is it all going
> > through the crypto tree now?
>
>
> Patch 1/3 should go through 'crypto', the other ones through 'keyrings'.
Do 2 & 3 depend on 1?
David
This (sub)set is intended to go through the keyrings tree or is it all going
through the crypto tree now?
David
Herbert Xu wrote:
> > I've pulled this into my keys-next branch.
>
> David, please drop them because there are issues with the Crypto API
> bits.
Okay, dropped.
David
Stefan Berger wrote:
> This series of patches adds support for x509 certificates signed by a CA
> that uses NIST p256 or p192 keys for signing. It also adds support for
> certificates where the public key is a NIST p256 or p192 key. The math
> for ECDSA signature verification is also added.
>
>
Stefan Berger wrote:
> k=$(keyctrl newring test @u)
keyctl - but I can fix that.
David
Jarkko Sakkinen wrote:
> > I suppose a user space tool could be created. But wouldn’t what is
> > currently done in the kernel in this area need to be removed?
>
> Right. I don't think this was a great idea in the first place to
> do to the kernel but since it exists, I guess the patch does make
Jarkko Sakkinen wrote:
> With eBPF around, does this make any sense?
bpf/ebpf may be partially disabled if you boot in secure boot mode - not sure
whether that affects this.
David
Stefan Berger wrote:
> keyctrl newring test @u
This should be keyctl, and I would recommend you do:
k=`keyctl newring test @u`
and then use $k for it.
You also need:
#include
in ecc.c in the middle patch.
David
ure
public_key_verify_signature
This patch simply check this situation and fixes the crash
caused by NULL pointer.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Reported-by: Tobias Markus
Signed-off-by: Tianjia Zhang
Signed-off-by: David Howells
Reviewed-and-tested-by:
ure
public_key_verify_signature
This patch simply check this situation and fixes the crash
caused by NULL pointer.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Reported-by: Tobias Markus
Signed-off-by: Tianjia Zhang
Signed-off-by: David Howells
Reviewed-and-tested-by:
David Howells wrote:
> This fixes CVE-2020-26541.
Note that I added the CVE number, not Eric.
David
eferenced, if a matching key is found, the key will be rejected.
[DH: I've changed the names of the new functions with Eric's approval]
Signed-off-by: Eric Snowberg
Reviewed-by: Jarkko Sakkinen
Signed-off-by: David Howells
diff --git a/certs/blacklist.c
ure
This patch simply check this situation and fixes the crash
caused by NULL pointer.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Reported-by: Tobias Markus
Signed-off-by: Tianjia Zhang
Signed-off-by: David Howells
Reviewed-and-tested-by:
ure
This patch simply check this situation and fixes the crash
caused by NULL pointer.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Cc: sta...@vger.kernel.org # v5.10+
Reported-by: Tobias Markus
Signed-off-by: Tianjia Zhang
Signed-off-by:
Toke Høiland-Jørgensen wrote:
> Reviewed-by: Toke Høiland-Jørgensen
>
> and also, if you like:
>
> Tested-by: Toke Høiland-Jørgensen
Thanks!
David
ly check this situation and fixes the crash
caused by NULL pointer.
Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate
verification")
Cc: sta...@vger.kernel.org # v5.10+
Reported-by: Tobias Markus
Signed-off-by: Tianjia Zhang
Signed-off-by: David
nytime the .platform keyring is used, the keys in the .blacklist keyring
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg
Reviewed-by: Jarkko Sakkinen
Signed-off-by: David Howells
diff --git a/certs/blacklist.c b/certs/blackli
Eric Snowberg wrote:
> > On Dec 10, 2020, at 2:49 AM, David Howells wrote:
> >
> > Eric Snowberg wrote:
> >
> >> Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
> >> is found, it is added as an asymmetrical key to the .bla
t; Reported-by: Tobias Markus
> Signed-off-by: Tianjia Zhang
Looks reasonable:
Acked-by: David Howells
I wonder, though, if cert_sig_digest_update() should be obtained by some sort
of function pointer. It doesn't really seem to belong in this file. But this
is a separate issue.
David
ander A. Klimov (1):
encrypted-keys: Replace HTTP links with HTTPS ones
David Howells (1):
certs: Fix blacklist flag type confusion
Denis Efremov (1):
security/keys: use kvfree_sensitive()
Gabriel Krisman Bertazi (1):
watch_queue: Drop references to /dev/watch_queue
Gusta
Eric Snowberg wrote:
> Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
> is found, it is added as an asymmetrical key to the .blacklist keyring.
> Anytime the .platform keyring is used, the keys in the .blacklist keyring
> are referenced, if a matching key is found, the
Ben Boeckel wrote:
> > I've extended my collection of minor keyrings fixes for the next merge
> > window. Anything else I should add (or anything I should drop)?
> >
> > The patches can be found on the following branch:
> >
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/
fixes
David
---
Alex Shi (2):
PKCS#7: drop function from kernel-doc pkcs7_validate_trust_one
certs/blacklist: fix kernel doc interface issue
Alexander A. Klimov (1):
encrypted-keys: Replace HTTP links with HTTPS ones
David Howells (1):
certs: Fix blacklist flag type conf
_trust.c:25: warning: Function parameter or
member 'sinfo' not described in 'pkcs7_validate_trust_one'
crypto/asymmetric_keys/pkcs7_trust.c:25: warning: Function parameter or
member 'trust_keyring' not described in 'pkcs7_validate_trust_one'
Signed-off-by: Alex
Mickaël Salaün wrote:
> + cmd_check_blacklist_hashes = $(AWK) -f
> scripts/check-blacklist-hashes.awk $(2); touch $@
The script name needs prefixing with $(srctree)/ so that it can be used with
alternative build directories.
Note that doesn't apply to scripts/extract-cert in the same make
Ard Biesheuvel wrote:
> Apparently, it is permitted for gss_krb5_cts_crypt() to do a
> kmalloc(GFP_NOFS) in the context from where gss_krb5_aes_encrypt() is
> being invoked, and so I don't see why it wouldn't be possible to
> simply kmalloc() a scatterlist[] of the appropriate size, populate it
>
David Howells wrote:
> I wonder - would it make sense to reserve two arrays of scatterlist structs
> and a mutex per CPU sufficient to map up to 1MiB of pages with each array
> while the krb5 service is in use?
Actually, simply reserving a set per CPU is probably unnecessary. We c
I wonder - would it make sense to reserve two arrays of scatterlist structs
and a mutex per CPU sufficient to map up to 1MiB of pages with each array
while the krb5 service is in use?
That way sunrpc could, say, grab the mutex, map the input and output buffers,
do the entire crypto op in one go an
Ard Biesheuvel wrote:
Ard Biesheuvel wrote:
> > > > I wonder if it would help if the input buffer and output buffer didn't
> > > > have to correspond exactly in usage - ie. the output buffer could be
> > > > used at a slower rate than the input to allow for buffering inside the
> > > > crypto a
Ard Biesheuvel wrote:
> > I wonder if it would help if the input buffer and output buffer didn't
> > have to correspond exactly in usage - ie. the output buffer could be used
> > at a slower rate than the input to allow for buffering inside the crypto
> > algorithm.
> >
>
> I don't follow - how
Ard Biesheuvel wrote:
> > Yeah - the problem with that is that for sunrpc, we might be dealing with
> > 1MB
> > plus bits of non-contiguous pages, requiring >8K of scatterlist elements
> > (admittedly, we can chain them, but we may have to do one or more large
> > allocations).
> >
> > > However
Herbert Xu wrote:
> > Herbert recently made some changes for MSG_MORE support in the AF_ALG
> > code, which permits a skcipher encryption to be split into several
> > invocations of the skcipher layer without the need for this complexity
> > on the side of the caller. Maybe there is a way to reus
Ard Biesheuvel wrote:
> The tricky thing with CTS is that you have to ensure that the final
> full and partial blocks are presented to the crypto driver as one
> chunk, or it won't be able to perform the ciphertext stealing. This
> might be the reason for the current approach. If the sunrpc code
Bruce Fields wrote:
> OK, I guess I don't understand the question. I haven't thought about
> this code in at least a decade. What's an auxilary cipher? Is this a
> question about why we're implementing something, or how we're
> implementing it?
That's what the Linux sunrpc implementation call
Bruce Fields wrote:
> > Reading up on CTS, I'm guessing the reason it's like this is that CTS is the
> > same as the non-CTS, except for the last two blocks, but the non-CTS one is
> > more efficient.
>
> CTS is cipher-text stealing, isn't it? I think it was Kevin Coffman
> that did that, and I
Hi Chuck, Bruce,
Why is gss_krb5_crypto.c using an auxiliary cipher? For reference, the
gss_krb5_aes_encrypt() code looks like the attached.
>From what I can tell, in AES mode, the difference between the main cipher and
the auxiliary cipher is that the latter is "cbc(aes)" whereas the former is
Mickaël Salaün wrote:
> - KUIDT_INIT(0), KGIDT_INIT(0), current_cred(),
> + GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(),
I may pull out some of the relatively trivial changes like this and add them
to my keys-fixes branch.
David
Mickaël Salaün wrote:
> + if (*desc)
> + /* The hash is greater than MAX_HASH_LEN. */
> + return -EINVAL;
-ENOPKG might be better. It's not that the string is invalid, it's just that
it's unsupported at the moment.
David
Mickaël Salaün wrote:
> +#include
Something like linux/types.h is probably a better choice.
David
Mickaël Salaün wrote:
> When looking for a blacklisted hash, bin2hex() is used to transform a
> binary hash to an ascii (lowercase) hexadecimal string. This string is
> then search for in the description of the keys from the blacklist
> keyring. When adding a key to the blacklist keyring,
> bla
Mickaël Salaün wrote:
> > What would be easiest way to smoke test the changes?
>
> An easy way to test it is to enable the second trusted keyring to
> dynamically load certificates in the kernel. Then we can create a hash
> of a valid certificate (but not loaded yet) and sign it as explained in
Herbert Xu wrote:
> Couldn't you just change the output sg to include the offset?
That depends on whether the caller has passed it elsewhere for some other
parallel purpose, but I think I'm going to have to go down that road and
restore it afterwards.
David
Btw, would it be feasible to make it so that an extra parameter can be added
to the cipher buffer-supplying functions, e.g.:
skcipher_request_set_crypt(req, input, ciphertext_sg, esize, iv);
such that we can pass in an offset into the output sg as well?
David
I've taken Tianjia Zhang's patch for this.
Thanks,
David
Tobias Markus wrote:
> kernel: RIP: 0010:public_key_verify_signature+0x189/0x3f0
Is it possible for you to provide a disassembly of this function from the
kernel you were using? For this to occur on that line, it appears that sig
would need to be NULL - but that should trip an assertion at the
Herbert Xu wrote:
> > Here's my first cut at a generic Kerberos crypto library in the kernel so
> > that I can share code between rxrpc and sunrpc (and cifs?).
>
> I can't find the bit where you are actually sharing this code with
> sunrpc, am I missing something?
I haven't done that yet. Sorr
Chuck Lever wrote:
> Really? My understanding of the Linux kernel SUNRPC implementation is
> that it uses asynchronous, even for small data items. Maybe I'm using
> the terminology incorrectly.
Seems to be synchronous, at least in its use of skcipher:
grep -e skcipher *
gss_krb5_crypto.c:#inclu
Chuck Lever wrote:
> > There are three main interfaces to it:
> >
> > (*) I/O crypto: encrypt, decrypt, get_mic and verify_mic.
> >
> > These all do in-place crypto, using an sglist to define the buffer
> > with the data in it. Is it necessary to make it able to take separate
> > i
Would it be possible/practical to make the skcipher encrypt functions take an
offset into the scatterlist rather than always starting at the beginning?
David
---
net/rxrpc/ar-internal.h |1
net/rxrpc/key.c | 136 +++
net/rxrpc/rxgk.c| 25 +
net/rxrpc/rxgk_app.c| 135 +++
net/rxrpc/rxgk_common.h |2 +
net/rxrpc/security.c
Provide key derivation interface functions and a helper to implement the
PRF+ function from rfc4402.
Signed-off-by: David Howells
---
crypto/krb5/Makefile |1
crypto/krb5/kdf.c | 223 +
include/crypto/krb5.h | 29 ++
3 files
Add some constants from the sunrpc headers.
Signed-off-by: David Howells
---
include/crypto/krb5.h | 39 +++
1 file changed, 39 insertions(+)
diff --git a/include/crypto/krb5.h b/include/crypto/krb5.h
index 2bd6cfe50b85..a7e4ab4e1348 100644
--- a/include
inserted into the security-specific field in
the RX header, and we try and expand it to 32-bits to make it last longer.
Signed-off-by: David Howells
---
net/rxrpc/ar-internal.h |6 ++
net/rxrpc/conn_object.c |2 +
net/rxrpc/rxgk.c| 156
in:
tools.ietf.org/html/draft-wilkinson-afs3-rxgk-11
Signed-off-by: David Howells
---
net/rxrpc/Kconfig | 10 ++
net/rxrpc/Makefile |3 +
net/rxrpc/ar-internal.h |3 +
net/rxrpc/rxgk_common.h | 44
net/rxrpc/rxgk_kdf.c| 271
KEN_CELL_MAX = 64;
struct ktc_setTokenData {
afs_int32 flags;
string cell;
token_opaque tokens;
};
The parser for the basic token struct is already present, as is the rxkad
token type. This adds a parser for the rxgk token type.
Signed-off-by: David Howells
---
Implement the basic parts of the yfs-rxgk security class (security index 6)
to support GSSAPI-negotiated security.
Signed-off-by: David Howells
---
include/trace/events/rxrpc.h |4
net/rxrpc/Makefile |2
net/rxrpc/ar-internal.h | 12
net/rxrpc/rxgk.c
Add the security index for the YFS variant of rxgk.
Signed-off-by: David Howells
---
fs/afs/misc.c | 13 +
include/uapi/linux/rxrpc.h | 17 +
2 files changed, 30 insertions(+)
diff --git a/fs/afs/misc.c b/fs/afs/misc.c
index 1d1a8debe472
=6803
Signed-off-by: David Howells
---
crypto/krb5/Kconfig|3
crypto/krb5/Makefile |3
crypto/krb5/internal.h |6 +
crypto/krb5/main.c |2
crypto/krb5/rfc6803_camellia.c | 249
crypto/krb5
Implement encryption and decryption functions for AES + HMAC-SHA2 as
described in rfc8009 sec 5.
Signed-off-by: David Howells
---
crypto/krb5/rfc8009_aes2.c | 205
1 file changed, 203 insertions(+), 2 deletions(-)
diff --git a/crypto/krb5
Implement the aes128-cts-hmac-sha256-128 and aes256-cts-hmac-sha384-192
enctypes from rfc8009, overriding the rfc3961 kerberos 5 simplified crypto
scheme.
Signed-off-by: David Howells
---
crypto/krb5/Kconfig|2
crypto/krb5/Makefile |3 -
crypto/krb5/internal.h |6
Add the self-testing data from rfc8009 to test AES + HMAC-SHA2.
Signed-off-by: David Howells
---
crypto/krb5/selftest_data.c | 116 +++
1 file changed, 116 insertions(+)
diff --git a/crypto/krb5/selftest_data.c b/crypto/krb5/selftest_data.c
index
Implement self-testing infrastructure to test the pseudo-random function,
key derivation, encryption and checksumming.
Signed-off-by: David Howells
---
crypto/krb5/Kconfig |4
crypto/krb5/Makefile|4
crypto/krb5/internal.h | 48
crypto/krb5/main.c
Implement the aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 enctypes
from rfc3962, using the rfc3961 kerberos 5 simplified crypto scheme.
Signed-off-by: David Howells
---
crypto/krb5/Makefile |3 +
crypto/krb5/internal.h|6 ++
crypto/krb5/main.c|2 +
crypto
Add functions that sign and verify a piece of an skbuff according to
rfc3961 sec 5.4, using Kc to generate a checksum and insert it into the MIC
field in the skbuff in the sign phase then checksum the data and compare it
to the MIC in the verify phase.
Signed-off-by: David Howells
---
crypto
Add functions that encrypt and decrypt a piece of an skbuff according to
rfc3961 sec 5.3, using Ki to checksum the data to be secured and Ke to
encrypt it during the encryption phase, then decrypting with Ke and
verifying the checksum with Ki in the decryption phase.
Signed-off-by: David Howells
Implement the simplified crypto profile for Kerberos 5 rfc3961 with the
pseudo-random function, PRF(), from section 5.3 and the key derivation
function, DK() from section 5.1.
Signed-off-by: David Howells
---
crypto/krb5/Makefile |3
crypto/krb5/internal.h |6
rpc patches that are a prerequisite for
this, but the crypto patches don't need it.
---
The patches can be found here also:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=crypto-krb5
David
---
David Howells (18):
crypto/krb5: Implement Kerberos crypto
Provide core structures, an encoding-type registry and basic module and
config bits for a generic Kerberos crypto library.
Signed-off-by: David Howells
---
crypto/Kconfig |1 +
crypto/Makefile|1 +
crypto/krb5/Kconfig| 11 ++
crypto/krb5/Makefile |9
Hi Herbert, Dave, Trond,
I've written basic gssapi-derived security support for AF_RXRPC:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rxgk
I've borrowed some bits from net/sunrpc/auth_gss/ but there's a lot in there
that is quite specific to the su
Waiman Long wrote:
> The kzfree() function is normally used to clear some sensitive
> information, like encryption keys, in the buffer before freeing it back
> to the pool. Memset()
"memset()" is all lowercase.
> is currently used for buffer clearing. However unlikely, there is still a
> non-ze
Geert Uytterhoeven wrote:
> > > TL;DR: CONFIG_CRYPTO_DH=y is reported to cause boot delays of several
> > > minutes on old and slow machines.
> >
> > Why is it doing that? It doesn't do anything unless it is called, so
> > something must be calling it.
>
> I don't know. Enabling initcall_debug
Would you rather this went through net or net-next?
David
Ard Biesheuvel wrote:
> Given that this part of the driver only uses synchronous crypto, and
> only using a hardcoded algo and mode [pcbc(fcrypt)], of which only a
> generic C implementation exists, may I suggest that we switch to a
> library based approach instead?
>
> That way, we can get rid
_call
struct.
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by
userspace and kernel both")
Reported-by: Arnd Bergmann
Signed-off-by: David Howells
cc: Herbert Xu
---
net/rxrpc/ar-internal.h |4 ++
net/rxrpc/call_object.c |4 +-
net/rxrpc/insecure.c|5 ++
Marcel Holtmann wrote:
> why use the description instead the actual key id? I wonder if a single
> socket option and a struct providing the key type and key id might be more
> useful.
If the key becomes invalid in some way, you can call request_key() again if
you have the description to get a ne
| > It's not clear that sig->digest is guaranteed to be kmalloc memory.
Well, public_key_signature_free() will go bang if it's not kfree'able.
David
Vitaly Chikunov wrote:
> + digest = kmemdup(sig->digest, sig->digest_size, GFP_KERNEL);
> + if (!digest)
You shouldn't need to copy the digest. It's being passed in to the crypto
algorithm, not extracted out.
> + if (memcmp(c, outbuf_enc, c_size)) {
Please use == 0 and !=
I have a couple of patches that add ACLs to keyrings, that you can find at the
top of the branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-acl
I have other patches that allow tags to be used as subjects in the ACL, with a
container supplying
Umm... What do I apply this patch to?
In your modified public_key_verify_signature():
> - sg_init_one(&digest_sg, output, outlen);
> - akcipher_request_set_crypt(req, &sig_sg, &digest_sg, sig->s_size,
> + sg_init_one(&output_sg, output, outlen);
> + akcipher_request_set_crypt(req
1 - 100 of 440 matches
Mail list logo
