Re: Testing the PRNG driver of the Allwinner Security System A20
On 07/03/14 01:06, Sandy Harris wrote: On Tue, Jul 1, 2014 at 7:14 AM, Corentin LABBE clabbe.montj...@gmail.com wrote: I am writing the PRNG driver for the Allwinner Security System SoC A20. The datasheet my search turned up (v1, Feb. 2013) just says: 160-bit hardware PRNG with 192-bit seed and gives no other details. Do you have more info, perhaps from a more recent version or talking to the company? The datasheet I used give some register info, just enough for having some random number out of the device. I didn't know how to test it, so ... Unless you have much more info, I see no point in enabling it or writing a driver. You need a true hardware RNG to seed it, so you need random(4) /dev/random anyway and can just use /dev/urandom for PRNG requirements. Using this device might have an advantage if it is much faster or less resource-hungry than urandom, but I see nothing in its documentation that indicates it is. Anyway, do your applications need that? And, if so, would an application-specific PRNG be better yet? Then there is the crucial question of trusting the device. Kerckhoff's Principle (http://en.citizendium.org/wiki/Kerckhoffs%27_Principle) has been a maxim for cryptographers since the 19th century; no-one should even consider trusting it until full design details are made public and reviewed. Even then, there might be serious doubts, since hardware can be very subtly sabotaged and an RNG is a tempting target for an intelligence agency. (http://arstechnica.com/security/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/) That article discusses Intel and the NSA, but similar worries apply elsewhere. Allwinner is a fabless company, so you also need to worry about whatever fab they use. The question of trusting is the reason that my preliminary driver made the PRNG optionnal and I think the next version will be without it. But for people who do not care (or do not have a real RNG requirement), the output speed is better than /dev/urandom Here is a comparison of the output speed of rng-test: with /dev/urandom rngtest: input channel speed: (min=623.523; avg=17402.670; max=3906250.000)Kibits/s with /dev/hwrng and ss-rng/sunxi-ss loaded rngtest: input channel speed: (min=1.193; avg=113.604; max=4768.372)Mibits/s So an average speed gain of x5 Apart from trusting, does the results of rng-test are good enough ? Thanks for your answer Regards -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Testing the PRNG driver of the Allwinner Security System A20
On Tue, Jul 1, 2014 at 7:14 AM, Corentin LABBE clabbe.montj...@gmail.com wrote: I am writing the PRNG driver for the Allwinner Security System SoC A20. The datasheet my search turned up (v1, Feb. 2013) just says: 160-bit hardware PRNG with 192-bit seed and gives no other details. Do you have more info, perhaps from a more recent version or talking to the company? I didn't know how to test it, so ... Unless you have much more info, I see no point in enabling it or writing a driver. You need a true hardware RNG to seed it, so you need random(4) /dev/random anyway and can just use /dev/urandom for PRNG requirements. Using this device might have an advantage if it is much faster or less resource-hungry than urandom, but I see nothing in its documentation that indicates it is. Anyway, do your applications need that? And, if so, would an application-specific PRNG be better yet? Then there is the crucial question of trusting the device. Kerckhoff's Principle (http://en.citizendium.org/wiki/Kerckhoffs%27_Principle) has been a maxim for cryptographers since the 19th century; no-one should even consider trusting it until full design details are made public and reviewed. Even then, there might be serious doubts, since hardware can be very subtly sabotaged and an RNG is a tempting target for an intelligence agency. (http://arstechnica.com/security/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/) That article discusses Intel and the NSA, but similar worries apply elsewhere. Allwinner is a fabless company, so you also need to worry about whatever fab they use. -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Testing the PRNG driver of the Allwinner Security System A20
Hello
I am writing the PRNG driver for the Allwinner Security System SoC A20.
I didn't know how to test it, so I have found that char/hw_random/exynos-rng.c
exposes a PRNG via the hwrng interfaces.
So I have written a HWRNG driver that use the SS PRNG via the crypto API
(crypto_alloc_rng/crypto_rng_reset/crypto_rng_get_bytes)
I have attached the code in case of...
The problem is that rngtest show some failures.
cat /dev/hwrng | rngtest
rngtest: bits received from input: 1876960032
rngtest: FIPS 140-2 successes: 93771
rngtest: FIPS 140-2 failures: 77
rngtest: FIPS 140-2(2001-10-10) Monobit: 15
rngtest: FIPS 140-2(2001-10-10) Poker: 11
rngtest: FIPS 140-2(2001-10-10) Runs: 30
rngtest: FIPS 140-2(2001-10-10) Long run: 22
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=979.894; avg=109756.722;
max=4882812.500)Kibits/s
rngtest: FIPS tests speed: (min=1.309; avg=32.191; max=39.986)Mibits/s
rngtest: Program run time: 72523286 microseconds
So I have questions:
- Does the use of a HWRNG driver for exposing the PRNG is a good idea ?
- Could I think the PRNG is good enough with the result of rngtest ?
Bests regards
/*
* ss-rng.c - Random Number Generator driver for the Security System
*/
#include linux/hw_random.h
#include linux/kernel.h
#include linux/module.h
#include crypto/rng.h
struct ss_rng_ctx {
struct hwrng rng;
struct crypto_rng *cr;
};
static struct ss_rng_ctx ss_rng;
#define SS_SEED_LEN (192/8)
static int ss_rng_init(struct hwrng *rng)
{
int i;
u8 seed[SS_SEED_LEN];
u32 *s = (u32 *)seed;
for (i = 0 ; i SS_SEED_LEN/4 ; i++)
s[i] = jiffies;
crypto_rng_reset(ss_rng.cr, seed, SS_SEED_LEN);
return 0;
}
static int ss_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
{
return crypto_rng_get_bytes(ss_rng.cr, buf, max);
}
static int ss_rng_probe(void)
{
int err;
struct crypto_rng *rng;
const char *name;
rng = crypto_alloc_rng(stdrng, 0, 0);
err = PTR_ERR(rng);
if (IS_ERR(rng))
return err;
name = crypto_tfm_alg_driver_name(crypto_rng_tfm(rng));
if (strcmp(name, rng-sunxi-ss) != 0) {
pr_err(ERROR: Cannot get Security System PRNG, but got %s
instead\n, name);
crypto_free_rng(rng);
return -ENODEV;
}
ss_rng.cr = rng;
ss_rng.rng.name = Security System HWRNG;
ss_rng.rng.init = ss_rng_init;
ss_rng.rng.read = ss_rng_read;
err = hwrng_register(ss_rng.rng);
if (err != 0) {
crypto_free_rng(ss_rng.cr);
}
return err;
}
static void ss_rng_remove(void)
{
hwrng_unregister(ss_rng.rng);
crypto_free_rng(ss_rng.cr);
}
module_init(ss_rng_probe);
module_exit(ss_rng_remove);
MODULE_DESCRIPTION(Allwinner Security System H/W Random Number Generator
driver);
MODULE_AUTHOR(Corentin LABBE clabbe.montj...@gmail.com);
MODULE_LICENSE(GPL);
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
