Hi Everyone,
I was performing some benchmarking today. On a Skylake Core-i5-6400
machine, and in the past (May 30, 2020), I would see these performance
numbers:
RDRAND: 67 MB/s, ~38 cpb
RDSEED: 24 MB/s, ~105 cpb
I ran the same benchmarks today (January 2 2020) and the benchmark
program repor
On Fri, May 24, 2019 at 4:47 AM Christophe Leroy
wrote:
> ...
> > As I already mentioned in another thread somewhere, this morning in the
> > shower I realised that this may be useful if you have no expectation of
> > the length itself. But it's still a pretty specific use case which was
> > never
On Thu, May 23, 2019 at 4:06 PM Eric Biggers wrote:
>
> On Thu, May 23, 2019 at 01:07:25PM +, Pascal Van Leeuwen wrote:
> >
> > I'm running into some trouble with some random vectors that do *zero*
> > length operations. Now you can go all formal about how the API does
> > not explictly disall
On Wed, Feb 20, 2019 at 4:23 AM Wei Yongjun wrote:
>
> Fixes the following sparse warning:
>
> drivers/char/hw_random/optee-rng.c:265:35: warning:
> symbol 'optee_rng_id_table' was not declared. Should it be static?
Static limits visibility to the current translation unit. Static is
like private
On Tue, Oct 9, 2018 at 2:00 AM Ard Biesheuvel wrote:
>
> On 9 October 2018 at 06:11, Jason A. Donenfeld wrote:
> > Hi Ard,
> > ...
> > As you might expect, when compiling in __siphash_unaligned and
> > __siphash_aligned on the x86 at the same time, __siphash_unaligned is
> > replaced with just "j
On Mon, Aug 6, 2018 at 7:04 PM, Jason A. Donenfeld wrote:
> These are unused, undesired, and have never actually been used by
> anybody. The original authors of this code have changed their mind about
> its inclusion. Therefore, this patch removes it.
I think it may be unwise to completely discar
On Mon, Jul 23, 2018 at 11:16 AM, Theodore Y. Ts'o wrote:
> On Mon, Jul 23, 2018 at 04:43:01AM +0100, Ken Moffat wrote:
>> ...
> One of the reasons why I didn't see the problem when I was developing
> the remediation patch for CVE-2018-1108 is because I run Debian
> testing, which doesn't have thi
On Tue, Jul 17, 2018 at 9:43 PM, Theodore Ts'o wrote:
> This gives the user building their own kernel (or a Linux
> distribution) the option of deciding whether or not to trust the CPU's
> hardware random number generator (e.g., RDRAND for x86 CPU's) as being
> correctly implemented and not having
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 need to perform PBKDF i
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
(https://www.wikitribune.com/story/2018/04/20/internet/67004/67004/):
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
>> atleast for shaX, g
On Mon, Feb 12, 2018 at 2:19 PM, Eric Biggers 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 treating
>> > the
>
On Thu, Feb 8, 2018 at 4:01 PM, Eric Biggers 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 wrote:
>> > Hello,
>> >
>> > This series adds Speck support to the crypto API, including th
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 instructions.
>
> We are plann
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 matters, you can check for GC
> 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 u
On Fri, Oct 13, 2017 at 3:09 PM, Linus Torvalds
wrote:
> On Fri, Oct 13, 2017 at 6:56 AM, Andrey Ryabinin
> wrote:
>>
>> This could be fixed by s/vmovdqa/vmovdqu change like bellow, but maybe the
>> right fix
>> would be to align the data properly?
>
> I suspect anything that has the SHA extensi
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 this correctly:
>
> -
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
On Wed, Jul 12, 2017 at 5:00 PM, Eric Biggers wrote:
> From: Eric Biggers
>
>
> Solve the problem for v2 encryption policies by storing a "hash" of the
> master encryption key in the encryption xattr and verifying it before
> accepting the user-provided key.
> ...
Forgive my ignorance... Doe
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
>>> entries, and overti
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
>> > likely will go unn
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 warning
> coming fr
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 enough random data, don't use it. But wha
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
> types of bugs for o
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 did not want to wait
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 kernel
> already and th
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 the
> Posix standard micros
>> 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 b
>> > 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 instr
> 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... RDSEED
> 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 hav
> 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 mont
> 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.
> + *
> + * This
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 avr32 blackfin c6x cr
>> > 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.
...
>> an
> 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
> The AIO support for algif_aead is broken when submitting more than one iocb.
> The break happens in aead_recvmsg_async at the following code:
>
I think the kernel needs to take a half step back, and add the missing
self tests and test cases to be more proactive in detecting breaks
earlier. Speak
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 interrupt. More often th
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 jz4780_rng_read(struct hwrng *rng, void *buf, size_t max, bool
> wa
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
> ---
> .../devicetree/bindings/rng/ingenic,jz4780-rng.txt | 12 +++
> MAINTAINERS
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 accurate,
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
> 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, 0)
> 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 ne
> 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 CR
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 /proc/modules | egrep -i '(via|pa
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. Padloc
> 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
> 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.
>
> ...
Something
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
>-- 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 th
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 undefined behavior
>>> 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, whic
On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote:
> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote:
>>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 func
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, commit it.
Its
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.
>>
>> > This construct has b
On Wed, May 4, 2016 at 1:49 PM, 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));
>> > +}
>>
>&g
>> + chacha20_block(&crng->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 gi
> +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.
sta
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 the common Linux interrupt handling.
>
On Fri, Apr 8, 2016 at 12:55 PM, Stephan Mueller wrote:
> Am Freitag, 8. April 2016, 12:54:10 schrieb Jeffrey Walton:
>
> Hi Jeffrey,
>
>> > +int rsa_check_key_length(unsigned int len)
>> > +{
>> > + switch (len) {
>> > + case 512
> +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 rest
On Sun, Apr 3, 2016 at 4:42 PM, Jeffrey Walton 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 kernels
>
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
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 i
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 asynchron
67 matches
Mail list logo
