Re: PBKDF2 support in the linux kernel

2018-05-25 Thread Tomas Mraz
On Thu, 2018-05-24 at 20:42 -0400, Theodore Y. Ts'o wrote: > On Thu, May 24, 2018 at 07:09:27PM -0500, Denis Kenzior wrote: > > > > But seriously, how is it a fault of the 'random person on the > > mailing list' > > that AF_ALG exists and is being used for its (seemingly intended) > > purpose? > >

Re: [PATCH v4 0/5] /dev/random - a new approach

2016-06-21 Thread Tomas Mraz
e). You have to trust the host for anything, not just for the entropy in timings. This is completely invalid argument unless you can present a method that one guest can manipulate timings in other guest in such a way that _removes_ the inherent entropy from the host. --

Re: Wrong system clock vs X.509 date specifiers

2012-09-25 Thread Tomas Mraz
On Tue, 2012-09-25 at 18:31 +0100, David Howells wrote: > Tomas Mraz wrote: > > > You can use openssl ca that allows to set arbitrary start date to > > generate selfsigned certs as well (-selfsign option). > > That seems to require some stuff I don't have installed

Re: Wrong system clock vs X.509 date specifiers

2012-09-25 Thread Tomas Mraz
m to be possible with openssl req. What would you recommend? You can use openssl ca that allows to set arbitrary start date to generate selfsigned certs as well (-selfsign option). -- Tomas Mraz No matter how far down the wrong road you've gone, turn back.

Re: [PATCH] random: add blocking facility to urandom

2011-09-07 Thread Tomas Mraz
to occasionally block with this patch, just read the data and drop it. But you have to understand that the value that will be set with the sysctl added by this patch will be large in the order of millions of bits. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back.

Re: [CRYPTO] obfuscating kernel pointers

2010-11-15 Thread Tomas Mraz
On Mon, 2010-11-15 at 19:58 +0800, Herbert Xu wrote: > Tomas Mraz wrote: > > > > This would not be a 'hashing' algorithm but a simple block encryption > > algorithm in the ECB mode with the random key initialized at boot. The > > problem here is that the st

Re: [CRYPTO] obfuscating kernel pointers

2010-11-15 Thread Tomas Mraz
the ECB mode with the random key initialized at boot. The problem here is that the standard block ciphers have at least 64 bit block length as smaller block length ciphers would not be secure for general purpose uses. You would have to take an existing block cipher algorithm and modify it to achi

Re: RFC: Crypto API User-interface

2010-09-07 Thread Tomas Mraz
E); > > /* Reads partial hash state */ > read(opfd, state, statelen); > > /* Restore from a partial hash state */ > send(opfd, state, statelen, MSG_OOB); > > /* Finalise */ > send(opfd, plain, 0, 0); > read(opfd, hash, hashlen

Re: [PATCH 00/19] RFC, v2: "New" /dev/crypto user-space interface

2010-08-24 Thread Tomas Mraz
obvious and easily utilized it is quite easier just to split the threads for crypto processing and the rest of the application directly inside the application process. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkis

Re: [PATCH 00/19] RFC, v2: "New" /dev/crypto user-space interface

2010-08-22 Thread Tomas Mraz
patched to use the kernel API in case they are configured to. By default they will still be using their internal implementation of the cryptographic algorithms. Of course there still might be some applications (for example glibc libcrypt password hashing) that decide