Timeline for Whitening a random bit sequence
Current License: CC BY-SA 2.5
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 26, 2010 at 16:42 | comment | added | BCS | @BlueRaja: See edit 3 | |
| Jun 28, 2010 at 20:11 | comment | added | BlueRaja | @BCS: It's not only the bias that's important, but the bits-per-seconds. | |
| Jun 28, 2010 at 14:34 | comment | added | BCS | Ok. Well I did put tighter bounds on the bias than that. | |
| Jun 26, 2010 at 2:03 | comment | added | BlueRaja | @BCS: Yes, true hardware-based random number generators are based on chaotic physical processes, and tend to generate lots of 0's with the occasional (randomly placed) 1, causing them to be very slow for the purpose of generating unbiased random streams. You may get a few thousand bits per second, compared to BBS (hundreds-of-thousands) or Mersenne Twister (hundreds of millions, not cryptographically secure). | |
| Jun 25, 2010 at 23:25 | comment | added | BCS | Or are you saying the type of input source I'm assuming are generally very slow? | |
| Jun 25, 2010 at 23:18 | comment | added | BCS | Why would it be slow? It could be implemented as a DFA and I expect may well end up I/O bound (I'm assuming the input stream is not a bottleneck). | |
| Jun 25, 2010 at 23:04 | history | answered | BlueRaja | CC BY-SA 2.5 |