import old notes

5 files changed, 187 insertions, 0 deletions

diff --git a/cryogenius_rng.gif b/cryogenius_rng.gif
new file mode 100644
index 0000000..65389a1
--- /dev/null
+++ b/cryogenius_rng.gif
diff --git a/jfet-rng-circuit.gif b/jfet-rng-circuit.gif
new file mode 100644
index 0000000..b512019
--- /dev/null
+++ b/jfet-rng-circuit.gif
diff --git a/notes b/notes
new file mode 100644
index 0000000..f8b07d6
--- /dev/null
+++ b/notes
@@ -0,0 +1,31 @@
+
+princeton "noosphere" project:
+http://noosphere.princeton.edu/
+
+http://code.google.com/p/avr-hardware-random-number-generation/wiki/AvalancheNoise
+
+http://forums.hackaday.com/viewtopic.php?f=2&t=2428
+
+http://holdenc.altervista.org/chua/
+
+http://holdenc.altervista.org/avalanche/
+
+http://web.jfet.org/hw-rng.html
+
+http://www.gniibe.org/memo/development/gnuk/rng/pqrng
+http://www.gniibe.org/memo/development/gnuk/rng/neug
+http://lists.gnupg.org/pipermail/gnupg-devel/2011-July/026146.html
+http://no-passwd.net/
+http://www.seeedstudio.com/wiki/index.php?title=FST-01
+
+http://emergent.unpythonic.net/01257868826
+
+arduino ADC no good for true random numbers?
+http://www.academia.edu/1161820/Ardrand_The_Arduino_as_a_Hardware_Random-Number_Generator#outer_page_20
+
+TinyMT (mersine twister), a very small-state PRNG implementation
+
+avalanche:
+http://robseward.com/itp/adv_tech/random_generator/
+
+
diff --git a/plan b/plan
new file mode 100644
index 0000000..3846d39
--- /dev/null
+++ b/plan
@@ -0,0 +1,104 @@
+
+Central circuit:
+http://www.cryogenius.com/hardware/rng/
+
+Using 17v (or +8.5v?) from a MAX232 as a voltage source.
+
+### BOM
+
+Breadboard prototype will be maple mini plus through-hole and DIP components.
+
+Version for fab should try to use surface mount components for everything, with
+SOT-sized-ish components for reasonable hand assembly.
+
+Central circuit:
+
+Q1,Q2,Q3        2N3904      transistors
+                74LS14      schmitt trigger (only one needed)
+C1                          0.1uF cap, ceramic ok
+R1,R3,R4                    4.7K resistors
+R2                          1M resistor
+
+Alternatively, use a series of 3 74ALS04 inverters (single chip) instead of the
+schmitt trigger and Q3 for amplification. This increases requires an extra
+0.1uF capacitor and two 2.7K resistors; see jfet.org diagram.
+
+Voltage source:
+
+                MAX232      level shifter (as a cheap voltage source)
+3x                          1uF capacitor, ceramic SMD ok (1206?)
+
+mchck:
+2x 0603 10ohm resistors
+2x 0603 1k resistors
+5x 0603 100n 6.3v+ capacitor
+1x 0603 1uF 20v+ capacitor
+1x 0603 1uF 6.3v+ capacitor
+1x 0603 LED (any?)
+1x button
+1x 8MHz 3-pin resonator
+1x MIC5202 3.3v regulator
+1x MCU: STM32L151C8T6
+
+### Circuit
+
+Power to all transistors comes from the MAX232; this higher-voltage segment is
+isolated from the rest of the circuit by a capacitor.  Both trigger and MAX232
+Vcc are straight to USB +5v/GND (which already has seperate stabilizing cap). 
+
+When using MCHCK, grab Vext and GND off headers and route to circuit. PB5 (on
+the end header) looks like a decent input pin to pipe in to: it is 5v tolerant
+and connected to both timer3 and comparator2.
+
+Optionally, according to jfet.org, the floating collector could be tied to the
+base of the first transistor.
+
+### Software
+
+Raw bits should be sampled at a regular rate, possibly using DMA to increase
+speed and reduce interrupts. 
+
+Raw bits should be analysed for their bias (some acceptable ratio; 20-80% over
+512 bits?) and potentially quickly for randomness. If they pass, they should go
+through von neumann de-biasing, then a quick randomness test. Every 1024 bits
+or so coming out of that phase should get hashed down to 256 bits or so, then
+that output again checked for randomness (really?). Finally bundle up packets
+and put them in a USB read buffer. Packet could include some extra data (eg,
+bias), or not.
+
+Failures due to poor bias should be skipped, at least for a long time. Any
+other failures due to non-randomness should cause the device to lock up and
+possibly report tampering.
+
+Optionally, randomness could get pushed out over i2c, SPI, UART, pin, or port.
+
+Raw read should be very fast and have highest interrupt, followed by USB
+interrupt.
+
+Alternatively, a timer can be used to measure the timing between digital value
+transitions.
+
+### 'scoping Notes
+
+Used cyrogenius circuit. Capacitor may be 
+
+"minimum viable voltage" seems to be 10v: first state flips to 2.8v around
+9.45v, first trigger scope at 5v at 11v input, reliably triggering at 12v. At
+20v in, peaks around 9.5v. At 17v in, peaks around 8.4v.
+
+Seems like sampling should be at least 1usec apart to reduce correlations
+between bits. This would make for about 125 kilobytes (not bits) per second
+best case, which seems very reasonable for rooter.
+
+Tying collector to base of first transistor doesn't seem to have a detrimental
+effect.
+
+Really can't discern any strong bias just by looking at the scope.
+
+### TODO
+
+- both 1uF really required for MAX232?
+- MAX202D vs. MAX232D? smaller caps
+- smaller schmitt trigger
+- 3-in-one 2N309 transistors?
+
diff --git a/ps_notes b/ps_notes
new file mode 100644
index 0000000..349ac11
--- /dev/null
+++ b/ps_notes
@@ -0,0 +1,52 @@
+
+ST232CN w/ capacitors:
+
+5.05v in (from USB via maple), 14.92 out unloaded
+
+with circuit, 14.4v or so. remeasuring later, 13.3-13.7v (with a little can
+capacitor)
+
+
+---------------------------------------------------
+
+Maxim MAX233CPP
+
+Sat Nov 10 21:29:48 CET 2012:
+
+with a 4.7kohm resistor, measure 16.99 volts. noise on output is a combination
+of ~100mV p-p triangle waves at 168 kz, plus extra 120mV p-p bursts at peaks,
+plus random sort-of-digital digressions of about 100mV on a time scale of 5ms
+or so. large amplification of USB input noise? in this configuration, USB
+voltage only wanders by 20mV or so, but maybe current varries.
+
+without any load, output is 19.28v; noise is ~50mV p-p triangle waves with
+100mV peak transients, plus same old macro scale wanderings.
+
+swapping input cap to 0.1uF and adding a 0.1uF output cap gives 40mV total
+noise with transients gone
+
+running entropy.cpp and doing crude stats in python...
+
+no negative resistor, INPUT_PULLDOWN, delay(1):  percent: 26.562500
+no negative resistor, INPUT_PULLDOWN, delay(10): percent: 30.078858
+no negative resistor, INPUT_FLOATING, delay(10): percent: 31.715096
+no negative resistor, INPUT_PULLUP,   delay(10): percent: 32.595183
+
+while probing un-amplified output, percent: 42.660407
+
+switched to a design where the amplifier is fed from the 0/+5v USB power
+instead of -10/+10 output. got:
+
+with negative resistor, INPUT_PULLUP,   delay(10), percent: 50.102838
+with negative resistor, INPUT_PULLUP,   delay(1),  percent: 52.064632
+with negative resistor, INPUT_FLOATING, delay(1),  percent: 48.503847
+with negative resistor, INPUT_PULLDOWN, delay(1),  percent: 45.382451
+
+
+I think that this circuit can not be used for more than about one raw bit per
+milisecond (meaning about 125 bits/second in the end assuming a 1/4 whitening
+and 50% testing redundancy?).
+
+for raw 32 kilobits/sec (eg, like entropykey?) need to sample with a period of
+32 microseconds or so
+