Hi,
I looked at Exynos Pseudo Random Nubmer Generator driver
(drivers/char/hw_random/exynos-rng.c) and noticed that it always seeds
the device with jiffies. Then I looked at few other drivers and found
that they do not seed themself (or at least I couldn't find this).
I think the hw_random API does not provide generic infrastructure for
seeding.
What is the preferred approach for seeding a PRNG device? Use jiffies or
a fixed value?
Or maybe the interface should be abandoned in favor of crypto API?
Best regards,
Krzysztof
> I looked at Exynos Pseudo Random Nubmer Generator driver
> (drivers/char/hw_random/exynos-rng.c) and noticed that it always seeds
> the device with jiffies. Then I looked at few other drivers and found
> that they do not seed themself (or at least I couldn't find this).
HW random interface is meant for true RNG, not pseudo RNG. Actually
PRNGs should use AF_ALG interface. I think exynos-rng.c should follow
the same.
> I think the hw_random API does not provide generic infrastructure for
> seeding.
>
> What is the preferred approach for seeding a PRNG device? Use jiffies or
> a fixed value?
>
> Or maybe the interface should be abandoned in favor of crypto API?
AF_ALG interface for rng does have seeding support. I think hw_random
does not provide seeding support intentionally as I understand that
True RNG need not require seeding (please correct me if I am wrong).
Regards,
PrasannaKumar
On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
>
> AF_ALG interface for rng does have seeding support. I think hw_random
> does not provide seeding support intentionally as I understand that
> True RNG need not require seeding (please correct me if I am wrong).
Yes. We should be converting PRNGs in hwrng over to algif_rng.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Am Montag, 20. M?rz 2017, 14:28:58 CET schrieb Herbert Xu:
Hi Herbert,
> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
> > AF_ALG interface for rng does have seeding support. I think hw_random
> > does not provide seeding support intentionally as I understand that
> > True RNG need not require seeding (please correct me if I am wrong).
>
> Yes. We should be converting PRNGs in hwrng over to algif_rng.
IMHO this not only applies to the PRNGs in drivers/crypto (which should simply
register with crypto_register_rngs) but also to ~/hacking/sources/linux/arch/
s390/crypto/prng.c which exports a /dev/prandom file.
For the seeding, it may make sense to follow the example given with crypto/
drbg.c using the add_random_ready_callback function.
Ciao
Stephan
On Mon, Mar 20, 2017 at 09:28:58PM +0800, Herbert Xu wrote:
> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
> >
> > AF_ALG interface for rng does have seeding support. I think hw_random
> > does not provide seeding support intentionally as I understand that
> > True RNG need not require seeding (please correct me if I am wrong).
>
> Yes. We should be converting PRNGs in hwrng over to algif_rng.
The actual hardware block can be seeded from true RNG (taking data
from thermal noise) so the solutions (if I understand correctly) for
exynos-rng might be:
1. Seed from internal TRNG making it a proper hwrandom device,
2. Convert to AF_ALG and seed with data from user-space through that
interface.
Thanks for explanation, I'll queue it to my tasks list.
Best regards,
Krzysztof
On 03/20/2017 02:39 PM, Stephan M?ller wrote:
> Am Montag, 20. M?rz 2017, 14:28:58 CET schrieb Herbert Xu:
>
> Hi Herbert,
>
>> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
>>> AF_ALG interface for rng does have seeding support. I think hw_random
>>> does not provide seeding support intentionally as I understand that
>>> True RNG need not require seeding (please correct me if I am wrong).
>> Yes. We should be converting PRNGs in hwrng over to algif_rng.
> IMHO this not only applies to the PRNGs in drivers/crypto (which should simply
> register with crypto_register_rngs) but also to ~/hacking/sources/linux/arch/
> s390/crypto/prng.c which exports a /dev/prandom file.
>
> For the seeding, it may make sense to follow the example given with crypto/
> drbg.c using the add_random_ready_callback function.
>
> Ciao
> Stephan
>
I'll have a look on it. Currently the s390/crypto/prng seeds itself with
an algorithm based on the jitter of the very fine granular hardware
clock of a s390 machine. There were some thoughts and measurements
by an mathematician which let to this algorithm. However, long-term
the s390 platform will provide some kind of true hardware random number
generator and the idea is to use this for seeding the prng.
regards
Harald Freudenberger
On Mon, Mar 20, 2017 at 09:28:58PM +0800, Herbert Xu wrote:
> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
> >
> > AF_ALG interface for rng does have seeding support. I think hw_random
> > does not provide seeding support intentionally as I understand that
> > True RNG need not require seeding (please correct me if I am wrong).
>
> Yes. We should be converting PRNGs in hwrng over to algif_rng.
>
Problem with this conversion, a huge regression for user space.
Using hwrng is simple as cat /dev/hwrng.
Using algif_rng via AF_ALG is ... unusable for the moment.
Perhaps creating an user space tool (prng-tool which provide a cat /dev/hwrng replacement) is mandatory before any convertion.
Regards
On Thu, Mar 23, 2017 at 09:23:07AM +0100, Corentin Labbe wrote:
>
> Problem with this conversion, a huge regression for user space.
> Using hwrng is simple as cat /dev/hwrng.
> Using algif_rng via AF_ALG is ... unusable for the moment.
> Perhaps creating an user space tool (prng-tool which provide a cat /dev/hwrng replacement) is mandatory before any convertion.
Stephan may have a tool to do this. Stephan?
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Am Donnerstag, 23. M?rz 2017, 09:03:23 CET schrieb Harald Freudenberger:
Hi Harald,
> I'll have a look on it. Currently the s390/crypto/prng seeds itself with
> an algorithm based on the jitter of the very fine granular hardware
> clock of a s390 machine. There were some thoughts and measurements
> by an mathematician which let to this algorithm.
It takes a page and simply writes 512 times the high-res time stamp using
get_tod_clock_fast into it. Effectively it uses the same fundamental noise
source as the jitterentropy. (A couple of months ago I had to perform an
SP800-90B assessment on exactly that code path. :-) )
> However, long-term
> the s390 platform will provide some kind of true hardware random number
> generator and the idea is to use this for seeding the prng.
The question is just that it provides a device file nobody else provides. And
the question is whether to consolidate it. If it is a DRNG, the discussion is
about consolidating it behind AF_ALG. If it is an RNG with its own noise
source (i.e. it provides entropic data by itself), it should rather be placed
into drivers/char/hw_random and use the hw-random framework. This framework
will also ensure that it may seed the /dev/random device kernel-internally.
Ciao
Stephan
Am Donnerstag, 23. M?rz 2017, 10:44:06 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Mar 23, 2017 at 09:23:07AM +0100, Corentin Labbe wrote:
> > Problem with this conversion, a huge regression for user space.
> > Using hwrng is simple as cat /dev/hwrng.
> > Using algif_rng via AF_ALG is ... unusable for the moment.
> > Perhaps creating an user space tool (prng-tool which provide a cat
> > /dev/hwrng replacement) is mandatory before any convertion.
> Stephan may have a tool to do this. Stephan?
Creating such tool is more or less trivial. It simply requires the invocation
of kcapi_rng_init, kcapi_rng_seed, kcapi_rng_generate and eventually
kcapi_rng_destroy from [1]. I can write such a tool if requested.
I see one change we need to add to algif_rng.c: currently the caller must
provide the specific name of the DRNG to be used. With such a tool, the caller
does not care about the type of DRNG. Thus, rng_bind should be changed such
that if name is NULL, it should use crypto_get_default_rng(). This would
alleviate the caller from selecting "the right" DRNG.
[1] http://www.chronox.de/libkcapi.html
Ciao
Stephan
Am Donnerstag, 23. M?rz 2017, 10:44:06 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Mar 23, 2017 at 09:23:07AM +0100, Corentin Labbe wrote:
> > Problem with this conversion, a huge regression for user space.
> > Using hwrng is simple as cat /dev/hwrng.
> > Using algif_rng via AF_ALG is ... unusable for the moment.
> > Perhaps creating an user space tool (prng-tool which provide a cat
> > /dev/hwrng replacement) is mandatory before any convertion.
> Stephan may have a tool to do this. Stephan?
Here is a suggestion for such a tool that I could add to libkcapi. Naturally,
this code is only a demonstrator which lacks some features.
Ciao
Stephan
Am Donnerstag, 23. M?rz 2017, 10:44:06 CEST schrieb Herbert Xu:
Hi Herbert,
> On Thu, Mar 23, 2017 at 09:23:07AM +0100, Corentin Labbe wrote:
> > Problem with this conversion, a huge regression for user space.
> > Using hwrng is simple as cat /dev/hwrng.
> > Using algif_rng via AF_ALG is ... unusable for the moment.
> > Perhaps creating an user space tool (prng-tool which provide a cat
> > /dev/hwrng replacement) is mandatory before any convertion.
> Stephan may have a tool to do this. Stephan?
I added the application kcapi-rng to HEAD of [1]. Create the application with
the --enable-kcapi-rngapp configure option.
$ kcapi-rng
Kernel Crypto API Random Number Gatherer
Kernel Crypto API interface library version: libkcapi pre-release 0.13.1
Reported numeric version number 130080
Usage:
-b --bytes <BYTES> Number of bytes to generate (required option)
-h --help This help information
--version Print version
-v --verbose Verbose logging, multiple options increase verbosity
Data provided at stdin is used to seed the DRNG
[1] https://github.com/smuellerDD/libkcapi/
Ciao
Stephan