Am Freitag, dem 09.04.2021 um 10:11 +0800 schrieb Hangbin Liu:
> On Thu, Apr 08, 2021 at 08:11:34AM -0700, Eric Biggers wrote:
> > On Thu, Apr 08, 2021 at 07:58:08PM +0800, Hangbin Liu wrote:
> > > On Thu, Apr 08, 2021 at 09:06:52AM +0800, Hangbin Liu wrote:
> > > > > Also, couldn't you just consid
Am Dienstag, dem 30.03.2021 um 15:26 -0700 schrieb Randy Dunlap:
>
> The Kconfig help text for CRYPTO_FIPS says
>
> config CRYPTO_FIPS
> bool "FIPS 200 compliance"
> ...
> help
> This option enables the fips boot option which is
> required if you want the syste
Am Dienstag, dem 30.03.2021 um 15:44 -0700 schrieb Eric Biggers:
> On Tue, Mar 30, 2021 at 09:38:55AM -0700, Randy Dunlap wrote:
> > On 3/29/21 10:29 PM, Eric Biggers wrote:
> > > On Mon, Mar 29, 2021 at 10:06:51PM -0700, Randy Dunlap wrote:
> > > > Having just seen a report of using "fips=1" on th
> Signed-off-by: Milan Djurovic
Thank you
Reviewed-by: Stephan Mueller
Am Dienstag, dem 09.02.2021 um 13:35 + schrieb Elena Petrova:
> Hi Stephan,
>
> On Fri, 8 Jan 2021 at 18:57, Stephan Mueller wrote:
> >
> > Am Freitag, dem 08.01.2021 um 17:38 + schrieb Elena Petrova:
> > > NIAP FPT_TST_EXT.1 [1] specification requ
Am Freitag, dem 08.01.2021 um 17:38 + schrieb Elena Petrova:
> NIAP FPT_TST_EXT.1 [1] specification requires testing of a small set of
> cryptographic modules on boot for devices that need to be NIAP
> compliant. This is also a requirement for FIPS CMVP 140-2/140-3
> certification.
>
> Current
Am Mittwoch, dem 06.01.2021 um 23:30 -0800 schrieb Eric Biggers:
> On Mon, Jan 04, 2021 at 10:49:13PM +0100, Stephan Müller wrote:
> > RFC5869 specifies an extract and expand two-step key derivation
> > function. The HKDF implementation is provided as a service function that
> > operates on a calle
gt; >
> > Signed-off-by: Stephan Mueller
> > ---
> > fs/crypto/Kconfig | 2 +-
> > fs/crypto/fscrypt_private.h | 4 +-
> > fs/crypto/hkdf.c | 108 +---
> > 3 files changed, 30 insertions(+), 84 d
Am Montag, dem 04.01.2021 um 14:20 -0800 schrieb Eric Biggers:
> On Mon, Jan 04, 2021 at 10:45:57PM +0100, Stephan Müller wrote:
> > The HKDF addition is used to replace the implementation in the filesystem
> > crypto extension. This code was tested by using an EXT4 encrypted file
> > system that w
Hi,
with the current cryptodev-2.6 tree and the Linus rc-2 tree, I get the
following during boot:
[0.837048] =
[0.837079] [ BUG: Invalid wait context ]
[0.837079] 5.11.0-rc1+ #215 Not tainted
[0.837079] -
[0.837079] crypt
Am Mittwoch, dem 23.12.2020 um 15:32 +0100 schrieb Jason A. Donenfeld:
>
> I would, however, be interested in a keccak-based construction. But
> just using the keccak permutation does not automatically make it
> "SHA-3", so we're back at the same issue again. FIPS is simply not
> interesting for o
Am Mittwoch, dem 16.12.2020 um 10:39 +0800 schrieb yumeng:
>
>
>
> > Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
> > >
> > > +/* size in bytes of the n prime */
> > > +#define HPRE_ECC_NIST_P128_N_SIZE 16
> >
> > Do we truly need P-128? Besides, I do not see that curve being
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
>
> +/* curve25519 */
> +static u64 curve25519_g_x[] = { 0x0009, 0x,
> + 0x, 0x };
> +static u64 curve25519_p[] = { 0xffed, 0xfff
Am Freitag, den 11.12.2020, 14:30 +0800 schrieb Meng Yu:
>
> +/* size in bytes of the n prime */
> +#define HPRE_ECC_NIST_P128_N_SIZE 16
Do we truly need P-128? Besides, I do not see that curve being defined in
contemporary cipher specs.
> +#define HPRE_ECC_NIST_P192_N_SIZE 24
> +#defi
Am Mittwoch, den 18.11.2020, 11:47 +0800 schrieb Meng Yu:
Hi Meng,
> Enable 'ECDH' algorithm in Kunpeng 930.
>
> Signed-off-by: Meng Yu
> Reviewed-by: Zaibo Xu
> ---
> drivers/crypto/hisilicon/hpre/hpre.h | 2 +-
> drivers/crypto/hisilicon/hpre/hpre_crypto.c | 802
> +
Am Montag, 19. Oktober 2020, 21:28:50 CET schrieb Stephan Müller:
Hi,
>
> * Performance
>
> - Faster by up to 75% in the critical code path of the interrupt handler
>depending on data collection size configurable at kernel compile time -
>the default is about equal in performance with e
Am Dienstag, 10. November 2020, 10:37:02 CET schrieb Paul Menzel:
Hi Paul,
> Dear Stephan,
>
>
> Thank you for the quick reply.
>
> Am 10.11.20 um 10:25 schrieb Stephan Mueller:
> > Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel:
> >> By mi
Am Montag, 9. November 2020, 20:31:02 CET schrieb Paul Menzel:
Hi Paul,
> Dear Linux folks,
>
>
> By mistake I built `XFRM_ESP` into the Linux kernel, resulting in
>
> CONFIG_CRYPTO_SEQIV=y
> CONFIG_CRYPTO_ECHAINIV=y
>
> and also the Jitterentropy RNG to be built in.
>
> CRYPT
Am Mittwoch, 7. Oktober 2020, 06:24:09 CEST schrieb Eric Biggers:
Hi Eric,
>
> Note that having multiple RNG implementations would cause fragmentation,
> more maintenance burden, etc. So IMO, that should be a last resort.
> Instead we should try to find an implementation that works for everyone
Am Montag, 5. Oktober 2020, 08:44:39 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Mon, 5 Oct 2020 at 08:40, Stephan Mueller wrote:
> > Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > > If jitterentropy is a sp
Am Montag, 5. Oktober 2020, 08:24:46 CEST schrieb Ard Biesheuvel:
Hi Ard,
> If jitterentropy is a special case, we could put a alternate
> non-'static inline' version of random_get_entropy() in the core
> kernel, and only export it if JITTER_ENTROPY is built as a module in
> the first place. But
Am Freitag, 2. Oktober 2020, 15:15:55 CEST schrieb Willy Tarreau:
Hi Willy,
> > And this is all ???
>
> Possibly a lot of people got used to seeing the numerous versions
> and are less attentive to new series, it's possible that your message
> will wake everyone up.
I think that points to my pa
Am Freitag, 2. Oktober 2020, 08:49:05 CEST schrieb Christoph Hellwig:
Hi Christoph,
> On Tue, Sep 29, 2020 at 11:56:18PM -0700, Palmer Dabbelt wrote:
> > clint_time_val will soon be used by the RISC-V implementation of
> > random_get_entropy(), which is a static inline function that may be used
>
Am Montag, 21. September 2020, 09:58:16 CEST schrieb Nicolai Stange:
Hi Nicolai,
> Hi all,
>
> first of all, my apologies for the patch bomb following up in reply to this
> mail here -- it's not meant to receive any serious review at all, but only
> to support the discussion I'm hoping to get go
Am Freitag, 18. September 2020, 15:02:17 CEST schrieb kernel test robot:
Hi,
> All errors (new ones prefixed by >>):
> >> drivers/char/lrng/lrng_chacha20.c:33:8: error: structure variable
> >> 'chacha20' with 'latent_entropy' attribute has a non-integer field
> >> 'block'
> 33 | struct chac
Am Mittwoch, 26. August 2020, 16:27:42 CEST schrieb kernel test robot:
Hi,
> >> drivers/char/lrng/lrng_chacha20.c:54:47: sparse: sparse: cast to
> >> restricted __le32
>drivers/char/lrng/lrng_chacha20.c:58:47: sparse: sparse: cast to
> restricted __le32 --
Thanks for the reports. Both, the _
Am Dienstag, 25. August 2020, 13:28:53 CEST schrieb kernel test robot:
Hi,
> All warnings (new ones prefixed by >>):
> >> drivers/char/lrng/lrng_drng.c:381:6: warning: no previous prototype for
> >> 'lrng_reset' [-Wmissing-prototypes]
> 381 | void lrng_reset(void)
>
> | ^~
Am Montag, 24. August 2020, 16:41:13 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi All,
>
> I am using libkcapi to execute HMAC tests. One of key size is 229248 bytes.
> setsockopt(tfmfd, SOL_ALG, ALG_SET_KEY API fails to set the key. I am not
> getting an option to set the buf
I use " additionalInput" and " entropyInput" from
> reSeed section.
>
> I could see only below APIs available to set the values.
> crypto_drbg_get_bytes_addtl_test { crypto_rng_set_entropy,
> crypto_rng_generate) crypto_drbg_reset_test {crypto_rng_set_entropy,
>
Am Donnerstag, 13. August 2020, 11:01:27 CEST schrieb Bhat, Jayalakshmi
Manjunath:
Hi Jayalakshmi,
> Hi All,
>
> I could successfully execute the CAVS test for DRBG with
> ""predResistanceEnabled" : true" reseedImplemented": false.
>
> I am trying to execute the tests with "predResistanceEnab
Am Montag, 3. August 2020, 16:48:02 CEST schrieb Elena Petrova:
Hi Elena,
> On Fri, 31 Jul 2020 at 08:27, Herbert Xu
wrote:
> > Eric Biggers wrote:
> > > lock_sock() would solve the former. I'm not sure what should be done
> > > about
> > > rng_recvmsg(). It apparently relies on the crypto_r
assumed to be non zero.
> So turn the assumption into a check.
>
> Fixes: 541af946fe13 ("crypto: drbg - SP800-90A Deterministic Random Bit
> Generator")
>
> Signed-off-by: Tom Rix
Thank you.
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Dienstag, 28. Juli 2020, 22:40:44 CEST schrieb Pavel Machek:
Hi Pavel,
> Hi!
>
> > The following patch set provides a different approach to /dev/random which
> > is called Linux Random Number Generator (LRNG) to collect entropy within
> > the Linux kernel. The main improvements compared to th
Am Dienstag, 21. Juli 2020, 14:55:14 CEST schrieb Elena Petrova:
Hi Elena,
> > > +#ifdef CONFIG_CRYPTO_CAVS_DRBG
> > > +static int rng_setentropy(void *private, const u8 *entropy, unsigned
> > > int
> > > len) +{
> > > + struct rng_parent_ctx *pctx = private;
> > > + u8 *kentropy = NULL;
Am Donnerstag, 16. Juli 2020, 18:40:28 CEST schrieb Elena Petrova:
Hi Elena,
sorry for the delay in answering.
> Extending the userspace RNG interface:
> 1. adding ALG_SET_DRBG_ENTROPY setsockopt option for entropy input;
> 2. using sendmsg syscall for specifying the additional data.
>
> Si
Am Donnerstag, 16. Juli 2020, 16:49:52 CEST schrieb Stephan Mueller:
Hi Herbert,
(resent, adding Herbert to the list and fix the keyrings address)
> Am Donnerstag, 16. Juli 2020, 16:41:26 CEST schrieb Elena Petrova:
>
> Hi Herbert,
>
> > > > > With these issues, I
Am Donnerstag, 16. Juli 2020, 16:41:26 CEST schrieb Elena Petrova:
Hi Herbert,
> > > > With these issues, I would assume you are better off creating your own
> > > > kernel module just like I did that externalizes the crypto API to user
> > > > space but is only available on your test kernel and
Am Dienstag, 14. Juli 2020, 17:23:05 CEST schrieb Elena Petrova:
Hi Elena,
> Hi Stephan,
>
> On Tue, 14 Jul 2020 at 06:17, Stephan Mueller wrote:
> > Am Montag, 13. Juli 2020, 18:48:56 CEST schrieb Elena Petrova:
> >
> > Hi Elena,
> >
> > > This pa
Am Montag, 13. Juli 2020, 18:48:56 CEST schrieb Elena Petrova:
Hi Elena,
> This patch extends the userspace RNG interface to make it usable for
> CAVS testing. This is achieved by adding ALG_SET_DRBG_ENTROPY
> option to the setsockopt interface for specifying the entropy, and using
> sendmsg sysc
that key with a full validation
> > compliant to section 5.6.2.3.3.
> >
> > Only if the full validation passes, the key is allowed to be used.
> >
> > The patch adds the full key validation compliant to 5.6.2.3.3 and
> > performs the required check on the gene
Am Freitag, 10. Juli 2020, 16:42:39 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Fri, 10 Jul 2020 at 13:16, Stephan Müller wrote:
> > Add mpi_sub_ui() based on Gnu PG mpz_sub_ui() from mpz/aors_ui.h
> > adapting the code to the kernel's structures and coding style and also
> > removing the defines
Am Dienstag, 16. Juni 2020, 05:56:04 CEST schrieb Anshuman Gupta:
Hi Anshuman,
> On 2020-06-15 at 21:25:58 +0200, Stephan Mueller wrote:
> > Am Montag, 15. Juni 2020, 19:04:14 CEST schrieb Anshuman Gupta:
> >
> > Hi Anshuman,
> >
> > > Hi ,
> > &g
Am Montag, 15. Juni 2020, 19:04:14 CEST schrieb Anshuman Gupta:
Hi Anshuman,
> Hi ,
> I wanted to verify a RSA SHA-384 signature.
> I am using crypto_alloc_shash(), crypto_shash_digest() API to extract
> the SHA-384 digest.
> I am having public key along with the sha-384 digest extracted from raw
Am Montag, 15. Juni 2020, 15:02:53 CEST schrieb LABBE Corentin:
Hi,
> I still dont see any memset_secure in kzfree (mm/slab_common.c).
> Does I miss something ?
Nope, you do not miss anything, it seems that the patch that I had seen did
not go in.
>
> Regards
Ciao
Stephan
Am Freitag, 12. Juni 2020, 17:51:52 CEST schrieb Peter P.:
Hi Peter,
> Hi,
>
> According to NIST SP800-131A Table 9, HMAC generation in FIPS must
> have a keylen of 14 bytes minimum. I've noticed that in the crypto
> algorithm testing framework, the HMAC test vectors from RFC 4231 all
> have a t
Am Freitag, 12. Juni 2020, 14:07:36 CEST schrieb Herbert Xu:
Hi Herbert,
> Crypto skcipher algorithms in general allow chaining to break
> large operations into smaller ones based on multiples of the chunk
> size. However, some algorithms don't support chaining while others
> (such as cts) only
Am Donnerstag, 11. Juni 2020, 10:33:56 CEST schrieb Zheng Bin:
Hi Zheng,
Thank you for the note, but I think this is handled, albeit differently.
Search for patch "[PATCH v3] crypto: DRBG - always try to free Jitter RNG
instance" that is sent to the list (but not yet applied).
Thanks
> drbg
Am Freitag, 5. Juni 2020, 08:16:46 CEST schrieb Eric Biggers:
Hi Eric,
> On Fri, Jun 05, 2020 at 07:58:15AM +0200, Stephan Mueller wrote:
> > Am Freitag, 5. Juni 2020, 02:43:36 CEST schrieb Eric Biggers:
> >
> > Hi Eric,
> >
> > > On Thu, Jun 04, 2020 at 08
be deallocated.
> >
> > Reported-by: syzbot+2e635807decef724a...@syzkaller.appspotmail.com
> > Fixes: 97f2650e5040 ("crypto: drbg - always seeded with SP800-90B ...")
> > Signed-off-by: Stephan Mueller
> > ---
> >
> > crypto/drbg.c | 3 +++
> > 1 f
be deallocated.
> >
> > Reported-by: syzbot+2e635807decef724a...@syzkaller.appspotmail.com
> > Fixes: 97f2650e5040 ("crypto: drbg - always seeded with SP800-90B ...")
> > Signed-off-by: Stephan Mueller
> > ---
> >
> > crypto/drbg.c | 3 +++
> &g
g - consolidation of...")
> Cc:
> Signed-off-by: Herbert Xu
Reviewed-by: Stephan Mueller
Thanks
Ciao
Stephan
Am Mittwoch, 27. Mai 2020, 04:21:31 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi All,
>
> I was going through libkcapi APIs to see if it can be used for DRBG CAVS
> validation. But I am thinking it cannot be. I also found cavs_driver.pl,
> this seems to depend on some kernel mo
Am Dienstag, 26. Mai 2020, 05:07:15 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi Stephen,
>
> I to add the backend support using libkcapi APIs to exercise Kernel CAVP.
> Can you please confirm if my understanding is correct?
You would need to implement an equivalent to backen
Am Mittwoch, 20. Mai 2020, 14:00:01 CEST schrieb Krzysztof Kozlowski:
Hi Krzysztof,
> On Wed, 20 May 2020 at 13:53, Stephan Mueller wrote:
> > > > That said, the illustrated example is typical for hardware RNGs. Yet
> > > > it is never guaranteed to work that way
Am Mittwoch, 20. Mai 2020, 12:44:33 CEST schrieb Lukasz Stelmach:
Hi Lukasz,
> It was <2020-05-20 śro 11:18>, when Stephan Mueller wrote:
> > Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach:
> >> It was <2020-05-20 śro 08:23>, when Stephan Muelle
Am Mittwoch, 20. Mai 2020, 11:10:32 CEST schrieb Lukasz Stelmach:
Hi Lukasz,
> It was <2020-05-20 śro 08:23>, when Stephan Mueller wrote:
> > Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach:
> >> The value was estimaded with ea_iid[1] using on 10485760
Am Mittwoch, 20. Mai 2020, 08:54:10 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Wed, 20 May 2020 at 08:47, Stephan Mueller wrote:
> > Am Mittwoch, 20. Mai 2020, 08:40:57 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > > On Wed, 20 May 2020 at 08:03,
Am Mittwoch, 20. Mai 2020, 08:40:57 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Wed, 20 May 2020 at 08:03, Stephan Mueller wrote:
> > Am Dienstag, 19. Mai 2020, 21:02:09 CEST schrieb Ard Biesheuvel:
> >
> > Hi Ard,
> >
> > > Stephan reports that the
Am Dienstag, 19. Mai 2020, 23:25:51 CEST schrieb Łukasz Stelmach:
Hi Łukasz,
> The value was estimaded with ea_iid[1] using on 10485760 bytes read from
> the RNG via /dev/hwrng. The min-entropy value calculated using the most
> common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.96446
src.nist.gov/projects/cryptographic-algorithm-validation-program/
validation-search?searchMode=validation&family=1&productType=-1&ipp=25
[3] https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/
details?validation=32608
[4] https://github.com/smuellerDD/acvpparser
&
Am Dienstag, 19. Mai 2020, 19:53:57 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Tue, 19 May 2020 at 19:50, Ard Biesheuvel wrote:
> > On Tue, 19 May 2020 at 19:35, Stephan Mueller wrote:
> > > Am Dienstag, 19. Mai 2020, 18:21:01 CEST schrieb Ard Biesheuvel:
> > >
>
Am Dienstag, 19. Mai 2020, 18:21:01 CEST schrieb Ard Biesheuvel:
Hi Ard,
>
> To be honest, this looks like the API is being used incorrectly. Is
> this a similar issue to the one Herbert spotted recently with the CTR
> code?
>
> When you say 'leaving the TFM untouched' do you mean the skcipher
Hi Ard,
The following report applies to kernel 5.3 as I am currently unable to test
the latest upstream version.
The CTS IV handling for cts-cbc-aes-ce and cts-cbc-aes-neon is not consistent
with the C implementation for CTS such as cts(cbc-aes-ce) and cts(cbc-aes-
neon).
For example, assume e
Am Freitag, 15. Mai 2020, 11:01:48 CEST schrieb Lukasz Stelmach:
Hi Lukasz,
As I mentioned, all that is or seems to be analyzed here is the quality of the
cryptographic post-processing. Thus none of the data can be used for getting
an idea of the entropy content.
That said, the ent value inde
Am Freitag, 15. Mai 2020, 00:18:41 CEST schrieb Lukasz Stelmach:
Hi Lukasz,
>
> I am running tests using SP800-90B tools and the first issue I can see
> is the warning that samples contain less than 1e6 bytes of data. I know
> little about maths behind random number generators, but I have noticed
Am Donnerstag, 14. Mai 2020, 21:07:34 CEST schrieb Łukasz Stelmach:
Hi Łukasz,
> The value has been estimaded by obtainig 1024 chunks of data 128 bytes
> (1024 bits) each from the generator and finding chunk with minimal
> entropy using the ent(1) tool. The value was 6.332937 bits of entropy
> in
Am Donnerstag, 14. Mai 2020, 21:07:33 CEST schrieb Łukasz Stelmach:
Hi Łukasz,
> The value has been estimaded by obtainig 1024 chunks of data 128 bytes
> (1024 bits) each from the generator and finding chunk with minimal
> entropy using the ent(1) tool. The value was 6.327820 bits of entropy
> in
Am Freitag, 8. Mai 2020, 14:26:41 CEST schrieb Alexander Dahl:
Hi Alexander,
> Hello,
>
> Am Freitag, 8. Mai 2020, 14:22:02 CEST schrieb Stephan Mueller:
> > Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
> > > Okay and DRBG has nothing to do with /dev/ra
Am Freitag, 8. Mai 2020, 14:17:25 CEST schrieb Alexander Dahl:
Hi Alexander,
> > > If so, then how is it supposed to be set up?
> >
> > It is intended for in-kernel purposes (namely to seed its DRBG).
>
> Okay and DRBG has nothing to do with /dev/random ?
Nope, it is used as part of the kernel
Am Freitag, 8. Mai 2020, 13:40:08 CEST schrieb Alexander Dahl:
Hi Alexander,
> Hello,
>
> after upgrading OpenSSL to 1.1.1g on an armv5 based embedded target I had a
> deeper look into entropy generation for that device and stumbled over the in
> kernel 'jitterentropy_rng' module.
>
> As far as
Am Dienstag, 5. Mai 2020, 09:58:35 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Apr 21, 2020 at 10:08:14AM +0200, Ondrej Mosnáček wrote:
> > Hi all,
> >
> > the libkcapi [1] tests are failing on kernels 5.5-rc1 and above [2].
> > All encryption/decryption tests that use 'ctr(aes)' and a messag
ev)
> + if (!drbg->prev) {
> + ret = -ENOMEM;
> goto fini;
> + }
> drbg->fips_primed = false;
> }
Thank you
Reviewed-by: Stephan Mueller
Ciao
Stephan
Am Dienstag, 21. April 2020, 11:19:36 CEST schrieb Stephan Mueller:
Hi Herbert,
could you please help us with the answer to the question below?
> Am Dienstag, 21. April 2020, 10:08:14 CEST schrieb Ondrej Mosnáček:
>
> Hi Ondrej,
>
> > Hi all,
> >
> > the lib
Am Sonntag, 13. Oktober 2019, 10:49:07 CEST schrieb Gleb Pomykalov:
Hi Gleb,
> Hello,
>
> I'm trying to make EIP97 work on Mediatek mtk7623n (Banana PI R2). The
> kernel version is 4.14.145. My tests uses af_alg in libaio mode, and
> encrypts the data. For smaller blocks it works just fine, but
_panic' was not
> declared. Should it be static? crypto/jitterentropy-kcapi.c:79:6: warning:
> symbol 'jent_memcpy' was not declared. Should it be static?
> crypto/jitterentropy-kcapi.c:93:6: warning: symbol 'jent_get_nstime' was
> not declared. Should it be static?
>
> Signed-off-by: Ben Dooks
Reviewed-by: Stephan Mueller
Am Montag, 7. Oktober 2019, 11:06:04 CEST schrieb Hans de Goede:
Hi Hans,
> Hi Stephan,
>
> On 07-10-2019 10:59, Stephan Mueller wrote:
> > Am Montag, 7. Oktober 2019, 10:55:01 CEST schrieb Hans de Goede:
> >
> > Hi Hans,
> >
> >> The purgatory co
Am Montag, 7. Oktober 2019, 10:55:01 CEST schrieb Hans de Goede:
Hi Hans,
> The purgatory code now uses the shared lib/crypto/sha256.c sha256
> implementation. This needs memzero_explicit, implement this.
>
> Reported-by: Arvind Sankar
> Fixes: 906a4bb97f5d ("crypto: sha256 - Use get/put_unalig
Am Sonntag, 1. September 2019, 20:52:24 CEST schrieb Bhat, Jayalakshmi
Manjunath:
Hi Jayalakshmi,
> Hi All,
>
> I am trying to implement DRBG CAVS test harness function for Linux Kernel
> crypto DRBG with the following requirements. 1. Derivate function is
> enabled.
> 2. predi
tests.
>
> Signed-off-by: Ard Biesheuvel
Tested-by: Stephan Mueller
Ciao
Stephan
Am Freitag, 16. August 2019, 11:52:33 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Fri, 16 Aug 2019 at 12:50, Stephan Müller wrote:
> > Hi,
> >
> > with the current cryptodev-2.6 code, I get the following with fips=1:
> >
> > [ 22.301826] alg: skcipher: xts-aes-aesni encryption failed on test
>
Am Dienstag, 30. Juli 2019, 14:38:35 CEST schrieb Hans de Goede:
Hi Hans,
> From: Andy Lutomirski
>
> This just moves code around -- no code changes in this patch. This
> wil let BPF-based tracing link against the SHA256 core code without
> depending on the crypto core.
>
> Cc: Ard Biesheuvel
Am Montag, 22. Juli 2019, 20:07:05 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi All,
>
> We are in the process of implementing
> KAT - known answer test
> MMT - Multi-block Message Test
> MCT - Monte Carlo Test
> KAS FFC - Key Agreement Scheme, Finite F
Am Freitag, 12. Juli 2019, 19:55:07 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi Stephan,
>
> Thank you very much for the suggestions, I have another question, is it
> possible to implement MMT and MCT using kernel crypto API's.
Yes, for sure - I have successfully implemented
Am Donnerstag, 11. Juli 2019, 17:22:00 CEST schrieb Bhat, Jayalakshmi
Manjunath:
Hi Jayalakshmi,
> Hi Stephan,
>
> Thank you very much for the reply. Yes we would need to write the test for
> AEC (ECB,CBC,CTR) 128 and 256 bits, SHA-1, SHA-2 (256,384 and 512), HMAC,
> DRBG and also for key deriv
Am Dienstag, 9. Juli 2019, 08:43:51 CEST schrieb Bhat, Jayalakshmi Manjunath:
Hi Jayalakshmi,
> Hi All,
>
> We are working on a product that requires NIAP certification and use IPSec
> environment for certification. IPSec functionality is achieved by third
> party IPsec library and native XFRM.
Am Dienstag, 9. Juli 2019, 13:34:21 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
> On Tue, Jul 9, 2019 at 9:44 AM Bhat, Jayalakshmi Manjunath
>
> wrote:
> > Hi All,
> >
> > We are working on a product that requires NIAP certification and use IPSec
> > environment for certification. IPSec functiona
Am Donnerstag, 11. Juli 2019, 13:52:29 CEST schrieb Stephan Mueller:
Hi,
> Am Dienstag, 9. Juli 2019, 08:43:51 CEST schrieb Bhat, Jayalakshmi
> Manjunath:
>
> Hi Jayalakshmi,
>
> > Hi All,
> >
> > We are working on a product that requires NIAP certification
Am Mittwoch, 29. Mai 2019, 22:21:50 CEST schrieb Richard Weinberger:
Hi Richard,
> Stephan,
>
> - Ursprüngliche Mail -
>
> >> I've seen that it does actually work the other way around, since
> >> crypto_init_shash_ops_async() in crypto/shash.c takes care of translating
> >> calls from a
Am Mittwoch, 29. Mai 2019, 16:04:47 CEST schrieb David Gstir:
Hi David,
> Hi!
>
> I've done some testing with hardware acceleration of hash functions
> and noticed that, when using the synchronous message digest API (shash),
> some drivers are not usable. In my case the CAAM driver for SHA256.
>
Am Dienstag, 28. Mai 2019, 07:58:19 CEST schrieb Nikolay Borisov:
Hi Nikolay,
> On 28.05.19 г. 7:58 ч., Stephan Mueller wrote:
> > Please correct me if I am wrong, but as far as I see, however, xxhash
> > seems to be a cryptographic hash function.
>
> No, xxhash is n
Am Montag, 27. Mai 2019, 21:15:51 CEST schrieb Eric Biggers:
Hi Eric,
> On Mon, May 27, 2019 at 05:06:53PM +0200, Stephan Mueller wrote:
> > > obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy_rng.o
> > > CFLAGS_jitterentropy.o = -O0
> > > jitteren
Am Montag, 27. Mai 2019, 16:28:10 CEST schrieb Nikolay Borisov:
Hi Nikolay,
> xxhash is currently implemented as a self-contained module in /lib.
> This patch enables that module to be used as part of the generic kernel
> crypto framework. It adds a simple wrapper to the 64bit version. I've
> als
Am Freitag, 24. Mai 2019, 11:21:30 CEST schrieb Pascal Van Leeuwen:
Hi Pascal,
> I was not aware of that, so thanks for pointing that out.
> Do they use the async calls (_aio) though? Because otherwise they shouldn't
> end up being hardware accelerated anyway ...
Yes, AIO is supported: http://ch
ect custom hardware keys provided by hardware
> (AES_SEL_HW_KEY)?
I am not intimately familiary with the keyring facility. Thus, let us ask the
experts at the keyring mailing list :-)
>
> Thanks
> kalyani
>
> > -Original Message-
> > From: Stepha
b3614763059b82c26bdd02ffcb1c016c1132aad0 .
The Jitter RNG implements its own FIPS 140-2 self test and thus does not
need to be subjected to the test in the DRBG.
The patch contains a tiny fix to ensure proper zeroization in case of an
error during the Jitter RNG data gathering.
Signed-off-by: Stephan Mueller
---
crypto
Am Dienstag, 7. Mai 2019, 15:10:38 CEST schrieb Yann Droneaud:
Hi Yann,
> > + if (IS_ENABLED(CONFIG_CRYPTO_FIPS)) {
>
> if (!IS_ENABLED(CONFIG_CRYPTO_FIPS))
> return 0;
Changed
>
> > + unsigned short entropylen = drbg_sec_strength(drbg->core-
>flags);
> > +
Am Dienstag, 7. Mai 2019, 15:10:38 CEST schrieb Yann Droneaud:
Hi Yann,
> Hi,
>
> Le mardi 07 mai 2019 à 11:29 +0200, Stephan Müller a écrit :
> > FIPS 140-2 section 4.9.2 requires a continuous self test of the noise
> > source. Up to kernel 4.8 drivers/char/random.c provided this continuous
> >
Am Freitag, 3. Mai 2019, 03:42:41 CEST schrieb Herbert Xu:
Hi Herbert,
> On Thu, May 02, 2019 at 06:38:12PM +0200, Stephan Müller wrote:
> > +static int drbg_fips_continuous_test(struct drbg_state *drbg,
> > +const unsigned char *entropy)
> > +{
> > +#if IS_ENABLED
Am Donnerstag, 2. Mai 2019, 14:48:11 CEST schrieb Herbert Xu:
Hi Herbert,
> Hi Stephan:
>
> On Thu, May 02, 2019 at 02:40:51PM +0200, Stephan Müller wrote:
> > +static int drbg_fips_continuous_test(struct drbg_state *drbg,
> > +const unsigned char *entropy)
> > +{
Am Donnerstag, 11. April 2019, 10:51:06 CEST schrieb Herbert Xu:
Hi Herbert,
> This patch forbids the use of 2-key 3DES (K1 == K3) in FIPS mode.
>
> Signed-off-by: Herbert Xu
> ---
>
> drivers/crypto/ccree/cc_aead.c | 37 +++--
> 1 file changed, 35 insertions(
1 - 100 of 1554 matches
Mail list logo
