[quote author="matseng"]I'd say that you've got plenty entropy in the device itself. By just fiddling with the joystick for a few seconds you should be able to generate hundred and hundreds with bits of random data.
If the joystick is activated at roughly 300 mS intervals by the user a 16 Mhz timer/counter would give about 20 bits of randomness in it's lower part of the counter. 20 bits * 3 per second * 2 seconds = 120 bits = 20 characters Base64 encoded password. Even if you just extract the lower 16 bits from the counter you'd still get a 16 character password in in two seconds of fiddling.[/quote]
I didn't think of that before, but also I really want to include a hardware RNG just for the sake of it. I got interested in the concept of creating "real" randomness a while ago, but haven't got around to implement it in a project.
[quote author="matseng"]But of course it's more 'tech' to have a real hwrng, you might be able to get your noise bias voltage from the oled since all oleds needs 12-15 volts to work - some need external circuity for this, but some have internal hv generators, but still usually requires a external cap where the voltage possibly can be leeched off from.[/quote]
Now that is an awesome idea. I had a look at two OLED datasheets (UG-2864AMBAG01 and UG-2864HSWEG01, both from Univision), but they generate 7V with their integrated DC-DC converter or can be supplied with 9V externally. That might be sufficient for a zener-diode based RNG, but not enough for the shown two transistor circuit. Hopefully I will find some time to do some testing over the Christmas holidays. I'm especially curious how the supply voltage affects the generated noise.
As probably many of you, I have lots and lots of accounts for different services, shops, forums and so on. In the old times (tm) I used the classical "one password fits all" approach and then got screwed. My account details got stolen from a website, which forced me to change all other accounts as well. Nowadays I use a password manager - namely KeePass - and that works well. I can synchronize the encrypted database with DropBox and therefore access my passwords on any device I own. One problem remains: if my PC or phone gets infected with a virus, it could read out all my passwords and abuse them. So the password manager is a single point of failure, and I would like to avoid that. Enter the USB Password Manager. Imagine a device, that securely stores all your login credentials and connects to your PC via USB. It appears as a USB keyboard, so you just have to select the right username/password combination on the device and it enters them directly to the website or program. I have been thinking about this idea for quite some time and plan on building a prototype in spring of 2013. However I'm not very proficient in writing firmware yet, so I was hoping to find some support here. If you have any suggestions or corrections for the hardware, please tell me.
The hardware will consist of the following:
an ATmega32U4,
a small OLED,
a joystick,
a SPI connected flash chip
and a hardware random number generator.
I haven't worked with PICs yet, so I chose the ATmega32U4. There is an open-source USB stack available for this chip, so that won't be a problem. The choice of display and user-input is mainly determined by size, as I want the PCB to be as small as possible. The flash is for storing the login credentials. Now for the interesting part: the random number generator (RNG). I want to be able to generate unique passwords for every website on the device. That way the password can't be manipulated by any PC side software. Using a pseudo-random number generator would be possible, but the good quality ones are computationally expensive and still need some entropy to work well. So I thought, why not use a hardware RNG to start with. The circuit I plan on using consists of two NPN transistors and some logic. You can find the circuit here http://http://web.jfet.org/hw-rng.html. The circuit is proven, but it needs a voltage in excess of 12V to work. I tried to generate this voltage with a Dickson Charge Pump (http://http://en.wikipedia.org/wiki/Voltage_multiplier#Dickson_charge_pump), but failed miserably - the charge pump was not able to deliver the necessary 520uA of current. So instead I will use a boost-converter. To reduce the BOM cost, the control circuit will be implemented in the microcontroller - and as I don't need any serious current I can use really small inductors and caps.
I plan on documenting the development process here in the forum. The level of detail will vary with how much spare time I will be able to invest in this project over the next few months. Well, that's it so far. Now I'm eager to hear what you think about this project.
Unfortunately I messed up the power switch circuit, so I had to change the schematic before posting it. The version shown below should work, but it's untested. On the v12 PCB, the one I built, the fixes were implemented in dead-bug style (see image below). I attached the Eagle files for the design and my version of the source code. I had to change some things, as I didn't copy the original schematic. The software UART is missing completely. I also updated the LCD driver code, the newer version is more flexible regarding the command timing. If you build this design please use the fuse settings as shown in fuses.bat. The boost-converter IC is the OnSemi NCP1402 (http://www.onsemi.com/PowerSolutions/pr ... id=NCP1402) which is absolutely awesome. With its startup voltage of just 0.8V I could have used just one AA battery. And it comes in a tiny SOT23-5 package, including a 200mA FET. I have to say I'm a big fan of DC-DC converters, so most of my designs include one :)
I built my own version of this handy tool last weekend. I replaced the linear regulator with a small boost-converter. Now the circuit can be powered with two AA batteries. The PCB is sandwiched between the battery holder and LCD, so to provide a handy device without need for a case. I had a lot of fun designing and building the circuit, so thank you DP for highlighting this project.
