On Fri, Jan 11, 2019 at 08:10:02PM +0100, Stephan Müller wrote:
> The SP800-108 compliant Key Derivation Function is implemented as a
> random number generator considering that it behaves like a deterministic
> RNG.
>
> All three KDF types specified in SP800-108 are implemented.
>
> The code comm
On Fri, Jan 11, 2019 at 08:10:22PM +0100, Stephan Müller wrote:
> Add known answer tests to the testmgr for the KDF (SP800-108) cipher.
>
> Signed-off-by: Stephan Mueller
> ---
> crypto/testmgr.c | 226 +++
> crypto/testmgr.h | 110
On Fri, Jan 11, 2019 at 08:10:56PM +0100, Stephan Müller wrote:
> Add known answer tests to the testmgr for the HKDF (RFC5869) cipher.
>
> The known answer tests are derived from RFC 5869 appendix A.
>
> Note, the HKDF is considered to be a FIPS 140-2 allowed (not approved)
> cipher as of now. Ye
Hi Stephan,
On Fri, Jan 11, 2019 at 08:10:39PM +0100, Stephan Müller wrote:
> The RFC5869 compliant Key Derivation Function is implemented as a
> random number generator considering that it behaves like a deterministic
> RNG.
>
Thanks for the proof of concept! I guess it ended up okay. But can
Enable testing of the SP800-108 and RFC5869 KDFs.
Signed-off-by: Stephan Mueller
---
crypto/tcrypt.c | 8
1 file changed, 8 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index e7fb87e114a5..5606e59e80ec 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -2054,6 +2054,
Hi Herbert, Eric,
key derivation functions behave like a random number generator requiring
a seed and can generate arbitrarily-sized bit sequences. As KDFs wrap
ciphers, the first patch adds template support for the RNG part of the
kernel crypto API. This allows the KDFs to be implemented as templ
The RFC5869 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.
The extract and expand phases use different instances of the underlying
keyed message digest cipher to ensure that while the extraction phase
generates a
Add known answer tests to the testmgr for the KDF (SP800-108) cipher.
Signed-off-by: Stephan Mueller
---
crypto/testmgr.c | 226 +++
crypto/testmgr.h | 110 +++
2 files changed, 336 insertions(+)
diff --git a/crypto/testmgr.c b/cry
Add known answer tests to the testmgr for the HKDF (RFC5869) cipher.
The known answer tests are derived from RFC 5869 appendix A.
Note, the HKDF is considered to be a FIPS 140-2 allowed (not approved)
cipher as of now. Yet, an allowed cipher is usable under FIPS 140-2
rules.
Signed-off-by: Steph
The SP800-108 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.
All three KDF types specified in SP800-108 are implemented.
The code comments provide details about how to invoke the different KDF
types.
Signed-off-
Add ability to register templates for RNGs. RNGs are
"meta" mechanisms using raw cipher primitives. Thus, RNGs can now be
implemented as templates to allow the complete flexibility the kernel
crypto API provides.
Signed-off-by: Stephan Mueller
---
crypto/rng.c | 44 +
On Fri, Jan 11, 2019 at 02:33:58PM +0800, Herbert Xu wrote:
> On Thu, Jan 03, 2019 at 08:16:09PM -0800, Eric Biggers wrote:
> > Hello,
> >
> > This series adds a function skcipher_alloc_instance_simple() that
> > greatly simplifies creating an skcipher_instance that uses a single
> > underlying bl
Hi Sumit,
Thanks for the patch. Some nitpicks in-line:
On 01/11/2019 05:17 PM, Sumit Garg wrote:
Introduce a generic TEE bus driver concept for TEE based kernel drivers
which would like to communicate with TEE based devices/services.
In this TEE bus concept, devices/services are identified via
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
In chacha20-simd, clear the MAY_SLEEP flag in the blkcipher_desc to
prevent sleeping with preemption disabled, under kernel_fpu_begin().
This was fixed upstream incidentally by a
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Biggers
In chacha20-simd, clear the MAY_SLEEP flag in the blkcipher_desc to
prevent sleeping with preemption disabled, under kernel_fpu_begin().
This was fixed upstream incidentally by a
On ARM SoC's with TrustZone enabled, peripherals like entropy sources
might not be accessible to normal world (linux in this case) and rather
accessible to secure world (OP-TEE in this case) only. So this driver
aims to provides a generic interface to OP-TEE based random number
generator service.
Introduce a generic TEE bus driver concept for TEE based kernel drivers
which would like to communicate with TEE based devices/services.
In this TEE bus concept, devices/services are identified via Universally
Unique Identifier (UUID) and drivers register a table of device UUIDs
which they can sup
This flag indicates that requests in this context should not wait for
tee-supplicant daemon to be started if not present and just return
with an error code. It is needed for requests which should be
non-blocking in nature like ones arising from TEE based kernel drivers
or any in kernel api that use
OP-TEE provides a pseudo TA to enumerate TAs which can act as devices/
services for TEE bus. So implement device enumeration using invoke
function: PTA_CMD_GET_DEVICES provided by pseudo TA to fetch array of
device UUIDs. Also register these enumerated devices with TEE bus as
"optee-clntX" device.
This series introduces a generic TEE bus driver concept for TEE based
kernel drivers which would like to communicate with TEE based devices/
services.
Patch #1 adds TEE bus concept where devices/services are identified via
Universally Unique Identifier (UUID) and drivers register a table of
device
On Fri, 11 Jan 2019 at 15:24, Daniel Thompson
wrote:
>
> On Fri, Jan 11, 2019 at 01:00:49PM +0530, Sumit Garg wrote:
> > On Thu, 10 Jan 2019 at 19:53, Daniel Thompson
> > wrote:
> > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > > > index 9ddb89e..5d6c317 100644
> > > > ---
On Fri, Jan 11, 2019 at 01:00:49PM +0530, Sumit Garg wrote:
> On Thu, 10 Jan 2019 at 19:53, Daniel Thompson
> wrote:
> > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
> > > index 9ddb89e..5d6c317 100644
> > > --- a/drivers/tee/tee_core.c
> > > +++ b/drivers/tee/tee_core.c
> > > @@
On Fri, 11 Jan 2019 at 15:09, Daniel Thompson
wrote:
>
> On Fri, Jan 11, 2019 at 12:52:19PM +0530, Sumit Garg wrote:
> > On Thu, 10 Jan 2019 at 19:49, Daniel Thompson
> > wrote:
> > > > +static int get_devices(struct tee_context *ctx, u32 session,
> > > > +struct tee_shm *devi
On Fri, Jan 11, 2019 at 12:52:19PM +0530, Sumit Garg wrote:
> On Thu, 10 Jan 2019 at 19:49, Daniel Thompson
> wrote:
> > > +static int get_devices(struct tee_context *ctx, u32 session,
> > > +struct tee_shm *device_uuid, u32 *shm_size)
> >
> > Missing const on device_uuid?
> >
On Thu, 10 Jan 2019 at 19:57, Daniel Thompson
wrote:
>
> On Thu, Jan 10, 2019 at 05:54:57PM +0530, Sumit Garg wrote:
> > On ARM SoC's with TrustZone enabled, peripherals like entropy sources
> > might not be accessible to normal world (linux in this case) and rather
> > accessible to secure world
25 matches
Mail list logo
