74 lines
3.1 KiB
Text
74 lines
3.1 KiB
Text
Debian specific notes regarding haveged
|
||
=======================================
|
||
|
||
Concerns regarding the RDTSC instructions in virtualized environments
|
||
---------------------------------------------------------------------
|
||
|
||
PolarSSL issued a security advisory on 2011-12-05 regarding their
|
||
implementation of the HAVEGE random generator and virtualized environment:
|
||
<https://polarssl.org/tech-updates/security-advisories/polarssl-security-advisory-2011-02>
|
||
|
||
When asked if the issue also applied to haveged, Gary Wuertz — haveged author —
|
||
replied:
|
||
|
||
First, there are significant differences between the polarssl and haveged
|
||
implementations of HAVEGE. In general, haveged works much harder to provoke
|
||
timing variations in the host (larger collection buffer, tuning collection code
|
||
and walk table to the host L1 caches). See comparison below.
|
||
I think items d) and e) in the comparison are items where polarssl is
|
||
particularly weak.
|
||
|
||
Second, since V1.5 haveged includes run time testing of haveged output. This is
|
||
the only definitive way to deal with a poor timing source (virtual or
|
||
otherwise). The test procedures are adapted from the German CC body, see:
|
||
http://www.issihosts.com/haveged/ais31.html
|
||
|
||
By default, AIS procedures A and B are run at start up and AIS procedure B is
|
||
run continuously by the daemon. Procedure A is intended to detect statistical
|
||
anomalies - it includes running the FIPS140-1 tests 257 times on successive
|
||
20,000 bit samples and an auto-correlation test. Procedure B runs a series of
|
||
bit distribution tests of a more theoretical nature, terminating with an
|
||
entropy estimate on a 256000+2560 bit sample using Coron's estimator.
|
||
Dispensing with procedure A during continuous tests is a performance
|
||
enhancement. haveged output gets mixed with other sources in /dev/random and as
|
||
long as haveged does not lie about the entropy it is feeding into the pool, all
|
||
should be fine.
|
||
|
||
AIS31 defines a retry strategy that a ideal generator should never fail, so any
|
||
haveged testing failure terminates output. Note that the test procedures
|
||
are not synchronized with collection but all haveged output is guaranteed to
|
||
come from a buffer not containing any failed individual test.
|
||
|
||
Comparison of the polarssl and haveged implementations of HAVEGE
|
||
|
||
a) Both use approximately the same collection code:
|
||
|
||
* PolarSSL: havege.c inline macro
|
||
* haveged: oniteration.h
|
||
|
||
b) Adaptation of collection code to host:
|
||
|
||
* PolarSSL: static
|
||
- collection buffer: 1024*sizeof(int),
|
||
- walk table: 8192 * sizeof(int),
|
||
- fill loop: 4 iterations
|
||
* haveged: dynamic (built in tuning or invocation parameters)
|
||
- collection buffer: 512*1024*sizeof(int32) (default, adjustable),
|
||
- walk table: (4K *sizeof(int32)) + (2 * size of L1 data cache) ,
|
||
- fill loop: number of iterations in that fit in a minimum of L1 instruction
|
||
cache or 64K (approximately)
|
||
|
||
c) Timer source
|
||
|
||
* PolarSSL: hardware cycle counter, gettimeofday() fallback
|
||
* haveged: hardware cycle counter, clock_gettime() fallback
|
||
|
||
d) Collector warmup
|
||
|
||
* PolarSSL: 1 fill
|
||
* haveged: 32 fills plus self test
|
||
|
||
e) Run time testing
|
||
|
||
* PolarSSL: none
|
||
* haveged: Continuous and start-up AIS-31 tests (configurable)
|