2015-08-17 07:36:12 +00:00
|
|
|
/*-
|
2018-08-26 12:51:46 +00:00
|
|
|
* Copyright (c) 2015-2018 Mark R V Murray
|
2015-08-17 07:36:12 +00:00
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* Redistribution and use in source and binary forms, with or without
|
|
|
|
* modification, are permitted provided that the following conditions
|
|
|
|
* are met:
|
|
|
|
* 1. Redistributions of source code must retain the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer
|
|
|
|
* in this position and unchanged.
|
|
|
|
* 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
* notice, this list of conditions and the following disclaimer in the
|
|
|
|
* documentation and/or other materials provided with the distribution.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
|
|
|
|
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
|
|
|
|
* IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
|
|
|
|
* INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
|
|
|
|
* NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
* THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
|
|
|
|
* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*-
|
|
|
|
* This is a skeleton for folks who wish to build a loadable module
|
|
|
|
* containing an alternative entropy-processing algorithm for random(4).
|
|
|
|
*
|
|
|
|
* The functions below should be completed with the appropriate code,
|
2018-08-26 12:51:46 +00:00
|
|
|
* and the nearby fortuna.c may be consulted for examples of working code.
|
2015-08-17 07:36:12 +00:00
|
|
|
*
|
|
|
|
* The author is willing to provide reasonable help to those wishing to
|
|
|
|
* write such a module for themselves. Please use the markm@ FreeBSD
|
|
|
|
* email address, and ensure that you are developing this on a suitably
|
2018-08-26 12:51:46 +00:00
|
|
|
* supported branch (This is currently 12-CURRENT, and may be no
|
|
|
|
* older than 12-STABLE in the future).
|
2015-08-17 07:36:12 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <sys/cdefs.h>
|
|
|
|
__FBSDID("$FreeBSD$");
|
|
|
|
|
2018-08-26 12:51:46 +00:00
|
|
|
#include <sys/limits.h>
|
|
|
|
|
|
|
|
#ifdef _KERNEL
|
2015-08-17 07:36:12 +00:00
|
|
|
#include <sys/param.h>
|
|
|
|
#include <sys/kernel.h>
|
|
|
|
#include <sys/lock.h>
|
|
|
|
#include <sys/malloc.h>
|
|
|
|
#include <sys/mutex.h>
|
|
|
|
#include <sys/random.h>
|
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#include <sys/systm.h>
|
|
|
|
|
|
|
|
#include <machine/cpu.h>
|
|
|
|
|
|
|
|
#include <crypto/rijndael/rijndael-api-fst.h>
|
2015-12-27 17:33:59 +00:00
|
|
|
#include <crypto/sha2/sha256.h>
|
2015-08-17 07:36:12 +00:00
|
|
|
|
|
|
|
#include <dev/random/hash.h>
|
|
|
|
#include <dev/random/randomdev.h>
|
|
|
|
#include <dev/random/random_harvestq.h>
|
|
|
|
#include <dev/random/uint128.h>
|
|
|
|
#include <dev/random/other_algorithm.h>
|
2018-08-26 12:51:46 +00:00
|
|
|
#else /* !_KERNEL */
|
|
|
|
#include <inttypes.h>
|
|
|
|
#include <stdbool.h>
|
|
|
|
#include <stdio.h>
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <threads.h>
|
|
|
|
|
|
|
|
#include "unit_test.h"
|
|
|
|
|
|
|
|
#include <crypto/rijndael/rijndael-api-fst.h>
|
|
|
|
#include <crypto/sha2/sha256.h>
|
|
|
|
|
|
|
|
#include <dev/random/hash.h>
|
|
|
|
#include <dev/random/randomdev.h>
|
|
|
|
#include <dev/random/uint128.h>
|
|
|
|
#include <dev/random/other_algorithm.h>
|
|
|
|
#endif /* _KERNEL */
|
2015-08-17 07:36:12 +00:00
|
|
|
|
|
|
|
static void random_other_pre_read(void);
|
random(4): Generalize algorithm-independent APIs
At a basic level, remove assumptions about the underlying algorithm (such as
output block size and reseeding requirements) from the algorithm-independent
logic in randomdev.c. Chacha20 does not have many of the restrictions that
AES-ICM does as a PRF (Pseudo-Random Function), because it has a cipher
block size of 512 bits. The motivation is that by generalizing the API,
Chacha is not penalized by the limitations of AES.
In READ_RANDOM_UIO, first attempt to NOWAIT allocate a large enough buffer
for the entire user request, or the maximal input we'll accept between
signal checking, whichever is smaller. The idea is that the implementation
of any randomdev algorithm is then free to divide up large requests in
whatever fashion it sees fit.
As part of this, two responsibilities from the "algorithm-generic" randomdev
code are pushed down into the Fortuna ra_read implementation (and any other
future or out-of-tree ra_read implementations):
1. If an algorithm needs to rekey every N bytes, it is responsible for
handling that in ra_read(). (I.e., Fortuna's 1MB rekey interval for AES
block generation.)
2. If an algorithm uses a block cipher that doesn't tolerate partial-block
requests (again, e.g., AES), it is also responsible for handling that in
ra_read().
Several APIs are changed from u_int buffer length to the more canonical
size_t. Several APIs are changed from taking a blockcount to a bytecount,
to permit PRFs like Chacha20 to directly generate quantities of output that
are not multiples of RANDOM_BLOCKSIZE (AES block size).
The Fortuna algorithm is changed to NOT rekey every 1MiB when in Chacha20
mode (kern.random.use_chacha20_cipher="1"). This is explicitly supported by
the math in FS&K §9.4 (Ferguson, Schneier, and Kohno; "Cryptography
Engineering"), as well as by their conclusion: "If we had a block cipher
with a 256-bit [or greater] block size, then the collisions would not
have been an issue at all."
For now, continue to break up reads into PAGE_SIZE chunks, as they were
before. So, no functional change, mostly.
Reviewed by: markm
Approved by: secteam(delphij)
Differential Revision: https://reviews.freebsd.org/D20312
2019-06-17 15:09:12 +00:00
|
|
|
static void random_other_read(uint8_t *, size_t);
|
2015-08-17 07:36:12 +00:00
|
|
|
static bool random_other_seeded(void);
|
|
|
|
static void random_other_process_event(struct harvest_event *);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* RANDOM_OTHER_NPOOLS is used when reading hardware random
|
|
|
|
* number sources to ensure that each pool gets one read sample
|
2018-08-26 12:51:46 +00:00
|
|
|
* per loop iteration. Fortuna has 32 (0-31).
|
2015-08-17 07:36:12 +00:00
|
|
|
*/
|
|
|
|
#define RANDOM_OTHER_NPOOLS 1
|
|
|
|
|
2019-12-26 19:32:11 +00:00
|
|
|
#ifdef RANDOM_LOADABLE
|
|
|
|
static
|
|
|
|
#endif
|
|
|
|
const struct random_algorithm random_alg_context = {
|
2015-08-17 07:36:12 +00:00
|
|
|
.ra_ident = "other",
|
|
|
|
.ra_pre_read = random_other_pre_read,
|
|
|
|
.ra_read = random_other_read,
|
|
|
|
.ra_seeded = random_other_seeded,
|
|
|
|
.ra_event_processor = random_other_process_event,
|
|
|
|
.ra_poolcount = RANDOM_OTHER_NPOOLS,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Use a mutex to protect your reseed variables? */
|
|
|
|
static mtx_t other_mtx;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Do algorithm-specific initialisation here.
|
|
|
|
*/
|
2019-12-26 19:32:11 +00:00
|
|
|
static void
|
2015-08-17 07:36:12 +00:00
|
|
|
random_other_init_alg(void *unused __unused)
|
|
|
|
{
|
|
|
|
|
2019-12-26 19:32:11 +00:00
|
|
|
#ifdef RANDOM_LOADABLE
|
|
|
|
p_random_alg_context = &random_alg_context;
|
|
|
|
#endif
|
2015-08-17 07:36:12 +00:00
|
|
|
|
2019-12-26 19:32:11 +00:00
|
|
|
RANDOM_RESEED_INIT_LOCK();
|
2015-08-17 07:36:12 +00:00
|
|
|
}
|
2019-12-26 19:32:11 +00:00
|
|
|
SYSINIT(random_alg, SI_SUB_RANDOM, SI_ORDER_SECOND, random_other_init_alg,
|
|
|
|
NULL);
|
2015-08-17 07:36:12 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* void random_other_pre_read(void)
|
|
|
|
*
|
|
|
|
* Do any pre-read preparation you need to. This will be called
|
|
|
|
* before >=1 calls to random_other_read() corresponding to one
|
|
|
|
* read(2).
|
|
|
|
*
|
|
|
|
* This routine will be called periodically while the generator is
|
|
|
|
* still blocked and a read is being attempted, giving you an
|
|
|
|
* opportunity to unblock.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
random_other_pre_read(void)
|
|
|
|
{
|
|
|
|
|
|
|
|
RANDOM_RESEED_LOCK();
|
|
|
|
/*
|
|
|
|
* Do pre-read housekeeping work here!
|
|
|
|
* You may use this as a chance to unblock the generator.
|
|
|
|
*/
|
|
|
|
RANDOM_RESEED_UNLOCK();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
random(4): Generalize algorithm-independent APIs
At a basic level, remove assumptions about the underlying algorithm (such as
output block size and reseeding requirements) from the algorithm-independent
logic in randomdev.c. Chacha20 does not have many of the restrictions that
AES-ICM does as a PRF (Pseudo-Random Function), because it has a cipher
block size of 512 bits. The motivation is that by generalizing the API,
Chacha is not penalized by the limitations of AES.
In READ_RANDOM_UIO, first attempt to NOWAIT allocate a large enough buffer
for the entire user request, or the maximal input we'll accept between
signal checking, whichever is smaller. The idea is that the implementation
of any randomdev algorithm is then free to divide up large requests in
whatever fashion it sees fit.
As part of this, two responsibilities from the "algorithm-generic" randomdev
code are pushed down into the Fortuna ra_read implementation (and any other
future or out-of-tree ra_read implementations):
1. If an algorithm needs to rekey every N bytes, it is responsible for
handling that in ra_read(). (I.e., Fortuna's 1MB rekey interval for AES
block generation.)
2. If an algorithm uses a block cipher that doesn't tolerate partial-block
requests (again, e.g., AES), it is also responsible for handling that in
ra_read().
Several APIs are changed from u_int buffer length to the more canonical
size_t. Several APIs are changed from taking a blockcount to a bytecount,
to permit PRFs like Chacha20 to directly generate quantities of output that
are not multiples of RANDOM_BLOCKSIZE (AES block size).
The Fortuna algorithm is changed to NOT rekey every 1MiB when in Chacha20
mode (kern.random.use_chacha20_cipher="1"). This is explicitly supported by
the math in FS&K §9.4 (Ferguson, Schneier, and Kohno; "Cryptography
Engineering"), as well as by their conclusion: "If we had a block cipher
with a 256-bit [or greater] block size, then the collisions would not
have been an issue at all."
For now, continue to break up reads into PAGE_SIZE chunks, as they were
before. So, no functional change, mostly.
Reviewed by: markm
Approved by: secteam(delphij)
Differential Revision: https://reviews.freebsd.org/D20312
2019-06-17 15:09:12 +00:00
|
|
|
* void random_other_read(uint8_t *buf, size_t count)
|
2015-08-17 07:36:12 +00:00
|
|
|
*
|
|
|
|
* Generate <count> bytes of output into <*buf>.
|
random(4): Generalize algorithm-independent APIs
At a basic level, remove assumptions about the underlying algorithm (such as
output block size and reseeding requirements) from the algorithm-independent
logic in randomdev.c. Chacha20 does not have many of the restrictions that
AES-ICM does as a PRF (Pseudo-Random Function), because it has a cipher
block size of 512 bits. The motivation is that by generalizing the API,
Chacha is not penalized by the limitations of AES.
In READ_RANDOM_UIO, first attempt to NOWAIT allocate a large enough buffer
for the entire user request, or the maximal input we'll accept between
signal checking, whichever is smaller. The idea is that the implementation
of any randomdev algorithm is then free to divide up large requests in
whatever fashion it sees fit.
As part of this, two responsibilities from the "algorithm-generic" randomdev
code are pushed down into the Fortuna ra_read implementation (and any other
future or out-of-tree ra_read implementations):
1. If an algorithm needs to rekey every N bytes, it is responsible for
handling that in ra_read(). (I.e., Fortuna's 1MB rekey interval for AES
block generation.)
2. If an algorithm uses a block cipher that doesn't tolerate partial-block
requests (again, e.g., AES), it is also responsible for handling that in
ra_read().
Several APIs are changed from u_int buffer length to the more canonical
size_t. Several APIs are changed from taking a blockcount to a bytecount,
to permit PRFs like Chacha20 to directly generate quantities of output that
are not multiples of RANDOM_BLOCKSIZE (AES block size).
The Fortuna algorithm is changed to NOT rekey every 1MiB when in Chacha20
mode (kern.random.use_chacha20_cipher="1"). This is explicitly supported by
the math in FS&K §9.4 (Ferguson, Schneier, and Kohno; "Cryptography
Engineering"), as well as by their conclusion: "If we had a block cipher
with a 256-bit [or greater] block size, then the collisions would not
have been an issue at all."
For now, continue to break up reads into PAGE_SIZE chunks, as they were
before. So, no functional change, mostly.
Reviewed by: markm
Approved by: secteam(delphij)
Differential Revision: https://reviews.freebsd.org/D20312
2019-06-17 15:09:12 +00:00
|
|
|
* You may NOT use the fact that <count> will be a multiple of
|
2015-08-17 07:36:12 +00:00
|
|
|
* RANDOM_BLOCKSIZE for optimization purposes.
|
|
|
|
*
|
|
|
|
* This function will always be called with your generator
|
|
|
|
* unblocked and ready. If you are not ready to generate
|
|
|
|
* output here, then feel free to KASSERT() or panic().
|
|
|
|
*/
|
|
|
|
static void
|
random(4): Generalize algorithm-independent APIs
At a basic level, remove assumptions about the underlying algorithm (such as
output block size and reseeding requirements) from the algorithm-independent
logic in randomdev.c. Chacha20 does not have many of the restrictions that
AES-ICM does as a PRF (Pseudo-Random Function), because it has a cipher
block size of 512 bits. The motivation is that by generalizing the API,
Chacha is not penalized by the limitations of AES.
In READ_RANDOM_UIO, first attempt to NOWAIT allocate a large enough buffer
for the entire user request, or the maximal input we'll accept between
signal checking, whichever is smaller. The idea is that the implementation
of any randomdev algorithm is then free to divide up large requests in
whatever fashion it sees fit.
As part of this, two responsibilities from the "algorithm-generic" randomdev
code are pushed down into the Fortuna ra_read implementation (and any other
future or out-of-tree ra_read implementations):
1. If an algorithm needs to rekey every N bytes, it is responsible for
handling that in ra_read(). (I.e., Fortuna's 1MB rekey interval for AES
block generation.)
2. If an algorithm uses a block cipher that doesn't tolerate partial-block
requests (again, e.g., AES), it is also responsible for handling that in
ra_read().
Several APIs are changed from u_int buffer length to the more canonical
size_t. Several APIs are changed from taking a blockcount to a bytecount,
to permit PRFs like Chacha20 to directly generate quantities of output that
are not multiples of RANDOM_BLOCKSIZE (AES block size).
The Fortuna algorithm is changed to NOT rekey every 1MiB when in Chacha20
mode (kern.random.use_chacha20_cipher="1"). This is explicitly supported by
the math in FS&K §9.4 (Ferguson, Schneier, and Kohno; "Cryptography
Engineering"), as well as by their conclusion: "If we had a block cipher
with a 256-bit [or greater] block size, then the collisions would not
have been an issue at all."
For now, continue to break up reads into PAGE_SIZE chunks, as they were
before. So, no functional change, mostly.
Reviewed by: markm
Approved by: secteam(delphij)
Differential Revision: https://reviews.freebsd.org/D20312
2019-06-17 15:09:12 +00:00
|
|
|
random_other_read(uint8_t *buf, size_t count)
|
2015-08-17 07:36:12 +00:00
|
|
|
{
|
|
|
|
|
|
|
|
RANDOM_RESEED_LOCK();
|
|
|
|
/*
|
|
|
|
* Do random-number generation work here!
|
|
|
|
*/
|
|
|
|
RANDOM_RESEED_UNLOCK();
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* bool random_other_seeded(void)
|
|
|
|
*
|
|
|
|
* Return true if your generator is ready to generate
|
|
|
|
* output, and false otherwise.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
random_other_seeded(void)
|
|
|
|
{
|
|
|
|
bool seeded = false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find out if your generator is seeded here!
|
|
|
|
*/
|
|
|
|
return (seeded);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* void random_other_process_event(struct harvest_event *event)
|
|
|
|
*
|
|
|
|
* Process one stochastic event <*event> into your entropy
|
|
|
|
* processor.
|
|
|
|
*
|
|
|
|
* The structure of the event may change, so it is easier to
|
|
|
|
* just grab the whole thing into your accumulation system.
|
|
|
|
* You may pick-and-choose bits, but please don't complain
|
|
|
|
* when/if these change.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
random_other_process_event(struct harvest_event *event)
|
|
|
|
{
|
|
|
|
|
|
|
|
RANDOM_RESEED_LOCK();
|
|
|
|
/*
|
|
|
|
* Do entropy accumulation work here!
|
|
|
|
* You may use this as a chance to unblock the generator.
|
|
|
|
*/
|
|
|
|
RANDOM_RESEED_UNLOCK();
|
|
|
|
}
|