Re: PBKDF2 support in the linux kernel

On Thu, May 24, 2018 at 5:11 AM, Stephan Mueller wrote: > Am Donnerstag, 24. Mai 2018, 10:33:07 CEST schrieb Rafael J. Wysocki: > > Hi Rafael, > >> So the problem is that Yu would like to use this for hibernation encryption >> done entirely in the kernel. > > But why do you

Re: [PATCH v2 0/5] crypto: Speck support

On Tue, Apr 24, 2018 at 12:11 PM, Jason A. Donenfeld wrote: > Can we please not Speck? > > It was just rejected by the ISO/IEC. > > https://twitter.com/TomerAshur/status/988659711091228673 Yeah, but here was the reason given

Re: [PATCH v3 1/4] crypto: AF_ALG AIO - lock context IV

On Thu, Feb 15, 2018 at 8:04 AM, Stephan Mueller wrote: > Am Donnerstag, 15. Februar 2018, 13:45:53 CET schrieb Harsh Jain: > >> > Could you please elaborate what you mean with "partial tag" support? >> >> Here is the catch, Calculation of tag depends on total payload length

Re: [PATCH 0/5] crypto: Speck support

On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers <ebigg...@google.com> wrote: > Hi all, > > On Fri, Feb 09, 2018 at 07:07:01PM -0500, Jeffrey Walton wrote: >> > Hi Jeffrey, >> > >> > I see you wrote the SPECK implementation in Crypto++, and you are t

Re: [PATCH 0/5] crypto: Speck support

On Thu, Feb 8, 2018 at 4:01 PM, Eric Biggers <ebigg...@google.com> wrote: > On Wed, Feb 07, 2018 at 08:47:05PM -0500, Jeffrey Walton wrote: >> On Wed, Feb 7, 2018 at 7:09 PM, Eric Biggers <ebigg...@google.com> wrote: >> > Hello, >> > >> > This series

Re: [PATCH 0/5] crypto: Speck support

On Wed, Feb 7, 2018 at 7:09 PM, Eric Biggers wrote: > Hello, > > This series adds Speck support to the crypto API, including the Speck128 > and Speck64 variants. Speck is a lightweight block cipher that can be > much faster than AES on processors that don't have AES

Re: [PATCH RFC 0/3] API for 128-bit IO access

On Wed, Jan 24, 2018 at 4:05 AM, Yury Norov wrote: > > ... > With all that, this example code: > > static int __init 128bit_test(void) > { > __uint128_t v; > __uint128_t addr; > __uint128_t val = (__uint128_t) 0x1234567890abc; > ... In case it

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

> Still, a stream cipher is sufficient to protect data confidentiality in > the event of a single point-in-time permanent offline compromise of the > disk, which currently is the primary threat model for fscrypt. Thus, > when the alternative is quite literally *no encryption*, we might as > well

Re: Poor RNG performance on Ryzen

On Fri, Jul 21, 2017 at 3:12 AM, Oliver Mangold wrote: > Hi, > > I was wondering why reading from /dev/urandom is much slower on Ryzen than > on Intel, and did some analysis. It turns out that the RDRAND instruction is > at fault, which takes much longer on AMD. > > if I read

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Hi Ted, Snipping one comment: > Practically no one uses /dev/random. It's essentially a deprecated > interface; the primary interfaces that have been recommended for well > over a decade is /dev/urandom, and now, getrandom(2). We only need > 384 bits of randomness every 5 minutes to reseed the

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 7:38 PM, Theodore Ts'o wrote: > On Tue, Jun 20, 2017 at 11:49:07AM +0200, Jason A. Donenfeld wrote: >> ... >>> I more or less agree with you that we should just turn this on for all >>> users and they'll just have to live with the spam and report odd >>>

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote: > On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote: >> > Suppressing all messages for all configurations cast a wider net than >> > necessary. Configurations that could potentially be detected and fixed >> >

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 4:14 AM, Jason A. Donenfeld wrote: >... > Specifically, I added `depends on DEBUG_KERNEL`. This means that these > useful warnings will only poke other kernel developers. This is probably > exactly what we want. If the various associated developers see a

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan wrote: > On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote: >> Hi Lee, >> >> On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: >>> It seems like what you are doing is basically "good", i.e. if there is >>> not

Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Tue, Jun 6, 2017 at 1:48 PM, Jason A. Donenfeld wrote: > This enables an important dmesg notification about when drivers have > used the crng without it being seeded first. Prior, these errors would > occur silently, and so there hasn't been a great way of diagnosing these >

Re: [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote: > These functions are simple convenience wrappers that call > wait_for_random_bytes before calling the respective get_random_* > function. It may be advantageous to add a timeout, too. There's been a number of times I

Re: get_random_bytes returns bad randomness before seeding is complete

On Sun, Jun 4, 2017 at 1:48 AM, Stephan Müller wrote: > Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld: > >> Alternatively, I'm open to other solutions people might come up with. > > How about stirring in some data from the Jitter RNG that we have in the

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris wrote: > ... > Of course this will fail on systems with no high-res timer. Are there > still some of those? It might be done in about 1000 times as long on a > system that lacks the realtime library's nanosecond timer but has

Re: [PATCH] crypto: gf128mul - define gf128mul_x_ble in gf128mul.h

>> Also note that '(b & ((u64)1 << 63)) ? 0x87 : 0x00;' is actually getting >> compiled as '((s64)b >> 63) & 0x87', which is branchless and therefore makes >> the >> new version more efficient than one might expect: >> >> sar$0x3f,%rax >> and$0x87,%eax >> >> It could even

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

>> > The design and implementation is driven by a set of goals described in [2] >> > that the LRNG completely implements. Furthermore, [2] includes a >> > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and >> > AIS20/31. >> >> A quick comment about SP800 and the hardware

Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1)

> The design and implementation is driven by a set of goals described in [2] > that the LRNG completely implements. Furthermore, [2] includes a > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and > AIS20/31. A quick comment about SP800 and the hardware instructions...

Re: [PATCH 0/2] crypto: arm64/ARM: NEON accelerated ChaCha20

> ChaCha20 is a stream cipher described in RFC 7539, and is intended to be > an efficient software implementable 'standby cipher', in case AES cannot > be used. That's not quite correct. The IETF changed the algorithm a bit, and its not compatible with Bernstein's ChaCha. They probably should

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> As far as half-siphash is concerned, it occurs to me that the main > problem will be those users who need to guarantee that output can't be > guessed over a long period of time. For example, if you have a > long-running process, then the output needs to remain unguessable over > potentially

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> diff --git a/lib/test_siphash.c b/lib/test_siphash.c > new file mode 100644 > index ..93549e4e22c5 > --- /dev/null > +++ b/lib/test_siphash.c > @@ -0,0 +1,83 @@ > +/* Test cases for siphash.c > + * > + * Copyright (C) 2016 Jason A. Donenfeld . All Rights > Reserved.

Fast Code and HAVE_EFFICIENT_UNALIGNED_ACCESS (was: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access)

On Wed, Nov 2, 2016 at 5:25 PM, Jason A. Donenfeld wrote: > These architectures select HAVE_EFFICIENT_UNALIGNED_ACCESS: > > s390 arm arm64 powerpc x86 x86_64 > > So, these will use the original old code. > > The architectures that will thus use the new code are: > > alpha arc

Re: [ANNOUNCE] libkcapi v0.12.0 released

>> > The Linux kernel exports a network interface of type AF_ALG to allow user >> > space to utilize the kernel crypto API. libkcapi uses this network >> > interface and exports an easy to use API so that a developer does not >> > need to consider the low-level network interface handling. ... >>

Re: [ANNOUNCE] libkcapi v0.12.0 released

> The Linux kernel exports a network interface of type AF_ALG to allow user > space to utilize the kernel crypto API. libkcapi uses this network interface > and exports an easy to use API so that a developer does not need to consider > the low-level network interface handling. > > The library does

Entropy sources (was: /dev/random - a new approach)

On Fri, Aug 19, 2016 at 1:20 PM, H. Peter Anvin wrote: > On 08/18/16 22:56, Herbert Xu wrote: >> On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote: >>> >>> That really depends on the system. We can't assume that people are >>> using systems with a 100Hz clock

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- > ... > +static int

Re: [PATCH] Add Ingenic JZ4780 hardware RNG driver

On Wed, Aug 17, 2016 at 11:35 AM, PrasannaKumar Muralidharan wrote: > This patch adds support for hardware random number generator present in > JZ4780 SoC. > > Signed-off-by: PrasannaKumar Muralidharan > --- >

JZ4780 RNG and entropy depletion

Hi Everyone, I have a MIPSEL ci20 dev board for testing. The board has a hardware based rng, but its suffering entropy depletion. I have Debian's rng-tools package installed. The board lacks /dev/hwrng. /dev/random blocks indefinitely after draining the device. "Indefinitely" may not be

Data type for aio_buf under X32?

Hi Everyone, My apologies for this question and my confusion. When interfacing with the kernel crypto through AF_ALG, what is the type of 'aio_buf' under X32? I know is X32 uses ILP32 data model, so integers/longs/pointers are 32-bits (cf., http://www.unix.org/version2/whatsnew/lp64_wp.html). I

Re: AF_ALG broken?

> When trying to use the openssl AF_ALG module with 4.8-rc1 with imx > caam, I get this: > > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5 > ... > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3 > close(3)= 0 > socket(PF_ALG, SOCK_SEQPACKET,

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

> Note, as shared secrets potentially post-processed by a KDF usually are again > used as key or data encryption keys, they need to be truncated/expanded to a > specific length anyway. A KDF inherently provides the truncation support to > any arbitrary length. Thus, I would think that the caller

Re: Unable to decrypt message

> I am trying to encrypt decrypt data over the wire. On the receiver > side I have a pre-routing hook where I get reference to my encrypted > data and apply decryption using the skcipher api's, however I am > unable to get the same data back. > > My algo is same on both ends "cbc(aes)" and using

Re: (none)

On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu wrote: > On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote: >> >> I thought via-rng.c covers the VIA Padlock RNG? > > Indeed, you're quite right. In that case Jeffrey was the via-rng > driver loaded? $ cat

[no subject]

Please forgive my ignorance here... I have test system with a VIA C7-M processor and PM-400 chipset. This is one of those Thin Client/Internet of Things processor and chipsets I test security libraries on (like OpenSSL, Cryptlib and Crypto++). The processor includes the Padlock extensions.

Re: AES-NI: slower than aes-generic?

> If we implement something which happens to result in a 2 minute stall > in boot times, the danger is that a clueless engineer at Sony, or LGE, > or Motorola, or BMW, or Toyota, etc, will "fix" the problem without > telling anyone about what they did, and we might not notice right away > that the

Re: AES-NI: slower than aes-generic?

> What I am wondering is that when encrypting 256 16 byte blocks, I get a speed > of about 170 MB/s with the AES-NI driver. When using the aes-generic or aes- > asm, I get up to 180 MB/s with all else being equal. Note, that figure > includes a copy_to_user of the generated data. > > ...

HWCAP_CRYPTO define for ARMv8?

Hi Everyone, It appears defines like HWCAP_CRC32 fall under the purview of the kernel. Confer, http://www.google.com/search?q="HWCAP_CRC32; (my apologies if this is not the case). We use getauxval(AT_HWCAP) and HWCAP_CRC32 for runtime detection of processor support for CRC. However, I can't find

Re: UB in general ... and linux/bitops.h in particular

>-- Perhaps the compiler guys could be persuaded to support > the needed features explicitly, perhaps via a command-line > option: -std=vanilla > This should be a no-cost option as things stand today, but > it helps to prevent nasty surprises in the future. It looks LLVM has

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > ... > But instead of arguing over what works and doesn't, let's just create > the the test set and just try it on a wide range of compilers and > architectures, hmmm? What are the requirements? Here's a short list: * No

Re: better patch for linux/bitops.h

>>> So you are actually saying outright that we should sacrifice *actual* >>portability in favor of *theoretical* portability? What kind of >>twilight zone did we just step into?! >> >>I'm not sure what you mean. It will be well defined on all platforms. >>Clang may not recognize the pattern,

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin <h...@zytor.com> wrote: > On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton <noloa...@gmail.com> wrote: >>On Wed, May 4, 2016 at 5:52 PM, John Denker <j...@av8n.com> wrote: >>> On 05/04/2016 02:42 PM, I wrote: >&g

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: > On 05/04/2016 02:42 PM, I wrote: > >> I find it very odd that the other seven functions were not >> upgraded. I suggest the attached fix-others.diff would make >> things more consistent. > > Here's a replacement patch. > ... +1,

Re: linux/bitops.h

On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote: > On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >> >> Beware that shifting by an amount >= the number of bits in the >> >> word remains Undefined Behavior. >> >>

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, May 4, 2016 at 1:49 PM, <ty...@mit.edu> wrote: > On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >> > +static inline u32 rotl32(u32 v, u8 n) >> > +{ >> > + return (v << n) | (v >> (sizeof(v) * 8 - n)); >> &

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

>> + chacha20_block(>state[0], out); >> + if (crng->state[12] == 0) >> + crng->state[13]++; > > state[12]++? Or why do you increment the nonce? In Bernstein's Salsa and ChaCha, the counter is 64-bit. It appears ChaCha-TLS uses a 32-bit counter, and the other 32-bits is given

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

> +static inline u32 rotl32(u32 v, u8 n) > +{ > + return (v << n) | (v >> (sizeof(v) * 8 - n)); > +} That's undefined behavior when n=0. I think the portable way to do a rotate that avoids UB is the following. GCC, Clang and ICC recognize the pattern, and emit a rotate instruction.

Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o wrote: > From: Stephan Mueller > > The Hyper-V Linux Integration Services use the VMBus implementation for > communication with the Hypervisor. VMBus registers its own interrupt > handler that completely bypasses

Re: [PATCH v3 2/3] crypto: rsa_helper - add raw integer parser actions

On Fri, Apr 8, 2016 at 12:55 PM, Stephan Mueller <smuel...@chronox.de> wrote: > Am Freitag, 8. April 2016, 12:54:10 schrieb Jeffrey Walton: > > Hi Jeffrey, > >> > +int rsa_check_key_length(unsigned int len) >> > +{ >> > + switch (len) {

Re: [PATCH v3 2/3] crypto: rsa_helper - add raw integer parser actions

> +int rsa_check_key_length(unsigned int len) > +{ > + switch (len) { > + case 512: > + case 1024: > + case 1536: > + case 2048: > + case 3072: > + case 4096: > + return 0; > + } > + > + return -EINVAL; > +} That's an unusual

Re: What are the requirements to create/open an AF_ALG socket type?

On Sun, Apr 3, 2016 at 4:42 PM, Jeffrey Walton <noloa...@gmail.com> wrote: > I'm testing userspace crypto code using AF_ALG domain socket. The call > to 'socket(AF_ALG, SOCK_SEQPACKET, 0)' always fails with errno=2. The > failure has been experienced on 3.8, 4.1, 4.2 and 4.4 kern

What are the requirements to create/open an AF_ALG socket type?

I'm testing userspace crypto code using AF_ALG domain socket. The call to 'socket(AF_ALG, SOCK_SEQPACKET, 0)' always fails with errno=2. The failure has been experienced on 3.8, 4.1, 4.2 and 4.4 kernels (provided by Debian, Fedora, Lubuntu and Ubuntu). I also experienced it on a Gentoo kernel, but

How to detect availability of asynchronous ciphers at runtime?

Hi Everyone, Please forgive my ignorance here... I'm trying to detect the availability of asynchronous ciphers support at runtime. The back story is there's some feature tests going on based on hard coded kernel version numbers (namely, 4.1). I feel like there's probably a better way to go about

Userland crypto api test cases and test programs?

Hi Everyone, I've been doing some testing of OpenSSL's upcoming 1.1.0. OpenSSL includes an Engine wrapper for the userland crypto exposed through the kernel's AF_ALG socket domain. The upcoming code experiences somewhat unexplained failures on occasion. I think its partly related to the