linux-kernel - Re: [PATCH 0/3] enable CAAM's HWRNG as default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHQ1cqGAtw5UVqGbr-05Tg0V9bXRRyP6SjqrXCiuwmLbgRrOBA@mail.gmail.com>
Date:   Tue, 12 Nov 2019 07:13:02 -0800
From:   Andrey Smirnov <andrew.smirnov@...il.com>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Lucas Stach <l.stach@...gutronix.de>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@...r.kernel.org>, Chris Healy <cphealy@...il.com>,
        Horia Geantă <horia.geanta@....com>,
        Iuliana Prodan <iuliana.prodan@....com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/3] enable CAAM's HWRNG as default

On Fri, Nov 8, 2019 at 7:19 AM Herbert Xu <herbert@...dor.apana.org.au> wrote:
>
> On Tue, Oct 29, 2019 at 12:58:24PM -0700, Andrey Smirnov wrote:
> >
> > > I'm not sure if we can ever use the job based RNG interface to hook it
> > > up to the Linux HWRNG interface. After all the job based RNG interface
> > > is always a DRNG, which only gets seeded by the TRNG. The reseed
> > > interval is given in number of clock cycles, so there is no clear
> > > correlation between really true random input bits and the number of
> > > DRNG output bits.
> >
> > Doesn't enabling prediction resistance gives us that correlation? E.g.
> > that every time new random data is generated, DRNG is reseeded? I am
> > assuming even if this is true we'd have to significantly limit
> > generated data length (< seed length?), so maybe what you propose
> > below is still simpler.
>
> Prediction resistance should be sufficient in general.  However,
> is the prediction resistance reseeding done in real time?
>

If I am reading the datasheet right reseeding should be done every
time CAAM is asked to generated random data.

> > > I've hacked up some proof of concept code which uses the TRNG access in
> > > the control interface to get the raw TRNG random bits. This seems to
> > > yield about 6400 bit/s of true entropy. It may be better to use this
> > > interface to hook up to the Linux HWRNG framework.
> >
> > OK, I'll take a look into that and send out a v2 with results.
>
> I've backed out the patch-set for now but if we can clarify the
> prediction resistance implementation details then I'm happy to
> put it back in.

Even if prediction resistance is an acceptable approach, would it be
better to expose underlying TRNG and downgrade current CAAM hwrng code
to crypto rng API? If that's the best path forward, I am more than
happy to go that way in v2.

Thanks,
Andrey Smirnov