21–30 of 89 posts
Isn't this a problem in the US, being against the famous part 15 of the FCC rules:
«Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.»
> It even has a “tinfoil hat” to prevent RF interference Isn't this a problem in the US, being against the famous part 15 of the FCC rules: «Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.»
Some background - this board is in late beta testing, we're going to kickstart it and release it (with papers scheduled at a couple of conferences) - it's hitting Hacker News a little early - but keep us in mind when we do finally release to the public - at the moment we haven't published the design - we'll be putting up both the firmware an hardware designs on GitHub when we think it's ready for the public (almost there)
If you want some idea of the code and development system it's largely based on the dev system for out IoT project:
http://www.moonbaseotago.com/cheaprf/
Meanwhile I'm happy to answer questions
> It even has a “tinfoil hat” to prevent RF interference Isn't this a problem in the US, being against the famous part 15 of the FCC rules: «Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.»
I think it refers to the fact that if your device fails due to interference below the legal limit it is your problem to fix, not the device that generated the interference.
This seems sound. However, I'm in doubt about some of their points: > You can ask it to dump the current firmware to you It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it? > You can see all the components on the board The fact that I can see these tiny thingies doesn't do much good either? Can I, seeing them, tell what they do? No. Building one of t…
> It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it? Well, of course, in theory. In practice the total amount of firmware space is limited. It's rather large, as these things go, at 256 or 512 KB depending on the exact model. If it dumps a firmware close to that size, which passes scrutiny by several people, I would say that the risk that the chip s…
(and then of course one verifies the source by inspection)
> It even has a “tinfoil hat” to prevent RF interference Isn't this a problem in the US, being against the famous part 15 of the FCC rules: «Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.»
I'm curious why they chose to use an avalanche diode which doesn't generate quantum-random numbers, unlike a reverse-biased transistor. As far as I'm aware, this means you could effect the numbers, by varying temperature.
I'm curious why they chose to use an avalanche diode which doesn't generate quantum-random numbers, unlike a reverse-biased transistor. As far as I'm aware, this means you could effect the numbers, by varying temperature.
And being in a semiconductor it is a quantum process (in fact most sources of noise in circuits are quantum in origin - not that it matters)
I'm curious why they chose to use an avalanche diode which doesn't generate quantum-random numbers, unlike a reverse-biased transistor. As far as I'm aware, this means you could effect the numbers, by varying temperature.
I doesn't matter. And being in a semiconductor it is a quantum process (in fact most sources of noise in circuits are quantum in origin - not that it matters)
A good CS-PRNG can take a modest amount of entropy and store it in a way (internal state) that you trust it can't be recovered by the attacker. From this they can generate a nearly endless supply of random output. That, as I understand it, is /dev/random vs. /dev/urandom/. So it's nice to have a good reliable source of entropy , but you can also consider how protected is the internal state, aka the place you stick th…