View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000090 | Main CAcert Website | account administration | public | 2005-11-23 08:27 | 2013-01-13 15:37 |
| Reporter | Sourcerer | Assigned To | duane | ||
| Priority | normal | Severity | block | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Fixed in Version | 2006 | ||||
| Summary | 0000090: random numbers breach the CAcert CPS | ||||
| Description | The sourcecode of CAcert contains a lot of /dev/urandom references, but according to the CPS, /dev/random must be used. This is a breach of the CPS: www/cps.php: www/cps.php: in /dev/random. www/index.php: $rnd = fopen("/dev/urandom", "r"); | ||||
| Tags | No tags attached. | ||||
| Reviewed by | |||||
| Test Instructions | |||||
|
|
The core team should decide to either send a policy-change request to the policy editor, or change the implementation |
|
|
/dev/random has a problem -- without a source of enough entropy, it blocks. /dev/urandom doesn't. After the entropy is exhausted, /dev/urandom switches to a pseudorandom number generator, the details of which I haven't looked at. The fact that a one-way hash is applied to the /dev/urandom source (which is seeded during system startup based on the last truly random information that was saved during shutdown) is, however, perfectly okay in my book. (MD5 has not been "broken" in that it can determine what the hashed value was, and in any case the MD5 from /dev/urandom could be fed back into /dev/random as a seed, as its output is still unpredictable, especially without knowing what the current value of the pseudorandom number generator is. In order to understand the issue, you must realize that /dev/random picks up the randomness inherent in network activity (the delta between packets), the delta between initiating a request for data to the hard disk and getting it back, the delta between keystrokes, and so on. For the CA, there should be no network activity to speak of, and hard disk access is only going to be for writing logs and (on relatively rare occasions) signing a certificate request. (I don't know if the serial driver feeds entropy into /dev/random, but even if it did I don't think it would be particularly entropic.) Now, if someone wanted to be particularly paranoid about it (note: I use the word 'paranoid' because a good security team is -- you have to win every attack vector, while your adversary only has to win one), they could take the implementation of the FIPS-120-2 random number generator from the latest CVS snapshot of OpenSSL 0.9.7, and instead of using MD5 for the generation of the pseudorandom numbers, use that instead. It has a long enough period and an appropriate level of inability to determine its internal state that it can effectively be used as a source of entropy to feed to /dev/random if reading it would block. (A proper implementation of this would, every time /dev/random is read, add that result to the tail of a circular queue of approximately 1024 bits in length. If /dev/random is read with O_NOBLOCK was a parameter, and gets EWOULDBLOCK as a result, feed that queue into the FIPS PRNG, and shift out as much data from the PRNG to seed /dev/random as necessary to avoid the blocking.) |
|
|
I would change the implementation, and then send the policy-change request to the policy editor to state that cryptographically secure pseudorandom numbers are used in the case where there the system cannot provide enough entropy, and used to 'seed' additional entropy as needed. |
|
|
CPS was wrong, random was never used due to locking... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-11-23 08:27 | Sourcerer | New Issue | |
| 2005-11-26 07:42 | Sourcerer | Note Added: 0000038 | |
| 2005-11-26 07:42 | Sourcerer | Status | new => needs work |
| 2005-11-26 07:42 | Sourcerer | Assigned To | => duane |
| 2005-12-08 20:38 | evaldo | Relationship added | related to 0000083 |
| 2006-02-20 11:41 | aerowolf | Note Added: 0000082 | |
| 2006-02-20 11:45 | aerowolf | Note Added: 0000083 | |
| 2006-04-21 07:28 | duane | Status | needs work => closed |
| 2006-04-21 07:28 | duane | Note Added: 0000174 | |
| 2006-04-21 07:28 | duane | Resolution | open => won't fix |
| 2006-04-21 07:28 | duane | Fixed in Version | => production |
| 2013-01-13 15:37 | Werner Dworak | Fixed in Version | => 2006 |
