4 ms·

I've never worked on state-level appliances, so thank you for the information, but just for the sake of stopping urandom-fear, let me spell out why this all doe

I've never worked on state-level appliances, so thank you for the information, but just for the sake of stopping urandom-fear, let me spell out why this all does not apply to the 99% of us developing for consumer processor architectures (which I'm sure you realize): - the "uncertain mathematical constructions" are hashes. More precisely, in Linux case, SHA-1 preimage (not collision) security. No civilian cryptosystem would survive the fall of hashes. - all other points are void as soon as you use that randomness from a regular application running on regular CPUs, as all the bit-flips, compromises and backdoors can simply happen there. - having the keys on hardware DOES make compromise recovery much easier, but there we are speaking of HSM capable of doing the private key operations themselves, not simply providing randomness.

nickpsecurity 10y ago
"the "uncertain mathematical constructions" are hashes. More precisely, in Linux case, SHA-1 preimage (not collision) security. No civilian cryptosystem would survive the fall of hashes." The fall of a RNG by biasing its bits is more likely than a full, second-preimage attack on a hash. So, a failure of hash function in one app != failure in all apps. You're certainly right that it would have bigger implications but might still be useful as MD5 is if collisions are out of scope. "all other points are void as soon as you use that randomness from a regular application running on regular CPUs, as all the bit-flips, compromises and backdoors can simply happen there." There's a lot of CPU's to choose from to reduce that risk. There's systems like Gaisler's Leon3-FT that are open-source, have resistance to bitflips, support mods like TRNG's, and run Linux. At this point, they have to subvert your ASIC process, mask manufacturing, or supply chain. Harder than a purchasing a Linux 0-day if target has decent OPSEC and avoids spy-friendly jurisdictions. ;) If it's on Intel/AMD/IBM, your comment is true in most cases. "but there we are speaking of HSM capable of doing the private key operations themselves, not simply providing randomness." I was speaking of both. One problem I have is bootstrapping randomness. I do it by hand with cards whose entropy feeds into a CRNG unless I have a trustworthy TRNG. A plug-in, analog source with dumb, interface chip isn't going to be compromise by hackers... probably. Likewise, I can go further with a simple, coprocessor w/ ROM, memory protection, dumb interface, and onboard TRNG. Many available from many vendors of varying trustworthiness. Still safer than base system w/ kernel RNG and can even monitor (or restore) host system if I choose. "let me spell out why this all does not apply to the 99% of us developing for consumer processor architectures" I still agree with that, though. Main reason is nobody in 99% is going to use anything high-security because it will cost more, be inconvenient, and lack feature/app X, Y, or Z. Always was the case. :)
- recivorecivo 10y ago
  Have both of you considered taking with less ego?
- ashitlerferad 10y ago
  Why can't high-security stuff get into the consumer world?
  - semi-extrinsic 10y ago
    Why don't you drive a different randomised route to and from work every day and keep a log of cars you keep recognising in the rear view mirror, to detect government/foreign intelligence spying on you? Or: why doesn't your car have an FIA compliant roll cage, a fire extinguishing system and six point harnesses? Same answer: for you (and 99.9% of us), the costs outweigh the benefits.
    - nickpsecurity 10y ago
      The cost was nearly free for the basic protections. High-assurance design or components applied in otherwise commercial. We call this medium assurance but it's quite effective in practice. Even high-assurance projects like LOCK program said A1-class requirements only added around 30-40% to the cost of otherwise solid, development process. That's not bad for software that should rarely fail, get hacked, or be unrecoverable. I'd pay $150 for Windows instead of $100 or so. :) Meanwhile, methods like Cleanroom and Eiffel showed great reductions in defects and problems while around same cost and time to market due to reduced debugging. Sometimes faster or cheaper slightly. Sometimes slightly more cost or time. Not much of a difference and low technical debt meant it got cheaper to improve over time. So, your argument might apply if we're talking keeping legacy software at full speed on cheapest hardware with zero modifications. That really puts high-assurance in a box. Yet, if you're talking dramatically improving assurance of isolation or recovery at the least, then you can do it for a significant, but not heavy, additional cost. And remember much of those exorbitant costs came from straight-up inventing the stuff on the spot. Proven examples to draw from in the literature, including full designs, should drop that many fold. GEMSOS was $15 million over 2-5 years. seL4 was about $5 million over 2-4. A handful of academics put together Muen in SPARK pretty quickly so maybe a few hundred K to a million there. See how the costs drop as we do similar jobs with improved tools and prior examples?

nickpsecurity 10y ago

"the "uncertain mathematical constructions" are hashes. More precisely, in Linux case, SHA-1 preimage (not collision) security. No civilian cryptosystem would survive the fall of hashes." The fall of a RNG by biasing its bits is more likely than a full, second-preimage attack on a hash. So, a failure of hash function in one app != failure in all apps. You're certainly right that it would have bigger implications but might still be useful as MD5 is if collisions are out of scope. "all other points are void as soon as you use that randomness from a regular application running on regular CPUs, as all the bit-flips, compromises and backdoors can simply happen there." There's a lot of CPU's to choose from to reduce that risk. There's systems like Gaisler's Leon3-FT that are open-source, have resistance to bitflips, support mods like TRNG's, and run Linux. At this point, they have to subvert your ASIC process, mask manufacturing, or supply chain. Harder than a purchasing a Linux 0-day if target has decent OPSEC and avoids spy-friendly jurisdictions. ;) If it's on Intel/AMD/IBM, your comment is true in most cases. "but there we are speaking of HSM capable of doing the private key operations themselves, not simply providing randomness." I was speaking of both. One problem I have is bootstrapping randomness. I do it by hand with cards whose entropy feeds into a CRNG unless I have a trustworthy TRNG. A plug-in, analog source with dumb, interface chip isn't going to be compromise by hackers... probably. Likewise, I can go further with a simple, coprocessor w/ ROM, memory protection, dumb interface, and onboard TRNG. Many available from many vendors of varying trustworthiness. Still safer than base system w/ kernel RNG and can even monitor (or restore) host system if I choose. "let me spell out why this all does not apply to the 99% of us developing for consumer processor architectures" I still agree with that, though. Main reason is nobody in 99% is going to use anything high-security because it will cost more, be inconvenient, and lack feature/app X, Y, or Z. Always was the case. :)

recivorecivo 10y ago
Have both of you considered taking with less ego?
ashitlerferad 10y ago
Why can't high-security stuff get into the consumer world?
- semi-extrinsic 10y ago
  Why don't you drive a different randomised route to and from work every day and keep a log of cars you keep recognising in the rear view mirror, to detect government/foreign intelligence spying on you? Or: why doesn't your car have an FIA compliant roll cage, a fire extinguishing system and six point harnesses? Same answer: for you (and 99.9% of us), the costs outweigh the benefits.
  - nickpsecurity 10y ago
    The cost was nearly free for the basic protections. High-assurance design or components applied in otherwise commercial. We call this medium assurance but it's quite effective in practice. Even high-assurance projects like LOCK program said A1-class requirements only added around 30-40% to the cost of otherwise solid, development process. That's not bad for software that should rarely fail, get hacked, or be unrecoverable. I'd pay $150 for Windows instead of $100 or so. :) Meanwhile, methods like Cleanroom and Eiffel showed great reductions in defects and problems while around same cost and time to market due to reduced debugging. Sometimes faster or cheaper slightly. Sometimes slightly more cost or time. Not much of a difference and low technical debt meant it got cheaper to improve over time. So, your argument might apply if we're talking keeping legacy software at full speed on cheapest hardware with zero modifications. That really puts high-assurance in a box. Yet, if you're talking dramatically improving assurance of isolation or recovery at the least, then you can do it for a significant, but not heavy, additional cost. And remember much of those exorbitant costs came from straight-up inventing the stuff on the spot. Proven examples to draw from in the literature, including full designs, should drop that many fold. GEMSOS was $15 million over 2-5 years. seL4 was about $5 million over 2-4. A handful of academics put together Muen in SPARK pretty quickly so maybe a few hundred K to a million there. See how the costs drop as we do similar jobs with improved tools and prior examples?