SoylentNews is people
SoylentNews
Former FBI General Counsel Jim Baker, who was known for prosecuting the legal case against Apple to get them to unlock the San Bernardino shooter's iPhone, has published an extraordinary essay on Lawfare where he surprisingly argues rather for strong encryption without government back doors.
From Schneier on Security:
In the face of congressional inaction, and in light of the magnitude of the threat, it is time for governmental authorities -- including law enforcement -- to embrace encryption because it is one of the few mechanisms that the United States and its allies can use to more effectively protect themselves from existential cybersecurity threats, particularly from China. This is true even though encryption will impose costs on society, especially victims of other types of crime.
[...] I am unaware of a technical solution that will effectively and simultaneously reconcile all of the societal interests at stake in the encryption debate, such as public safety, cybersecurity and privacy as well as simultaneously fostering innovation and the economic competitiveness of American companies in a global marketplace.
[...] All public safety officials should think of protecting the cybersecurity of the United States as an essential part of their core mission to protect the American people and uphold the Constitution. And they should be doing so even if there will be real and painful costs associated with such a cybersecurity-forward orientation. The stakes are too high and our current cybersecurity situation too grave to adopt a different approach.
Baker joins the growing list of former US law enforcement and national security senior officials who have come out in favor of strong encryption over backdoors, such as former NSA directors Gen. Michael Hayden and V. Adm. Mike McConnell, former DHS secretary Michael Chertoff, Counter-Terrorism adviser Richard Clarke, former Secretary of Defense Ash Carter, and former deputy Secretary of Defense William Lynn.
(Score: 2) by opinionated_science on Wednesday October 30 2019, @02:49PM (7 children)
I must confess the whole AMD "RAND" bug got me thinking - what if the backdoor is simply a way of gaming random number generation so that keys are a *tiny* bit predictable.
Hence, they can come out and say "Everyone use secure stuff, we love you!" and in actual fact, they have already have a backdoor.
I am a little shocked the Linux kernel doesn't test the random numbers on boot, but hey, I guess they will now...
(Score: 0) by Anonymous Coward on Wednesday October 30 2019, @03:00PM
Hmm, interesting you are concerned about an optional non-issue when there are much bigger ones at stake (Intel me, amd psp, etc).
In fact AMD's implementation may be "buggy" because it was designed by Intel to have a backdoor to begin with: https://en.m.wikipedia.org/wiki/RDRAND [wikipedia.org]
(Score: 2) by Freeman on Wednesday October 30 2019, @04:02PM (3 children)
There's no such thing as that, it's either reproducible/predictable or it isn't. Now, perhaps it's only predictable in XYZ scenario, but '"tiny" bit predictable' seems like any oxymoron.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 2) by c0lo on Wednesday October 30 2019, @04:41PM
Meh, maybe it's a brit mannerism. You know? like "yo momma is quite a bit overweight"
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 3, Insightful) by vux984 on Wednesday October 30 2019, @06:15PM
"There's no such thing as that, it's either reproducible/predictable or it isn't"
For a simplified example, If I define a true random number generator that produces 8 bit random numbers, then it will produce random numbers from 0 to 255.
If my generator has a defect such that every 61st number it generates has a 55% chance setting the lowest bit to 1. It will produce random numbers from 0 to 255, but every 61st number is slightly weighted toward being odd.
That is a 'tiny bit predictable'. You don't know what odd number it will be, you don't even know whether it will be odd, and it ONLY affects every 61th number.
And if you are using it to generate 1024 bits of randomness by calling it 128 times then you will only actually get 1022 random bits. And the other 2 bits are slightly weighted. At best you can use this knowledge of the flaw to improve the average case performance of a brute force search a little.
(Score: 2) by stormwyrm on Thursday October 31 2019, @04:04AM
If I had loaded dice, say, one which is weighted such that 6 comes up more often, then their outcome is easier to predict than dice that are completely fair, i.e. a "tiny bit predictable". An unloaded, completely fair die has six possibilities, each of which has a probability of ⅙ of appearing. Now, if we loaded the die such that a 6 would come up with a higher frequency than any other result, say, we make it such that it appears on average three times out of every four rolls. So now, the probability of rolling a 6 becomes ¾, while rolling anything else has a probability of 0.05. So now it becomes a lot easier to predict the roll. In the same way, if we had a random number generator circuit (this is a particular project of mine, see my journal for details) doctored such that four bits out of eight are actually generated according to a very simple sequence (e.g. they are easily derived from each other), it would become fairly easy to predict cryptographic keys derived from it. If it were used to generate 128 bit keys, 64 bits of the key would be easily derivable, and so the brute-force attack is only 64 bits worth, not so infeasible.
Numquam ponenda est pluralitas sine necessitate.
(Score: 1, Insightful) by Anonymous Coward on Wednesday October 30 2019, @06:17PM (1 child)
Maybe not, other than adding another bug flag to /proc/cpuinfo. How do you propose to tell whether a random number generator is compromised? It could be more maliciously compromised than what AMD did.
15 years ago or so ago, when the first hardware RNGs came packaged on CPUs, I believe Linus made the right decision to only keep the hardware RNGs as one source of random data in a pool of many other sources.
(Score: 0) by Anonymous Coward on Thursday October 31 2019, @07:03AM
One of the kernel configuration options is whether or not to trust the CPU's RNG.
It would not make sense to attempt to test this on the fly, as if it were that easy to detect, someone would have already done so. If the RNG is compromised, it has to be done in such a way that no one can prove it.