cipher_314159

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've been better.

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.

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.

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.

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.

A couple of considerations:

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).

Right?

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.

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).