They won't stop using strong encryption. The big national security issue is not a break of government encryption; it's a break on civilian encryption.
Consider a foreign adversary with the ability to break encryption used by banks, credit card companies, large retail facilities, hospitals, etc.
There are a few things that seem tempting-- think "steal from the banks", but a lot of that is unlikely to work, anyway. Banks and wire transfer systems have auditing and verification measures in place that would make it difficult to pull this off successfully. Credit card companies and retailers would have a serious issue with reissuing cards, etc.
What would turn things upside-down is the LOSS OF FAITH in these systems and the economic, social, and practical effects. The Russians would be all to happy to exploit this.
Suppose somebody recovers the necessary keys to send out fake-but-authenticated buy/sell orders on the NYSE, NASDAQ, or even commodities exchanges, with the specific intent of causing havoc with algorithmic trading, and causes a crash.
Suppose somebody is able to break into JP Morgan Chase and reveal private records, transfer information, and the session keys used to decrypt them.
Suppose somebody is able to modify a single prescription in West Bumfuck, Georgia, cause their death, and show off that they can do it again.
In all of these cases, you would see an immediate collapse of trust in important institutions. If the attackers make clear that their ability to fuck things up is the result of backdoored crypto, there would likely be spillover from one institution to the others-- "I can't even trust my pharmacy; how the hell can I trust my bank?!"
That collapse of trust would result in severe, immediate, and possibly unrecoverable damage to entire industries. That would likely destroy a lot of wealth as stocks take a giant shit.
Could somebody DO that? With backdoored cryptio, I'd say it's likely, even inevitable. Backdoored crypto either has to have a mathematical weakness inserted somewhere into the algorithm itself (in which case I would expect adversarial equivalents of the NSA to hire fucktons of mathematicians and tell them find and exploit said backdoor), or you have to do some form of key escrow (in which case the master keys used to protect session keys will be SUPER high priority for attack, including technical attacks and the famous "give the right disgruntled IT worker a bunch of money" attack).
Strong, un-tampered-with encryption is SERIOUSLY vital for national security.
Yes, some companies already have issues with this due to shit security practice, but those can be treated as isolated incidents. If it becomes clear that EVERYBODY is fucked, I would expect to see the market crash worse than it has during the pandemic.
EARN-IT is NOT OKAY by a long shot, but as others have pointed out, this is an attempt to make EARN-IT look like a responsible, reasonable compromise. It isn't a reasonable compromise, but Congress is basically a giant bag of assholes, s we're probably screwed.
I just lost my drivers license due to a medical issue (my "controlled" epilepsy ain't so much any more). My partner left for a six-week trip recently. I'm working from home because my office still can't open up. Most of the stuff near me is still shut down. I'm effectively restricted to a relatively small radius around my house.
I'm trying to get out as much as I can, and go as far as I can. I'm taking the opportunity to get more cycling in-- which is my hobby anyway, but it feels odd in light of the fact that now it's my ONLY reasonable option for, say, getting to the grocery store.
I think if my partner were home, I'd be okay. I think if I had my license and could just go around and take a drive somewhere, I'd be okay. I think if work were back to normal and I could spend the days working with people in close proximity, I'd be okay.
But it's everything together that's just screwing me up. I feel isolated. I feel trapped. I'm losing weight because I'm not bothering to cook or eat beyond the occasional slice of toast or handful of trail mix. I'm not sleeping well, which is making my seizures worse, which is going to make the wait for my license reinstatement take that much longer. All the stuff reinforces all the other stuff, which makes it difficult to break out of it.
I don't know. I'm lucky that my seizure are not, comparatively speaking, all that bad. I'm lucky that I have a job, and that I can work from home-- plenty of my neighbors and friends are out of work. I'm SUPREMELY lucky to have the love of an incredible woman whom I love dearly, and who makes me want to be a better person. I'm lucky to be able-bodied enough to go cycling, and I'm definitely lucky to have the money to afford my groceries.
All in all, I don't have it bad at all. But everything just feels like shit right now.
Hey, that really sucks about the license issue! Tooling around in my car is one of the few things keeping me sane. Hopefully you live somewhere nice enough to bike consistently. My SO and I have been walking and cycling a ton.
I understand that feeling lucky but everything feels like shit. I hope you start to feel better!
From what I understand: tech, mission, and tickets.
Say what you want, the NSA probably has some of the most interesting tech problems you'll encounter. Part of that is due to the unique job that they do-- by definition, they're doing things that nobody else in the US is allowed to do, so they need people to solve problems that don't exist elsewhere. Part of that is due to having a huge amassed knowledge particular to their area of work, which allows them to work on things that other people/organizations simply don't even know about.
Also: the NSA has supercomputers that make your eyes bleed. A buddy of mine who worked there says that even their power bills are classified. Back in the day, they developed a lot of highly specialized, one-of-a-kind hardware. Cray processors had a popcount instruction that was supposedly put in place at the NSA's behest. They can afford to get specialized treatment and demand specialized features from folks who build their computers. If speculation regarding their signal collection capabilities is true, then they also have to have serious signal processing and communications tech, too.
The NSA has interesting challenges and cool tech to work with. That can attract a LOT of people.
Another issue is mission. Look, you may not agree with the NSA's techniques and methods. But at least the original goal of the NSA-- breaking codes used by foreign adversaries to gain an intelligence and military advantage-- is pretty standard military fare, and not inherently evil. SIGINT played a major role in shortening WWII, and who knows may have happened since then (since it's all classified). The folks I know who work there are proud of their work, and believe they're doing the right thing. I'll note that these are GOOD people whom I respect, which leads me to believe that the NSA isn't just moustache-twirling and evil cackling. Some people work there because they believe they are genuinely serving their country.
Finally: tickets. Several of the folks I know have gone to the NSA, worked there a few years, then jumped ship to take industry jobs with clearances. Government contractors pay a premium for cleared workers, and if you show up with a TOP SECRET clearance in hand, your job interview chances just got better. It's a good way to set yourself up for decent job security and comfortable pay.
Sort of depends on how you look at it. A shitty, misconfigured install of MySQL on an OpenBSD box won't automatically become secure. And the default install is pretty spartan-- you're not likely to use an OpenBSD machine without installing outside software, which is not going to be developed by the OpenBSD guys. So you're only as secure as your weakest public-facing program.
I tend to look at OpenBSD as a sort of "security incubator" program, where good security ideas and practices have the chance to grow. I think that the biggest impact of OpenBSD tends to be felt in OTHER operating systems and on the internet at large.
One of the big areas where OpenBSD has pushed things forward, in my opinion, is defense-in-depth for software. They put a lot of effort into maintaining high coding standards and an emphasis on correctness. They've been active in the area of exploit prevention and detection-- they were the first to really do W^X, they've been using ProPolice by default since forever, they randomize memory addresses, etc. But they're also very active in exploit mitigation-- that is, if we start by assuming that a program IS going to have a security bug, how do we limit the damage? OpenBSD has invented or popularized techniques like privilege separation, their "pledge" and "reveal" systems, and various other forms of sandboxing.
There's also the crypt side-- their work on cleaning up OpenSSL to create LibreSSL has been an incredible service. OpenSSH has been adopted EVERYWHERE. Their work has done a LOT to reduce the amount of unencrypted traffic going across the internet generally.
> Sort of depends on how you look at it. A shitty, misconfigured install of MySQL on an OpenBSD box won't automatically become secure. And the default install is pretty spartan-- you're not likely to use an OpenBSD machine without installing outside software, which is not going to be developed by the OpenBSD guys
Depends on what you're doing with it -- but the base system ships with many things that you would want to use, and it's definitely concievable that you'd only run with OpenBSD software.
Web servers? OpenHTTPd.
Mail wervers? OpenSMTPd.
Proxies? Relayd
Firewalls? pf
Routing? Depends on what you need, but there's probably a daemon for that.
Regarding the hostname thing, the NISP SP800-90Ar1 specs for PRNGs include "personalization strings" as an optional part of the initialization. Lots of other systems have similar parameters. The fundamental idea is that randomness sources are sometimes subject to failure, especially as you ask for more and more random data (e.g., until recently, /dev/random on Linux would block if it "didn't have enough entropy", and there have been plenty of issues related to code NOT CHECKING for short reads). The NIST spec suggests using things like serial numbers, user IDs, MAC addresses, software versions, timestamps, module and applications, even random numbers derived from other sources as parts of the personalization string. The idea is that each PRNG created will always have at least one unique input to it, so you at least avoid repeated outputs if the seeds and the nonces get hosed up.
So there's a case to be made for hauling in low-randomness data, even if it doesn't help accumulate enough randomness. The hostname certainly isn't perfect (think of all those Raspberry Pis with the same hostname), but it doesn't HURT as long as we're honest about what that input is providing (distinction versus randomness).
Also: the author notes that some of the random sources they tested are highly biased. While biased output from a random source isn't GREAT, it isn't necessarily a showstopper. The key thing for security in this context is not a lack of bias, but a lack of predictability. Suppose I have a biased random source, with a 1/3 probability of outputting a 1, and a 2/3 probability of outputting a 0. If there's nobody out there who can predict the NEXT output with probability greater than 2/3 (i.e., it's not backdoored or subject to some nasty attack), then it's just fine as a random source. We just can't treat each bit we read as providing a "full bit" of random into the system. In the example above, you could just seed your 256-bit PRNG with about 280 bits of biased input. Alternatively, you could just do the old "read twice: discard if results match; otherwise take the first value" trick to get an unbiased source.
Also, it's important to remember that "entropy" in these conversations is used in a squishy way, and it's easy to mix up different definitions of the term. Folks talking about "entropy" in the context of PRNGs usually mean unpredictability, unstructuredness, unrecoverability, or some combination thereof. They typically do not mean Shannon entropy, which is essentially a measure of UNIFORMITY of output . If you feed the numbers 0 through 255-- in order-- into an entropy calculator, it will report exactly 8 bits of entropy, even though the input was clearly structured and predictable. That's why I've tried to avoid using the term "entropy" and focus on "random" or "randomness".
As for backdoors-- it's theoretically possible that things like RDRAND or a USB key or whatever can be compromised. Standard, non-dedicated randomness inputs (like keystroke timing, network packet arrival times, disk I/O info, interrupt timing, clock drift, etc.) are still included in OS PRNGs, and PRNG state is periodically updated to fold in that randomness. While it isn't EASY for a hardware backdoor to overcome this, it's theoretically possible, and it only takes a small amount of influence to create some devastating effects. Dan Bernstein wrote an article back in 2014 about the hardware backdoor idea; one very simple suggestion that he made was to simply design cryptosystems to use LESS random data (his Ed25519 system generates nonces deterministically, for instance).
FWIW, the Windows 10 RNG includes (one-time) personalization data that is non-random but maybe unique during initialization. (They don't call it that, but it's the same idea.)
Low-entropy random sources don't hurt but there's not really much point using them unless you have no better options (i.e., jitter entropy for initial seeding on embedded systems).
Better to just use the biased source directly than to make up an ad-hoc de-biasing algorithm. I'm know there are mathy ways to combine imperfect sources and get perfect entropy out, but it adds complexity, which is a risk.
Respect where it is due to DJB, but if Intel wants to compromise your system, it's already got the SMM/IME backdoor; it doesn't need to poison RDRAND. There is sometimes a disconnect between cryptography researchers and cryptography practitioners. I enjoyed and would recommend JPA et al's RWC paper, Too Much Crypto: https://eprint.iacr.org/2019/1492.pdf
Oh, there are definitely better ways to de-bias; the read-check-discard construction is meant as a math example, not practical advice. Most of the popular PRNG constructions (for instance, anything in SP800-90A) will integrate things in a much saner fashion (e.g., with a hash or MAC algorithm). I was mainly trying to make the point that a bias in a random bit source doesn't automatically mean that everything is broken and horrible.
The biased/low-entropy point was mainly in relation to a specific case mentioned in the original article (Allwinner embedded ARM systems). I don't know how quickly that particular HWRNG provides data, but if the bias isn't huge, and the random can be read quickly enough, I'd probably argue to include it. Even if it's biased 4-to-1, you can still reach a desired "amount" of randomness (however you're choosing to measure it) pretty quickly.
> you could just do the old "read twice: discard if results match; otherwise take the first value" trick to get an unbiased source.
Huh?
If I have a legitimately random source that gives 00, 10 or 11 entirely at random (but never 01 which is why we're filtering it), and you feed it through your proposed process to get a 16-bit number you always get 1111111111111111 which is clearly no sort of random.
I suppose I should have made it explicit that this construction relies on the unpredictability of SINGLE-bit reads. I had actually considered some wording about that and the independence of each sample, but figured I'd sound pedantic.
Under the system you outlined, that single-bit unpredictability condition doesn't hold, so you're right that the construction totally breaks down. Given a starting bit of 0, you can predict the next bit with absolute certainty.
For something like your random source, it would be best to just skip every other bit and look at the result as a biased bit generator. In that case, the construction works: you would have (0, 1) and (1, 0) each happening with probability 2/9, while the matching sets (0, 0) and (1, 1) happen with a combined probability 5/9. That gives (0, 1) and (1, 0) as equally likely outputs, so just consistently take one of them, and you have an unbiased source.
But what you mention DOES have some relevance to bit generators, too. One of the Bernstein scenarios deals with a hypothetical backdoored RDRAND instruction on x86. The basic idea is that the instruction is designed with some understanding of the system the values will be used in, and doing a short brute-force to see which value would fix the first four bits to a desired pattern. With the "sample, check unmatched, take first" construction, that pattern would be SUPER easy to fix.
In context, they were talking about the specific case of a source that outputs 33% 1s and 67% 0s, with no correlation between successive outputs. For the general case of a entropy source that's (not provably not) biased in some arbitary way that you don't know about, you obviously need a cryptographically secure hash function.
> In effect, Romu generators are infinitely fast when inlined.
What the hell does "infinitely fast" even MEAN in this context? They can be parallelized easily? The computational cost amortizes well? That it literally requires zero operations to generate output?
This may be something interesting if it packs a lot of the features claimed. But there are a LOT of ill-defined claims on the website, and a fair bit of time spent pointing to the state of current research in OTHER algorithms/proposals as if open questions are an automatic disqualification ("[H]ow can you know whether such a generator has enough capacity for your large job? You don’t know.").
I don't think the guy is a crank, per se-- just excited. But this is the sort of stuff that makes me think that he hasn't done the requisite level of research required before claiming a breakthrough.
> What the hell does "infinitely fast" even MEAN in this context?
It's nonsense, but their argument seems to be that instruction level parallelism allows the RNG's user to keep executing simultaneously while the RNG pre-computes its next output. So the application doesn't have to delay execution to wait for the RNG to spit something out.
Well that clearly assumes that the user code is not utilizing most of the issue bandwidth or rather that the unutilized issue bandwidth is sufficient to run the RNG and that there are enough EUs left over to actually run it. In that case you do indeed get operations "for free" (in terms of wall-clock time), because your extra operations are exactly contained within the increased IPC.
It doesn't mean that it is infinitely fast. It does however mean that in this particular case it adds no latency for adding random number generation; an infinitely fast algorithm would also add no latency for random number generation. Doesn't mean one implies the other.
Yes, the output latency is zero clock cycles. The paper contains ILP tables that detail what happens in each clock cycle. The generator computes its next output while the application is running. But you are correct in that the statement (and ILP table) assumes that the application is not using all available issue-slots.
For a lot of folks with epilepsy, this is nothing new. Plenty of medications that treat epilepsy are known to induce changes in mood, mental state, etc.
Probably the biggest one is levetiracetam (also known as Keppra). If you read the warning label, it says it can induce "mood changes", which is a euphemistic way of saying "it can turn you into an uncontrollable rage monster".
I've been there. Whatever you think you know about getting ticked off, you haven't felt angry until you've felt it on Keppra. There is no gradation of anger-- no "subtly annoyed", no "getting ticked off", no "this is really getting me angry". Just "zero" and "Incredible Hulk on a bad day". The stuff that annoys you may not be anything that annoyed you in the past, but now it's something that makes you want to bash somebody's skull against the pavement until it goes soft. And there is no warning, no ramp-up-- you just suddenly find yourself enraged beyond all human comprehension, and you're doing everything you can just to restrict yourself to yelling incoherently instead of resorting to physical violence.
There's even a cute nickname for this whole horror show: "Kepprage".
I'm off levetiracetam now (onto lamotrigine, which is also prescribed as an antidepressant). But it scared me pretty badly. I genuinely fear getting angry now-- because I worry that I'm going to wind up back where I was. I was single when I was on Keppra, but I'm in a relationship now-- it scares me to think what I might do if I ever get back to Kepprage levels of anger, because it could easily cost me my partner.
So, to your question: was I a different person on Keppra? I mean, I still responded to my name and worked the same job and had the same favorite foods and such. But I was a lot angrier, I was getting angry all the time, and there was no off switch. It's a valid philosophical question as to whether that makes me a "a different person". Looking to your example, consider that feeling that you have on alcohol, and its assorted side effects and behavioral changes. Now imagine that you were stuck in that mode, 24/7. Would you be "a different person"?
> 10 years from now, it might be as good as plain text.
I created an account just to chime in on this.
In short: horseshit.
Look, cryptology is a tricky field, but when it comes to standards development (especially OPEN standards development, without government intervention), it's mostly been hits, not misses. While there are occasional breaks and busts, the fact is, most of the trusted algorithms have remained trustworthy-- lasting through their designated lifespans, and often a lot longer. Many of the algorithms that you hear are "insecure" aren't really insecure due to any math advances; they have simply fallen victim to their already-known limitations, or are "insecure" when used in specific ways.
For instance, look at the Blowfish block cipher. Blowfish was designed and released almost thirty years ago. Its current biggest security issue is not some tricky biclique attack that allows key recovery on a desktop computer or something. The problem is that the block size is 64 bits, and in modern contexts, that's just too small-- networks shuffle enough bits around these days that a 32-gigabyte encrypted transfer is suddenly a realistic use case, and there are known attacks related to that. 64 bits was fine at the time, and the block size was a known limitation of the algorithm (birthday attacks are well-understood). The algorithm didn't fall; we outgrew the use case.
Going back even further: DES was released nearly FORTY-FIVE years ago. It was released with a 56-bit key, which was known at the time to likely be in brute-force range for certain Nation State Adversaries. It has the same block-size issue as Blowfish. But it's actually stood up to cryptanalysis pretty well, given the power of the attacks that have been developed since then. Triple-DES, properly used, is plenty secure for lots of applications-- it's still even promulgated as a standard algorithm for a lot of financial industry systems.
More germane to modern encryption practice, AES was standardized nearly 20 years ago, and has been studied for even longer. It's still a solid algorithm today. There are a few implementation caveats if you want to avoid things like cache timing issues, but the algorithm itself is holding up very nicely to mathematical advances-- the best known mathematical attacks drop the security levels by 1 to 4 bits, depending on key size, which is... well, it's worse than 0 bits, but it's certainly nothing to worry about. AES has been integrated into processor designs, it's used to protect US government information classified up to TOP SECRET, and it's supported by nearly every cryptographic suite out there-- because of all of that, the algorithm has remained a significant subject of ongoing research, and it has stood up to the scrutiny beautifully.
Cryptography is always advancing, and sometimes algorithms do fall to mathematical breakthroughs (RC4 has been battered pretty badly, for instance, and SHA-1 is clearly dead now). But for the most part, cryptologists try their damnedest to know the limitations of their algorithms, and they're pretty up front about them.
I'll also point out: cryptologists are aware that there's risk associated with mathematical advances, and they hedge their bets. Note that there is now a SHA-3 standard. That's not because the SHA-2 algorithms are dead. It's because, while we're pretty sure they're secure, the SHA-2 algorithms are cut from the same mathematical cloth as SHA-1 (they use the Merkle-Damgard construction). SHA-3 was standardized with the explicit purpose of adding diversity to the pool of standardized algorithms. NIST is currently running a post-quantum public-key standardization effort, and has made it very clear from the start that they'd like to select multiple "winners" from multiple categories. Part of this is to allow flexibility for different use cases (key size / message size / performance trade-offs vary wildly for different classes of algorithms). But another part is preventing a complete disaster if one class of algorithms is broken (either classically or with a quantum computer).
All ciphers older than 100 years have been broken, except for one.
However, it seems to me that designs improved exponentially, while attacks only improved quadratically. The old days of WWII where Enigma was broken before the end of the war will never happen again.
Conceptually, it makes sense: Science improves quadratically because breakthroughs improve tooling that accelerate breakthroughs. I am simplifying here, but if you have N tools at T1 that make you progress at rate R1=N×K, and that progress yields another tool: at T2 you have N+1 tools, making you progress at rate R2=R1+K. Your progress is P2=P1+R1, which generalizes to Pn+1 = Pn+n×K = P0+K×N×(N-1)÷2, a quadratic progression.
On the other hand, cryptographic security is exponentially better with every bit. If an old cipher uses its bits badly, it will still be good enough if it is long enough. Let's say it reaches a given difficulty level after 10 rounds; a cipher that uses its bits twice as well will reach the same level after 5 rounds, but would have something like 2^K times that level after 6, 2^2K times after 7, … 2^5K times after 10, reaching a level that quadratic improvements won't reach for an increasingly long time.
For instance, it took 5 years for MD4 (1990) to have a practical collision, 12 for MD5 (1992), 22 for SHA1 (1995), therefore roughly doubling every three years. If we extrapolate, SHA2 will have a practical collision in 2080.
There's a quantum leap in cryptography in WWII and it's a real shame that's so rarely explained even at Bletchley where they'd be well-placed to do it.
Engima (like most systems in use in the 1930s) is thinking about cryptography as being some sort of art in which the idea is to sort of stir letter symbols. Everything else often can't even be encrypted or must be elaborately transformed into letter symbols first. Bletchley has replica "Bombes" which would be used to attack this mechanically, replicating the function of the Enigma machine to defeat it.
Lorenz, which was also attacked at Bletchley using the Colossus, is a modern stream cipher. It XORs a pseudo-random stream against your plaintext bits (albeit in the 1940s these were in 5-bit ITA telegraph code) and so it isn't different in core principles from say RC4 or at a greater distance in time indeed Salsa20 - Lorenz just has about 56-bit keys where these modern ciphers have more and are better designed. Attacking this mechanically was impractical, and that's why a computer like Colossus was needed.
As a result it really isn't fair to compare 100 years ago. If we look back 50 years instead the difference is stark.
Consider a foreign adversary with the ability to break encryption used by banks, credit card companies, large retail facilities, hospitals, etc.
There are a few things that seem tempting-- think "steal from the banks", but a lot of that is unlikely to work, anyway. Banks and wire transfer systems have auditing and verification measures in place that would make it difficult to pull this off successfully. Credit card companies and retailers would have a serious issue with reissuing cards, etc.
What would turn things upside-down is the LOSS OF FAITH in these systems and the economic, social, and practical effects. The Russians would be all to happy to exploit this.
Suppose somebody recovers the necessary keys to send out fake-but-authenticated buy/sell orders on the NYSE, NASDAQ, or even commodities exchanges, with the specific intent of causing havoc with algorithmic trading, and causes a crash.
Suppose somebody is able to break into JP Morgan Chase and reveal private records, transfer information, and the session keys used to decrypt them.
Suppose somebody is able to modify a single prescription in West Bumfuck, Georgia, cause their death, and show off that they can do it again.
In all of these cases, you would see an immediate collapse of trust in important institutions. If the attackers make clear that their ability to fuck things up is the result of backdoored crypto, there would likely be spillover from one institution to the others-- "I can't even trust my pharmacy; how the hell can I trust my bank?!"
That collapse of trust would result in severe, immediate, and possibly unrecoverable damage to entire industries. That would likely destroy a lot of wealth as stocks take a giant shit.
Could somebody DO that? With backdoored cryptio, I'd say it's likely, even inevitable. Backdoored crypto either has to have a mathematical weakness inserted somewhere into the algorithm itself (in which case I would expect adversarial equivalents of the NSA to hire fucktons of mathematicians and tell them find and exploit said backdoor), or you have to do some form of key escrow (in which case the master keys used to protect session keys will be SUPER high priority for attack, including technical attacks and the famous "give the right disgruntled IT worker a bunch of money" attack).
Strong, un-tampered-with encryption is SERIOUSLY vital for national security.
Yes, some companies already have issues with this due to shit security practice, but those can be treated as isolated incidents. If it becomes clear that EVERYBODY is fucked, I would expect to see the market crash worse than it has during the pandemic.
EARN-IT is NOT OKAY by a long shot, but as others have pointed out, this is an attempt to make EARN-IT look like a responsible, reasonable compromise. It isn't a reasonable compromise, but Congress is basically a giant bag of assholes, s we're probably screwed.