On Tue, Sep 18, 2018 at 01:00:31PM -0400, Sandy Harris wrote:
> Solutions have been proposed by various people. If I understand them
> right, Ted Ts'o suggests modifying the boot loader to provide some
> entropy & John Denker suggests that every machine should be
> provisioned with some entropy in
On Fri, Aug 10, 2018 at 08:20:51AM +0200, Stephan Mueller wrote:
> > while (nbytes >= CHACHA20_BLOCK_SIZE) {
> > int adjust = (unsigned long)buf & (sizeof(tmp[0]) - 1);
> >
> > extract_crng(buf);
>
> Why this line?
>
> > buf += CHACHA20_BLOCK_SIZE;
On Thu, Aug 09, 2018 at 08:38:56PM +0200, Stephan Müller wrote:
> The function extract_crng invokes the ChaCha20 block operation directly
> on the user-provided buffer. The block operation operates on u32 words.
> Thus the extract_crng function expects the buffer to be aligned to u32
> as it is
On Wed, Jun 06, 2018 at 04:58:29PM +0200, Harald Freudenberger wrote:
> Had a short glimpse to the mentioned add_hwgenerator_randomness()
> and this looks in fact like the API I am looking for :-)
> Thanks Stephan, I'll write some code and check this out.
The more convenient interface would be
On Sun, May 27, 2018 at 01:22:05PM +0200, Rafael J. Wysocki wrote:
> Again, the PBKDF2 user would be hibernation. It could either take a key from
> user space, which would require a key-generating user-space component to be
> present in the initramfs (I guess no issue for a regular distro, but I
On Sat, May 26, 2018 at 03:36:37PM +0200, Stephan Mueller wrote:
> - security related code should be vetted (which arguably is the case when the
> discussed PBKDF is part of the kernel)
> >
> > If he/she were to add their own userland code then he would surely be
> > criticized for rolling his
On Fri, May 25, 2018 at 12:07:06PM +0200, Tomas Mraz wrote:
>
> Because having millions of copies of SHA1, MD5, and SHA2 and in
> millions of applications is the best thing.
>
> Now that's something I would call laziness - just copy the code and do
> not care about doing the proper decision
One more thought about why userspace using AF_ALG is a bad idea ---
there is no guarantee that all kernels will have all of the crypto
algorithms you need built into the kernel. People who build custom
kernels very often only include those kernel modules they need. So by
default I don't normally
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?
>
> I'm not really here to criticize or judge the past. AF_ALG exists now.
On Thu, May 24, 2018 at 05:08:41PM -0500, Denis Kenzior wrote:
> Actually for the use case we have, speed is something pretty low on the
> priority list; not having to deal with userspace crypto library dependencies
> was a goal in and of itself. Each one has its own issues and you can never
>
On Thu, May 24, 2018 at 12:11:35PM -0500, Denis Kenzior wrote:
>
> Well, I'm not sure where the laziness comment is coming from. We have at
> least two user-space implementations that implement PBKDF on top of AF_ALG.
> But a typical invocation of PBKDF runs a couple of thousand iterations.
>
On Fri, May 18, 2018 at 10:58:14AM -0700, Eric Biggers wrote:
> Log the crypto algorithm driver name for each fscrypt encryption mode on
> its first use, also showing a friendly name for the mode.
>
> This will help people determine whether the expected implementations are
> being used. In some
On Mon, May 07, 2018 at 05:22:08PM -0700, Eric Biggers wrote:
> fscrypt currently only supports AES encryption. However, many low-end
> mobile devices have older CPUs that don't have AES instructions, e.g.
> the ARMv8 Cryptography Extensions. Currently, user data on such devices
> is not
On Thu, May 17, 2018 at 08:01:04AM +0200, Christophe LEROY wrote:
>
> On a powerpc embedded board which has an mpc8xx processor running at 133Mhz,
> I now get the startup done in more than 7 minutes instead of 30 seconds.
> This is due to the webserver blocking on read on /dev/random until we get
On Wed, May 16, 2018 at 05:07:08PM -0700, Srivatsa S. Bhat wrote:
>
> On a Photon OS VM running on VMware ESXi, this patch causes a boot speed
> regression of 5 minutes :-( [ The VM doesn't have haveged or rng-tools
> (rngd) installed. ]
>
> [1.420246] EXT4-fs (sda2): re-mounted. Opts:
The following changes since commit d848e5f8e1ebdb227d045db55fe4f825e82965fa:
random: add new ioctl RNDRESEEDCRNG (2018-04-14 11:59:31 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random.git
tags/random_for_linus_stable
for you to fetch
On Tue, Apr 24, 2018 at 10:58:35PM +0200, Jason A. Donenfeld wrote:
> > Note that Linux
> > doesn't bow down to any particular standards organization, and it offers
> > algorithms that were specified in various places, even some with no more
> > than a
> > publication by the author. In fact,
On Tue, Apr 24, 2018 at 03:24:55PM +0200, Harald Freudenberger wrote:
> The condition is true and terminates the function
> when the count value of the cpu fast pool is below 64
> AND the time since last mix of the pool is lower than
> HZ (so lower than 1s).
> This means the code following this
On Fri, Apr 13, 2018 at 07:38:30AM +0200, Stephan Mueller wrote:
> > The crng_init variable has three states:
> >
> > 0: The CRNG is not initialized at all
> > 1: The CRNG has a small amount of entropy, hopefully good enough for
> >early-boot, non-cryptographical use cases
> > 2: The CRNG is
On Sun, Apr 08, 2018 at 09:07:03PM +0200, Stephan Müller wrote:
> Can you please check whether the attached patch fixes the issue?
>
Stephan,
FYI, if you incude in your e-mail "#syz test " as
the first line of your patch and the syzbot e-mail is cc'ed, the
syzbot will automatically apply the
20 matches
Mail list logo
