…someone who remembers the *INFO “Liquid” simulation/demo.

The Entropy Key online shop is now open for business.

Yay.

Yesterday (2009–08-26) we built a small batch (100) of Entropy Keys so that we would have enough to take to the Debian UK BBQ this year. Indeed I shall be able to haul enough to fulfill 200% of the orders as yet received for the BBQ, so if you arrive and decide you want one (or one more :-) then I should have plenty of spares. They remain £35 only for the BBQ weekend. If you miss that boat, then they’ll be at £41.40 (admittedly incl. shipping) once we go live on the website for sales.

The process was a bit arduous for us. This is the first product we’ve done for ourselves (rather than for our customers to sell) in almost a decade. Legislative requirements change in that kind of time frame, as does one’s understanding of the production process. Normally we’d be taking bare boards, like those on the left, and putting them in anti-static jiffy bags and posting them to our customer in big boxes. However this time we actually had to box the devices, flood-fill them with potting compound, prepare security-sealed envelopes with the security keys in them, prepare labels for the devices, etc. On the right you can see the 100 devices all neatly in rows, waiting for their epoxy treatment.

All I have left to do now, is prepare the ISO image full of READMEs, debs and rpms, and then have a rest. I should warn the BBQ buyers that they’re getting v1.0 software, so I hope you’re all ready to provide patches to fix any hiccoughs on the host side. We’re very happy with the device firmware though, so I’m not worried about that.

The keys will be on soak test tomorrow morning, so they’ll be all nice and ready for you all on Saturday. Mmmm randomilicious.

The Simtec Electronics Entropy Key has finally been given official pricing information and an availability estimate of early September.

What’s even more cool is that we managed to persuade our sales guys that we should do a reduced rate for people at the Debian-UK BBQ. So if you’re going to the Debian-UK BBQ this year and want an Entropy Key then please email ekey@simtec.co.uk and tell us how many you want us to bring down for you. They’ll be £35 each, inclusive of VAT. A proper invoice will be issued on the day.

See you there.

Up until now, we’ve only talked about supporting the Simtec Entropy Key on Linux. However, Debian are trying to sort out a kFreeBSD kernel based version of their OS, and lots of security-conscious people use OpenBSD , so, yesterday, I set about trying to get the Entropy Key software working on the BSDs. I had written a userland USB daemon for the Entropy Key on Wednesday, using libusb and since libusb supports FreeBSD, I settled down with a VM of FreeBSD and tried to get an Entropy Key to play ball.

Building on the efforts of my colleague, having made the software compile (which revealed many glibc/linux-specific issues which were fun to fix, and then various Debian/RedHat specific bits of Lua packaging which I had to fix) and then made it run (which required further fettling of the ports of lua-posix on FreeBSD) I finally had an ekeyd which would start in EGD mode at least. The FreeBSD port of luasocket doesn’t enable UNIX domain sockets, so I added support to ekeyd to notice if unix domain sockets weren’t compiled into luasocket and just ignore them, requiring TCP control and EGD sockets.

Finally, after a lot of swearing and poking at things some more, I did manage to get an Entropy Key plugged into the VM and with ekey-ulusbd talking to the key, and ekeyd talking to that, I had it gathering entropy quite happily. Indeed once I had ironed out all of the niggles, it worked quite well. So we’ll be shipping with instructions for building on FreeBSD at least.

Then I moved on to OpenBSD. At first glance I was excited that OpenBSD seemed to be better packaged. Indeed, the OpenBSD packages for Lua, luaposix and luasocket appeared to be much better done, indeed I didn’t need to fettle the luaposix package so it’d load properly, and the luasocket package appeared to have been built with UNIX domain socket support. Excellent news thought I, and proceeded to plug in an Entropy Key to see what the kernel would say. Imagine my shocked joy at seeing OpenBSD merrily say “oh yes, that is a USB serial port/modem thingy, no problems.” I was very happy because this meant that I wouldn’t need ekey-ulusbd on OpenBSD, although OpenBSD was carrying a copy of libusb too. However I then couldn’t find the device node for ’ucom0’ or ’umodem0’ (/dev/ttyU0 did nothing) and all in all, I was a bit disheartened. So I went back to the libusb option, but couldn’t work out what the bus/device match would be, wrote a simple lsusb-alike in order to try and find out, and discovered that while libusb was built and packaged for OpenBSD, it simply didn’t work.

So, having given up on getting OpenBSD going any time soon, I went back to FreeBSD to try and work out how to get things to happen automatically when you plug a key in. I found devd and after reading manpages and looking at examples, decided to try and write an attach event for Entropy Keys. Unfortunately I couldn’t make devd seem to read my rules, let alone try and run them. The debug from devd confused my poor little Linux-centric brain, and so I gave up again.

So, to the crux of the matter…

Over the past week or so, several articles have turned up in such esteemed publications as Slashdot linking to Forbes.com and Information Week regarding the fact that cloud computers have issues getting at those precious bits of entropy required to secure SSL transactions and the like.

Indeed, modern GNU/Linux distributions, and various other operating systems, rapidly consume the available entropy during normal operations. Ubuntu 9.04, at least, uses ASLR in order to reduce the effectiveness of attacks since no two shells will have the same layout of address space etc. You can read more about ASLR on Wikipedia if you want to. Essentially, ASLR is done by reading 64 bits of data from /dev/urandom during process startup and then using that to seed a PRNG which is then used to peturb the layout of the dynamically loaded objects in the process. Indeed if the process itself is compiled appropriately then the main executable can be moved about from process start to process start.

All this, unfortunately, depletes the pool of entropy available to the system. Fortunately /dev/urandom continues to work when the pool is depleted, and indeed will not reduce the pool below a threshold value regardless of how much it is used. However this does open the door to the question of whether or not there might be an attack related to causing a server to spawn enough processes that it has insufficient entropy to subsequently establish a good SSL session or similar.

Normally a Linux system will gather entropy from such things as the miniscule differences in HDD response times, interrupts from keyboards and mice, etc. However a virtual computer (KVM, VMWare, Cloud system etc) doesn’t tend to have a real HDD, or in many cases, any useful amount of interactivity to produce entropic events to be measured. This results in cloud computers often having little to no entropy and no real way of gathering more. Some people believe this leads to being able to predict the random pool of one virtual machine, using the pool of a clone of it.

When Simtec first started talking about the Entropy Key we were inundated with people interested in whether or not it’d help for virtual machines. Initially we assumed it would, but after spending a long time poking at the Linux kernel, at KVM etc, we determined that unfortunately it wouldn’t usefully help in the state it was in. So, I spent some time and updated the Entropy Key’s host software to support the EGD‘s protocol, over both unix domain sockets and TCP. This, along with another simple tool which can connect to an EGD socket and push entropy into the Linux random pool, means that we have an, admittedly network-reliant, excellent way to push entropy from one host with a physical Entropy Key, to one or more systems for use in their random pools.

When the Entropy Key is released, the host software will be released as free software (under the MIT licence) and as such we hope that if anyone else has any cool ideas, for helping with getting entropy to cloud computers, they will send patches. I’m exceedingly proud that we’re releasing the host software under a F/LOSS licence and I hope that anyone who runs lots of VMs will be interested in this latest development in the host software too. If you are interested, be sure to check out the Entropy Key Website and send us a mail if you want to be told when retail units become available.

I am currently stuck taking four times the suggested daily dose of two anti-histamines in order to combat my body and its reaction to plants having sex all around me.

I am taking two 10mg Loratadine tablets, and two 10mg Cetirizine Hydrochloride tablets, twice daily. This is effectively four times the recommended dose of twice as many anti-histamines as I should need.

I wasn’t this bad last year, but the year before was similar. Irritatingly, once the drugs kick in (45 minutes to an hour after taking) my runny nose, itchy/burny eyes, slight dopeyness induced by feeling crap, etc. all fade away. Yesterday I needed my second dose a mere 8 hours after the first, but I didn’t need to re-dose until this morning after that.

I guess what I’m asking is—what is the expected side-effects of taking such a high dose of antihistamines. Do any of you out there have to take such high doses, have you seen a doctor about this? All I expect a doctor to do is to either supply me more loratadine on prescription (which is of dubious value unless I get a lot given prescription charges in the UK), or to try me on a nasal spray, which tend to induce nosebleeds for me. If you’ve found other ways to cope, I’m interested. Otherwise I guess I’ll make an appointment to see the doctor in the next week or so.

Before any of you get your hopes up. NO I have NOT managed it yet.

However, a bit of fiddling today did get me as far as the tomtom establishing a PPP connection. Unfortunately it subsequently did chuff-all with the link, not even a SYN packet afaict.

Here’s roughly what I did:

So, if anyone wants to pick up where I have left off, and have a go some more, then please do tell me if you manage to get anywhere more useful.

This drabble brought to you courtesy of the drabble challenge provided by Scott James Remnant.

Apart from sounding like a strange ‘70s prog-rock band, the title of this posting actually has something to do with random numbers. As some of you are aware, the company I work for has produced a small USB device which we are aiming at producing random numbers from for use in situations where a large number of IID random values are needed. However, rather than aiming at producing the megabits per second which some companies do for around £400 or so, our goal is to have a device more than capable of around 16kbits per second for around £30 or so.

My question is related to the mixing of streams of random numbers. Our device has two hardware RNGs which produce bitstreams. I am already using Üli M. Maurer’s “Universal Statistical Test for Random Bit Generators” to estimate the entropy gathered by the RNGs. What I am trying to determine is if it is reasonable and safe to use a hashing function such as SHA256 in the following way:

What I am trying to determine is whether or not it would be subsequently reasonable to estimate the entropy in each emitted hash state as being in the least bit close to the hash size of the function. E.g. assuming that in the 256 bits coming out of the SHA256 hash, that there is, perhaps 200 bits of entropy.

Ultimately I am trying to come up with a way to process the streams (in a microcontroller, so nothing too onerous on CPU or RAM) such that the data coming off the device can be treated confidently as having a high number of shannons of entropy in every byte. As I stated above, my goal would be 16kbits/second of entropy and if that came in the form of 20kbits/second of data (2500 bytes/second) where the assumption of at least six bits of entropy per byte was sound, then I would be very very pleased indeed.

Some of you familiar with the general area of randomness and particularly of testing randomness might have noticed that 2500 bytes is a rather convenient size for applying the FIPS 140–1 and 140–2 tests to. My goal is to aim at as high a FIPS 140 rating as I can.

If you think you can help, please do email me.

It’s been a long time since I did any Debian work.

Perhaps I should do more Debian work?

This weekend I took the plunge and got an android based phone (The T-Mobile HTC-manufactured G1 in black).

Unfortunately it turns out that the man in the shop lied when I asked if it would work with my Tomtom—It has no ‘dund’ support out of the box. However, following the ever so useful instructions on the Android Wiki I managed to downgrade the phone, jailbreak it, and re-upgrade to a chap’s modified firmware which has the bluetooth binaries etc in it. Unfortunately that wasn’t quite enough and I couldn’t get the Tomtom talking to it.

I am assured that there’s an update to the firmware due soon, although it’s not clear whether that’ll fix the missing features. Also there are rumours of a large firmware upgrade due in the first quarter of this year, but that’s even more woolly since only one person (who I do trust) has mentioned it to me as yet.

I have started to get a feel for coding for Android. Having pooh-poohed it when the emulators and SDKs first happened, I must say that I was pleasantly surprised. The Android stack is well thought out and quite pleasing to write for. Unfortunately I appear to be writing something which isn’t typically attempted by the sorts of people who write tutorials, so I am stuck trying to grobble through the source for the phone’s main apps, and small bits of examples I find lying around on the net.

If anyone has a small, clean, example of an application which combines tabs, bound services which may optionally be started to make them persistent, threading for the service to run code in the background, and asynchronous callbacks for status updates from the service to the app frontend, then I’d be interested in seeing code.