from the 549g6850gy7jh549y8k3450j45t4 dept.
The OneRNG is an Open Hardware, Open Source, simple and verifiable USB-connected source of entropy; we do not ask you to "trust" us, we give you the ability to verify for yourself that the OneRNG does what we claim, and that it does nothing else.
OneRNG collects entropy from an avalanche diode circuit, and from a channel-hopping RF receiver. It even has a “tinfoil hat” to prevent RF interference — you can remove the hat in order to visually verify the components being used.
You rely on a high-quality source of random numbers to maintain your privacy and security in computer communication; but computers have too few sources of truly random data for the demands we place upon them. Increasingly we have been distrusting the solutions given to us by others, as they are shown to be weak in so many ways - because of faults in implementation, in design, or due to subversion by attackers who simply do not care about the consequences of their actions (I'm looking at you, NSA).
In general usage, we recommend that you use the OneRNG as an entropy source for your operating system's own RNG software; this allows you to consume extremely large quantities of random data without either blocking or reducing the quality of the data.
http://onerng.info
[Additional Info]:
http://moonbaseotago.com/onerng/
http://www.theregister.co.uk/2014/11/17/meet_onerng_a_fullyopen_entropy_generator_for_a_paranoid_age/
Related Stories
Recent upgrades that depend on the new Linux getrandom() syscall can cause OpenSSH to delay starting for tens of minutes while waiting for enough bytes of randomness. There are currently not any feasible work-arounds.
Systemd makes this behaviour worse, see issue #4271, #4513 and #10621.
Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times when /var/lib/urandom/random-seed (that you still have laying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.#4167 is a re-opened discussion about systemd eating randomness early at boot (hashmaps in PID 0...). Some Debian folks participate in the recent discussion and it is worth reading if you want to learn about the mess that booting a Linux system has become.
While we're talking systemd ... #10676 also means systems will use RDRAND in the future despite Ted Ts'o's warning on RDRAND [Archive.org mirror and mirrored locally as 130905_Ted_Tso_on_RDRAND.pdf, 205kB as Google+ will be discontinued in April 2019].
Related post: OneRNG: a Fully-Open Entropy Generator (2014)
(Score: 2) by redneckmother on Tuesday November 18 2014, @01:44AM
This compares favorably with TrueRNG:
https://www.tindie.com/products/ubldit/truerng-hardware-random-number-generator/ [tindie.com]
Mas cerveza por favor.
(Score: 2) by davester666 on Tuesday November 18 2014, @04:57AM
True source of unlimited entropy: a small child left alone
out of control entropy: two small children left to themselves
(Score: 2) by redneckmother on Tuesday November 18 2014, @03:44PM
All we need is a way to pipe it to /dev/random eh?
Mas cerveza por favor.
(Score: 4, Insightful) by Nerdfest on Tuesday November 18 2014, @02:05AM
Okay, can everyone stop complaining about open-source project names? This is one of the best names ever.
(Score: 1, Troll) by cafebabe on Tuesday November 18 2014, @06:26AM
Yes, but it needs a good logo [knowyourmeme.com].
1702845791×2
(Score: 1) by tftp on Tuesday November 18 2014, @02:26AM
Unfortunately they have no software support for Windows or Mac. They don't even say if such support can be added without some major hacking. One would think that if it's easy to inject external random data into the kernel then it would be easy to compromise the system. So that interface should be protected. Will they manage to bypass that protection? I wouldn't want to build the hardware just to find out that it cannot be used.
(Score: 1) by dlb on Tuesday November 18 2014, @02:42AM
http://moonbaseotago.com/onerng/#windows [moonbaseotago.com] for Windows
http://moonbaseotago.com/onerng/#mac [moonbaseotago.com] for the Mac
From the short explanations given, however, I can't tell how usable it is on either.
(Score: 1) by tftp on Tuesday November 18 2014, @03:07AM
I have seen that. The current software is not usable at all on Windows and Mac, unless you want to write your own crypto software and ask it to read COM23 for random bytes.
The USB CDC support is built into all Windows distributions, it's not something to write home about. The trick is exactly in "We will need some app to copy entropy data, that's TBD at the moment." I cannot imagine that a userspace application, even with additional privileges, can write into kernel space. Not without a driver. Add to that the demand that x64 drivers must be signed... how many new i386 computers are sold today?
I spent a few minutes looking into Windows Crypto API [microsoft.com], and I don't see an obvious way to feed external random data into the RNG. I think OpenRNG people will have to create their own CSP, and then somehow offer it (how?) to the applications. Or they could hack the API and replace the stock RNG with their own. None of that looks straightforward, and that's why in my opinion this is the most complex part of the project.
(Score: 2) by c0lo on Tuesday November 18 2014, @05:13AM
I googled for "windows register custom RNG provider". One of the first links: http://blogs.msdn.com/b/winsdk/archive/2010/05/28/how-to-make-your-custom-rng-random-number-generator-implementation-the-default-rng-provider-for-the-system-using-cng-api-s.aspx [msdn.com].
Why the hell would a special driver be needed? I mean
"Pluggable providers" are necessary, be it only because any Crypto API worth its name will be additively enhanced with new algos over time while still needing to support legacy algos: easier and more secure to just register another DLL implementing the new algos than replace a monolithic library which supports everything
There may exist cases in which such a provider can/should be registered system-wide (for the use of any application) but, indeed, for such cases extra restriction may exists (to avoid attacks of malware/spyware that replaces the OS'es own providers).
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by tftp on Tuesday November 18 2014, @05:53AM
You are proposing exactly what I proposed: "I think OpenRNG people will have to create their own CSP, and then somehow offer it (how?) to the applications."
The catch is that the new CSP would have to be proactively demanded by applications in order to use the new RNG. There are quite a few CSPs already [microsoft.com], and they are selected by name [microsoft.com]. One of them is a default provider (selected if pszProvider == NULL in call to CryptAcquireContext.) The trouble here is that applications need to be modified to load and use the "OpenRNG CSP" or whatever the name is. Also, different CSPs serve different purposes, so one new CSP cannot replace them all. The application will have to load one CSP for RNG and another for whatever crypto it is doing.
A driver is needed if you are patching the existing CSP (default or not.) A new CSP will not need the driver, but it will be not much easier to develop, as it has to be signed. Otherwise it's just a DLL [wikipedia.org].
My point is that it's quite a bit harder than doing cat /dev/ttyACM0. And one way or another, you'll have to sign the executable.
(Score: 2) by c0lo on Tuesday November 18 2014, @07:03AM
(I haven't get in bed with MS/WinAPI for quite a long time already (more than 6 years), so take the below with a grain or 2 (or more than 2) of salt)
I'm not sure why one would need to patch a driver. I mean, I exclude from the start a situation in which certain applications wants to use a certain well-defined CSP instead of the system-default - because if they do want it, then is not "politically correct" to "upset" them. But for the apps which are fine with the system/user-default CPS (i.e. calling into CryptAcquireContext with a NULL pszProvider argument):
...If a CSP does not implement its own functions, the DLL acts as a pass-through layer, facilitating the communication between the operating system and the actual CSP implementation.
Further down the page, I see info on typical scenarios involving Win flavours as early as W2k, thus I assume that writing that DLL is just enough for Windows CPS purposes (that is: no driver patching seems to be necessary!)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 1) by tftp on Tuesday November 18 2014, @07:32AM
I'm not dealing with MS' CryptoAPI at this time, but I used it for a project a few years ago. Still, I'm not an expert, just a user. Here is what I think.
There are several CSPs that do different things. I don't know which one comes as a default, but compare these [microsoft.com] for yourself. They need to be selected by name (which is a convenient #define in the SDK) to do certain things. A default CSP won't allow you to generate a D-H key and at the same time use AES.
The RNG may be a part of a CSP, or it could be a pass-through into a lower level implementation. Since Intel CPUs have (or used to have) a hardware RNG, it is possible that the RNGs in CSPs are a pass-through, unless some CSP acts as a filter.
If you make your own CSP, this won't be backward compatible, as the browser, for example, loads the MS_DEF_RSA_SCHANNEL_PROV CSP. It won't load any other CSP because it doesn't know that they exist, and it doesn't know what those other CSPs might be good for. So if you build your own CSP, the browser wouldn't load it, even if the CSP overwrites the pass-through and implements its own, superior, RNG.
On the other hand, if you want to patch the RNG within the kernel, that will be transparent to all applications and CSPs (except those that have own RNGs.) But to do that you need to write and load a driver that can figure out where RNG calls are located, and patch them up so that they point at your own implementation.
As you can see, both methods (the custom CSP and the driver) are pretty much mutually exclusive. A custom CSP is good if you have a set of applications that know how to use it. A driver is good if you need instant RNG upgrade for all existing software. A driver would be a hack, of course, but many hacks work pretty well, and kernel's API has well defined entry points, and there are only so many Windows kernels.
If I were to decide what to do, I'd first investigate where the RNG is actually implemented. If some CSPs reimplement it, then they need separate attention. But probably none of MS' own CSPs reimplement the RNG that is located within the kernel. A RNG needs to have access to as much enthropy as possible, and a loadable DLL simply doesn't plug into all the interesting sources.
(Score: 2) by mojo chan on Tuesday November 18 2014, @09:29AM
The driver situation on Windows is as follows. There is a generic USB CDC driver that supports emulated serial ports. You do need a .inf file to tell Windows to use it for your specific device though. The problem is that on Windows 8.1 this .inf file needs to be signed with a valid certificate. IIRC the cert is about $275 for a year. My company bought one to do the USB CDC .inf files for its products.
You can disable the driver signing requirement, but on Windows 8.1 it is re-enabled after a reboot.
It's an most unsatisfactory situation, but I can understand why they did it from a security point of view. The only way around it, other than paying for a certificate, is to hijack someone else's signed driver. Clone the VID/PID pair of another USB CDC device. Not ideal because it makes auto-detection of your device's serial port much harder, but at least it bypasses the driver signing requirement.
const int one = 65536; (Silvermoon, Texture.cs)
(Score: 2) by novak on Tuesday November 18 2014, @04:24AM
While in general I guess drivers from all systems are a good thing, maybe you don't want a new RNG to make windows secure. Maybe you want a new OS.
novak
(Score: 1) by tftp on Tuesday November 18 2014, @04:36AM
People hold onto Windows (or Mac) because it runs their software. I cannot imagine anyone who would dump their PC and all the money invested into software just because there is a solution to "maybe a problem" that the guy never heard about and does not see as a threat. Unless the drivers are available, along with a one-click installer, OneRNG and TrueRNG will remain a private toy of cypherpunks.
(Score: 1) by CyprusBlue on Tuesday November 18 2014, @05:16AM
Yeah, I can't imagine where people needing an external source of entrpoy would be using an OS other than Windows.
... right...
(Score: 2) by novak on Tuesday November 18 2014, @05:25AM
I know that people use windows (or Mac) because of all the money invested into it, besides just ease of use. People use what they know. That's not the point.
My point is, don't bother changing your RNG on windows. There are already far more open doors into it.
maybe a problem
No, a definite problem. The NSA has backdoored windows and it is not secure. http://www.washingtonsblog.com/2013/06/microsoft-programmed-in-nsa-backdoor-in-windows-by-1999.html [washingtonsblog.com]
OneRNG and TrueRNG will remain a private toy of cypherpunks
If people don't think there's anything wrong with being spied upon by their own government, then perhaps the problem is how people think, not what RNG they have. In that case, it's nothing but a toy for a wider audience than cypherpunks.
novak
(Score: 1) by tftp on Tuesday November 18 2014, @05:39AM
And that's exactly how things are. Conduct a social experiment: ask random people (and not just your friends on SN :-) if they are concerned that the RNG in the CSP that their IE is using for SSL may be artificially weakened. How many of them will immediately start running in circles in panic?
As matter of fact, even people who have something to hide will not panic like that. Transactions from their home PC will be entirely innocent from any wrongdoing, no matter if they are in plaintext or encrypted. How in the world could an observer conclude anything if the computer in question fetches a small ad banner from some server at a given time of the day? But you just witnessed transfer of information - and a lot of bits, actually - more than 16 bits, if you can achieve 1 second accuracy. A remote observer, one who only watches the traffic, has no way to tell if the loading of the banner was caused by a Web page or by a specially crafted software. There are more ways to conceal information in the open.
(Score: 2) by novak on Tuesday November 18 2014, @05:54AM
I do not disagree. That is how things are. Also, most people do not buy RNGs, basically for that reason. Having drivers isn't going to fix that, and even if you could get drivers, most people would still be VERY insecure. Basically any security today is a toy unless you take extreme 'cypherpunk-esque' steps. This open RNG is one of them, and a good one to have.
novak
(Score: 1) by tftp on Tuesday November 18 2014, @06:09AM
I would buy - or make - one, not because I'm concerned, but just as a toy. In a practical sense you are absolutely correct, many OSes are a sieve of vulnerabilities, even if we only judge by published exploits. How many are not published? TLAs have access to Windows (and probably OS/X) sources and may see exploits that are not detectable by mere experiments. Especially if they paid for those to be coded in the first place... A typical Windows box opens connections to many servers all the time, and the only way to be really sure is to disconnect it from the Internet. (Don't forget the WiFi card.)
The vast majority of people are safe and secure in the cyberspace simply because their communications are of no value to anyone except the lowest of lowly thieves. And those can't break SSL. If a TLA wants your data, there is an xkcd just about that. Nobody is going to bother with decryption if the agency can send people into the apartment and capture the whole HDD.
(Score: 2) by novak on Tuesday November 18 2014, @06:54AM
their communications are of no value to anyone except the lowest of lowly thieves
their communications are of no value to anyone except their own government
Not everyone would immediately realize that the government is the lowest of lowly thieves, but they should (At least, if you live in one of the five eyes countries).
Most users have no reason to be worried about hackers, as you said they have nothing worth wasting their time on. Viruses are usually easy to steer around, either the vulnerabilities they exploit are soon patched, or they are dependent on ignorant users to spread. I'm worried about people who really do have the means and the reason to try to break encryption across the entire internet.
novak
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @03:32PM
Yeah, it sucks to be in a five eyes country. Too bad we can't all be in some place like China or Russia. I'm sure in those places you are FAR less likely to be spied upon by the government, right?
I find it remarkable how so many people around here whine and shit all over Western countries being essentially the equivalent of 1960's Soviet Bloc countries, when over 3/4th of the world is much worse from a human rights standpoint on all accounts. But they all somehow get a free pass because "OMG! Teh NSA!!!!!" What's a few thousand people rounded up and murdered here and there. That's nothing. They're lucky they don't have to take their shoes off at the airport! They have no idea what a pain in the ass that is and how lucky they are.
(Score: 2) by VLM on Tuesday November 18 2014, @01:47PM
People hold onto Windows (or Mac) because it runs their software
Over the decades I've been working, "their software" has almost entirely moved from native local apps to "on the web/cloud".
I need a boot loader for firefox (mac, windows, linux, freebsd...) and I personally need a ssh client and the vmware guys here won't enable the vsphere web client because it apparently sucks or they are lazy, so I need the hosted vsphere app. Thats it. Everything else is web based.
I can't think of a new tool or application rollout at work that hasn't been web based in the last decade or so. Hosted native apps are dead outside video games and legacy office software.
(Score: 2) by wonkey_monkey on Tuesday November 18 2014, @08:27AM
maybe you don't want a new RNG to make windows secure. Maybe you want a new OS.
And maybe some of these pretty things get broken if Big Jimmy doesn't get his money.
systemd is Roko's Basilisk
(Score: 1) by AgTiger on Tuesday November 18 2014, @02:41AM
(Score: 3, Insightful) by Dunbal on Tuesday November 18 2014, @02:59AM
Sending your random numbers across the internet sort of defeats the purpose though if you plan on using them for encryption.
(Score: 3, Funny) by stormwyrm on Tuesday November 18 2014, @03:08AM
Hotbits and the OneRNG? I wonder if one will toss the other into a volcano. XD
Numquam ponenda est pluralitas sine necessitate.
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @03:25PM
Will Natalie Portman pour hotbits in my pants?
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @02:54AM
"There's many a slip twixt the cup and the lip".
(Score: 4, Interesting) by kaszz on Tuesday November 18 2014, @01:31PM
The generator will perhaps provide truly random numbers. But those are vurnable to attack when transferred through the USB controller if it has backdoors, if the USB cable is "special edition", if the USB host is compromised, or if the USB driver is compromised. Microsoft/Apple products are of course compromised by corporate decision. But even free operating systems like Linux/BSD might be compromised by attacks on the USB stack or modifying the USB firmware on the embedded device. Another attack is to reprogram the USB firmware of another USB device to pretend it's your random generator. And make your crypto software to select that as the preferred one (enumeration).
One might point out emphasize that the numbers are just random bits. But then if they don't matter. Why build dedicated hardware in the first place?
To prevent attack surfaces like this. I propose that any security device has to have a secured link all the way even if it's a local hardware. Your cryptographic software shall demand that the link is encrypted and authenticated all the way to the internal workings of the source (CPU). The random source shall also be regularly tested for functionality. Electronics may fail, especially if ionizing sources are nearby. Or another serial device may be mistaken for being the proper source etc.
So all in all: Encrypt, authenticate, ensure functionality periodically, and make USB firmware read only (write protect!).
(btw, a Thyratron when operated as a diode where the grid is tied to the cathode within a transverse magnetic field may provide even better randomness than ionizing sources)
(Score: 2) by kaszz on Tuesday November 18 2014, @01:33PM
And don't forget attacks by memory inspection from kernel level loopholes or PCI bus snooping. A compromised firmware or ASIC on you Ethernet card may be all it takes. Or system BIOS..
(Score: 0, Funny) by Anonymous Coward on Tuesday November 18 2014, @06:02PM
> Or system BIOS..
Or systemd!
(Score: 1) by GWRedDragon on Wednesday November 19 2014, @01:14PM
Why does a security device for the paranoid use a uC that includes wireless radio????
Why claim the firmware is 'verifiable' when what you are really doing is calling a software routine to request program memory? There is nothing stopping a malicious firmware from simply sending back a friendly-looking program which isn't what is actually running. This 'feature' does nothing but add false sense of security. I see it as a red flag.
[Insert witty message here]