HN Simulatornew | past | comments | lists | submit | FiloSottile's commentslogin

This is some serious severity inflation.

Skipping CRL checks is not a Critical. A Critical is "whoops we were not checking the signature on the certificates" or "I guess all zeroes is a fine session ticket key" (both happened, the former in wolfSSL, the latter in GnuTLS).

Bypassing chain length limits is... barely a Low? It's definitely not a High.

The DHE one is fun. It'd have been valuable if they spent some tokens figuring out if any open source library would accept those broken parameters. If not, it doesn't really matter. (Another good reason not to negotiate DH parameters ever!)


This sort of breathless outrage rhetoric would be a lot easier to take seriously if it spent even a minute acknowledging the very real risk to users that this is meant to mitigate: tech support scams where people are walked through installing an app that takes over their phone and steals their money, private data, and identity.

You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

Personally, I think the 24h cooldown is an excellent compromise to allow user freedom while slowing down attackers sufficiently to mitigate the harm.

Tech is cool, but it's not an end in itself. Serving people should be. And if people are getting hurt, it's not working well, even if those people are not the ones that read Hacker News.


I don't think you can just do anything you want in the name of security and protecting users. This will make installing apps needlesly difficult. There is already a warning when enabling installation of apps from unknown sources. That should be enough. If users don't read that's on them.

The real problem here is not that Google is doing this bad thing. The real problem is that they can do this bad thing. They shouldn't have this power. Something needs to be done to rain in Google and take back Android as an open platform.


> If users don't read that's on them.

Nobody reads warnings or errors. StackOverflow is full of questions where someone pastes a clear error message and asks what they have to do when the very error message tells them the solution.

Also, scammers just tell people to ignore warnings and they do it. If someone is able to convince you that your child is in danger and that you have to bypass all warnings to help them, you _will_ do it.


Users don’t read warnings. Most scams capitalise on urgency. When given more time to stop and think something through, it often becomes obvious what’s happening.


> Users don’t read warnings

Why should that be a concern to a phone OS provider? A concern so important that they are willing to cripple couple billions of devices.


Courts make you liable for results, not intentions, like the way Quad9 is now an illegal piracy operation in France because it doesn't block pirate sites.


So why don't courts make knife manufacturers responsible for murders?


Only because they've chosen not to


There is a very real usability issue that has to analysed when developing high risk products, and that's popup fatigue.

A huge number of people just click accept to any popup they get because they're so fed up with seeing them. It's something that is often analysed in design of medical products


I experienced this problem in semiconductor manufacturing.

It was really difficult to explain to Korea that the additional warnings they wanted me to put in front of the tool operators were actually causing more harm than good. The cultural divide made this really difficult to approach.

"What do you mean the American mfg staff don't actually read everything?!"

"Yeah... Especially at the ATX line. We kind of go off vague shapes around here"


> There is already a warning when enabling installation of apps from unknown sources. If users don't read that's on them.

Hard disagree. My grandma is just going to follow the scammers directions.


> That should be enough. If users don't read that's on them.

The phone scammers who are saying the FBI/NSA/IRS will arrest you unless you install sketchy remote access software or other malware are rather convincing to a certain demographic of people and no amount of text on the screen will stop that. It all comes down to whether or not you view the tradeoff being that vulnerable people are worth protecting with this measure worldwide or not.


>Something needs to be done to [reign] in

Should Google be less than an asshole in all things? Yes.

I think there’s this like “something must be done now!” attitude of self-important, busybodies I can’t get behind… even if they’re right.

Why have people convinced themselves into thinking now is the most important thing in the world? That if it doesn’t happen now so that it makes me happy instantly it isn’t an option?

Evolution; social, tech, biological, legal, just fucking takes time, and that’s a feature.

There will be a period in which there’s a ton of food over there but your little fishy fins can’t get to it, and that sucks, but deal with it yourself, or just chill and let things happen. I promise if it’s important someone will solve it eventually and the scales do not need to be tipped for every little thing like phone app permissiveness.

In the meantime, you are free to not buy an android phone if you don’t like the system that Google has produced. You seem to think that because you can see its insides that it is collectively owned. It isn’t. Google owns it. Talk of talking it from its owners, is theft. In this case, justified entirely because you don’t like a process they decided on.

Don’t make me defend Google, I fucking hate Google.


I have huge incentives to have a phone. It means Android or Apple. not exactly a flourishing free market of choices. Banks, the government, places I want to go to all either force me to use an app, or create costs in money and time if I want to avoid using one.


>You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

There is a third position beside "I agree/disagree with the tradeoff", which is "I don't consider the tradeoff as stated truthful and refuse to frame the conversation that way".

Every closing of rights comes with a legitimate-sounding reason. Protect the children, etc. Most activist have been through this process enough times to see the play coming a mile away.

It is also surprising to see, on a place called hacker news, people defending closed systems and removal of agency from end users by giant corporations.


As silicon valley shifts from cyber-libertarian to cyber-authoritarian, so will HN, unfortunately.


Many scams are committed thru apps like AnyDesk, TeamViewer, RustDesk... That are apps already in the store. That is a very cheap, easy, proven way of doing it.

Fear, uncertainty, and doubt is a propaganda technique that tech companies have used for long against open source and competitors. The propaganda is to pretend that a 24 hour cooldown and making it difficult to install externals apps is for the good of the user meanwhile stealing their data and giving it to anybody that pays for it.

People are getting hurt. Mass spying should stop now.


Or even Whatsapp, which people already have installed on their phone. No need to go to the store to install anything.

A scammer managed to convince a relative to share their screen during a Whatsapp video call. Luckly, said relative didn't use banking apps on the phone, the bank rejected as suspicious the transaction on the computer which would have sent money to the scammer, and the relative asked me for help before going to the ATM to unblock the account (I then contacted the bank and had them fully block the account as a precaution, and told my relative to go to the bank branch the next day to change the passwords and unblock the account).


I’m all for trying to stop those who are getting harmed from being harmed, but at what point do we acknowledge the ignorance of those people? Installing random apps, provenance truly unknown, to your phone is a bad idea because of the security risk in doing so. I’d have the same advice for someone operating a windows PC. Don’t be downloading and installing random .exe to your environment, you’re gonna have a bad time. The former seems to be this mysterious new idea, unable to comprehend. Most people seem to know the latter and you get flamed for admitting “I installed this random .exe recommended to me by this dude on the phone who said he’s helping me.”

People gotta learn. Sometimes the best teacher is pain and suffering. I wish that weren’t true, but in my time on this planet, there has never been more truth to “you can lead a horse to water, but you certainly can’t make it drink it.”

Trying to save people against their will just doesn’t seem the best path. I’d rather more effort be put into education on best practices, or investment in an app sniffer that can try and identify common attack vectors. Idk, anything other than “some people are too stupid for their own good, so now we all have less freedom.” I mean truly, if you’re worried about grandma’s phone safety, only let her buy an iPhone. No android for mi-ma.

All I see here is Google snatching at the opportunity to get some of that scrumptious walled garden money.


Phone carriers can't be bothered to police their networks to mitigate flagrant bad actors, who can't be shut down by state law enforcement, so your software company needs to take control of your device away from you. "For your own safety."

It's just a public confession that none of these organizations - not the carriers, not the government, and not Evil Google, are fit for the responsibilities they've claimed.


Huh? You’re arguing for carriers to inspect all traffic to block scammers? That’s way more intrusive than google blocking sideloading. The outrage on places like HN would be deafening.


Are you kidding?

Small businesses getting blocked by Gmail, Twilio, etc. for legitimate activities is constant.


After researching this for some time, the majority of scams are perpetrated with apps that are already in the Play Store and are remote access apps. The entire premise that the Play Store is safe and everything else is dangerous is not borne out by the empirical evidence.

> You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

I would turn this right around and say that until the proponents of this measure acknowledge that the Play Store is not safe and is in fact a primary vector for scams, you're just doing propaganda.


The topic has been discussed multiple times, and propaganda really feels like not acknowledging past discussions. You might not have seen past discussions so I'll give you a pass and restate my argument.

One important way that scams reach end users are through the willing participation of ad platforms, and even before DSA (not that much has changed) people (myself included) have done countless reports of straight up scam ads with no recourse and a templated "we have found nothing wrong with the ad".

As a data point, have you not seen the Tai Chi AI ads on YouTube that will "make you a different person by the end of the week" which where run by a company that sold you a subscription via dark patterns with all the surprises that brings (like a big headache of an unsubscribe process).

Or the fact that Meta knows that X% of it's ads are scam/phising and do nothing about it because it hurts the bottomline (an AI chat will help you with references).

The hypocrisy is too much coming from Google since they are owners of the machine that feed scams right to your doorstep.

And let's not ignore all the other fronts they are fighting on to further lock down the Android platform (such as not making source available immediately and moving more of the runtime in their play services and platform integrity nonsense).


> the very real risk to users that this is meant to mitigate:

The risk of people cutting themselves is not a responsibility nor a concern for the knife manufacturers. I would be very upset if one day all kitchen knives would be sold blunt just to mitigate some clueless people from cutting their fingers off.

Similarly, I seriously and absolutely don't get it why people falling for scams should be a reason to require KYC to distribute apps.

Especially given that KYC-passed accounts are easily obtainable online for pennies.


Uh it absolutely is a concern and a responsibility . Different knives are made the way they are precisely to avoid people cutting themselves accidentally during various kinds of cutting motions. Additionally blunt knives are significantly more dangerous than sharp ones which is why they don't ship blunt ones.

Maybe before trying to go off half assed exactly like this outrage website does, you should take 5 minutes to be bothered to see if what you are saying is even mildly correct. Even five seconds of searching would tell you pretty much everything you wrote is wrong.

Lots of things are compromises intended to serve multiple goals rather than just drive one particular goal to the extreme. In that sense knives are exactly like what is happening here. You may not like that. But it is at least accurate, unlike what you wrote


You must be fun at parties


You are the person nobody invites because they won’t stop saying dumb shit about their super strong opinions and ruins every conversation.

anyone who ever attempts to point this out gently just gets made fun of by you while everyone backs away slowly and deletes you from their phone


I'm somebody who likes lifting weights. I often lift weights heavy enough that, if done improperly, could harm me greatly and grossly.

There are people at my gym who often have very bad form who I worry about. I will occasionally chat them up so they're not, for example, shoulder pressing with their arms outside of the scapular plane [0] or benching without any arch in their back [1]. Sometimes they appreciate it and ask me more questions. Sometimes they give me a terse 'thanks' and go back to doing it the way they want to do it.

If somehow every gym started forbidding people from using any equipment with which they could harm themselves unless they could prove, with a 24h cooling off period, that they knew the form and dangers in detail, I'm sure it would probably save a few people from suffering temporary injuries. I think it would also drive a lot of people away from any kind of sustained resistance training and be an overall net negative for public health.

Personally, I don't think such a nanny-state implementation is necessary? That you should be able to easily toggle off such a feature if you like and what happens to you happens. Perhaps there should be a 'tech-illiterate' mode toggled on by default but easily toggled off if you know how to access Developer Options with a little more forewarning about common scams. Perhaps gyms (or Google) could pay people to proactively assist and help people they see as the most vulnerable to certain kinds of exploits. Perhaps instead of spending time training Gemini to be a general-assist LLM they could train a very small local model to hyperspecifically guard against known intrusions.

There are so many more pro-social, less-draconian ways of tackling safety issues, from socialization to ongoing support to education efforts. A lockdown that just happens to also help ensure that they can extract their pound of flesh inside the abattoir that is Google Play seems at best overly protective and at worst just more corporate extraction of surplus value from individuals.

[0] https://brookbushinstitute.com/glossary/scapular-plane

[1] https://www.strongerbyscience.com/how-to-bench/#:~:text=it%2...


> Personally, I think the 24h cooldown is an excellent compromise to allow user freedom while slowing down attackers sufficiently to mitigate the harm.

The best solution would have been to be able to mark ANY alternative app store like fdroid as trusted and no such cooldown period would hit every time people install an app from there. This avoids that people can immediately use installed apps downloaded from an arbitrary URL but at the same time keeps the alternative app stores as a good alternative. Google decided to play unfair again.


The 24 hour wait happens once, not on every app install.


Oh, ok, thanks for the information. But if it is a one-time, device-level wait, not per source and not per app, then I'm unsure how this should prevent scammers in the long term?

I'm pretty convinced it is just Google testing boiling the water steady and slowly :)


Scammers often create a sense of urgency/emergency, especially over the phone, and putting a 24hr limit on it gives the person more time to possibly realize they're getting scammed.

It's not 100% perfect, but it helps reduce scams. And with AI, scams are probably going to get more frequent and harder to realize it's a scam.

If you know you want your phone unlocked, just start the process as soon as you get your phone, and then it's yours. It's like an extra day of shipping.

-

Edit: Google explains this more:

In these scenarios, scammers exploit fear – using threats of financial ruin, legal trouble, or harm to a loved one – to create a sense of extreme urgency. They stay on the phone with victims, coaching them to bypass security warnings and disable security settings before the victim has a chance to think or seek help.

According to a 2025 report from the Global Anti-Scam Alliance (GASA), 57% of surveyed adults experienced a scam in the past year, resulting in a global consumer loss of $442 billion.

https://android-developers.googleblog.com/2026/03/android-de...


Thanks for taking the time to explain this. This sounds reasonable to me too. However, it might be just the start :)


When I was still on android, I installed F-Droid to avoid the google app store entirely, since the google app store's vetting is -uh- not very good.

The correct move is to remove the (icon for) the google app store from inexperienced user's phones. (I'm dead serious, and it works)

Unfortunately, that's exactly the move that now gets sabotaged by this google change.

So sure I'll acknowledge the very real risk to users that this is meant to mitigate. It does in fact marginally mitigate the precise narrow risk they state, but introduces a fatal flaw in its place. Probably unwise to let naive users use android at all anymore after this.


> This sort of breathless outrage rhetoric would be a lot easier to take seriously if it spent even a minute acknowledging the very real risk to users that this is meant to mitigate: tech support scams where people are walked through installing an app that takes over their phone and steals their money, private data, and identity.

1. Is requiring developers to submit government ID actually an effective way to prevent tech support scams? Will scammers actually be deterred by a government ID requirement in addition to the existing developer registration process?

2. Is requiring developers to submit government ID the best option to prevent tech support scams? Are there other options that Google could use to make Android user less susceptible to tech support scams?

> You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

The tradeoff, such as it is, is acknowledged on keepandroidopen.org under the "But wait, isn't this...just about security?" section:

> The security rationale is a smokescreen. Google Play Protect already scans for malware independent of developer identity. Requiring a government ID doesn't make code safer.

Finally:

> Personally, I think the 24h cooldown is an excellent compromise to allow user freedom while slowing down attackers sufficiently to mitigate the harm.

I don't think this is an excellent compromise. Scammers are persistent. I'm not convinced a 24 hour cooldown is enough to deter them in any meaningful way. I, on the other hand, am not persistent enough to wait 24 hours to install an Android app from F-Droid just to try it out.


Why do we keep having to sacrifice our freedom for the fake safety of the ignorant and their continued freedom to be ignorant?

Why do we have to be lectured on how important this change is for their safety, while the Play store continues to be the primary location scam apps come from?

When do the companies get to be the ones that have to give up freedoms in favor of everyone else's safety?


Another small credit to Google - their developer registration (which unlocks all of this) is CHEAP.

Apple's is a scam in comparison and must be repaid every year.


That is a real concern, but I don’t for a minute believe that it’s Google’s only motivation. This is also securing a revenue stream and making it harder for others to compete.

Full disclosure, I am an iPhone user in part because I personally like living in the walled garden. But I also acknowledge that it has its downsides. I have a separate Android device just for language learning because the open source language learning app ecosystem is basically nonexistent on Apple’s locked-down platform. I’m not thrilled about the possibility of that ecosystem withering and dying on Android, too.


Google, who gladly take the money from criminals in exchange for funneling victims to their scam websites have the moral high ground and are unfortunately forced to take away the user's freedoms?


Google has an entire org dedicated to detecting and preventing bad ads.

I have many coworkers who work very hard on this problem.

The claim that Google does not care about ads integrity runs counter to my experience.


Look at the incentives. Google makes money from scam ads. Most ads I see online are scams of some sort. If Google completely blocked scams, they might not be in business.

Yes I understand that Google says they care a lot about scams and that there are people there working on blocking scams. But those are words. We need to look at money.

There is a very simple way that Google can block basically all scam ads: review all ads manually before approval, and allow no dynamic changes. They won’t do this, because it would implode their business model.


Look at the incentives. Google makes money from ads. Bad ads cause users to distrust Google ads, causing those users to be less valuable, causing advertisers to spend less with Google.

The goal is maintaining a continuous stream of revenue, not killing the stream for short term gains.


There have been a ton of scams my Customers have reported over the years that I've traced back to users clicking bad ads.

Google may care a lot, but if my experience is any indicator they don't care enough.


Work smarter, not harder.


1 day old account, name is a string of numbers, every comment is argumentative. Yep, all the signs are there


So Google is going to tackle scams on youtube too right? Because they care so much about the poor scam victims, and this has nothing to do with establishing overarching control.


Googler propaganda. Huge majority of scams is through play store apps and AdMob ads. Google doesn't care about scams, they care about control and sucking up money.


I'm fine with this as long as F-Droid and other stores are treated equally.

If I have to wait 24h to install an app from another store, I demand the same to apply to AppStore. I see app stores just like browsers: users must have the ability to choose which browser they want when installing an operating system, and for Android, users must be able to select which app store they want and they should work the same way.


> I think the 24h cooldown is an excellent compromise

I don't. An hour would make the same point and provide the same level of protection. So would clicking through a few screens with very simple and easy to understand warning messages about the risk of scams. Sure, it's a compromise, but it's pretty much the opposite of excellent.


> You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

I strongly agree with this statement.

If a piece of public communication is intended to sway the reader's opinion without informing them (or while selectively informing them, which is close to the same thing), it is propaganda.


If that's really what it is, Google should put their money where their mouth is. I'd be ok with this change if you had to go through all the same hoops to install apps through the Play store.


Is this really just a 24h cooldown once?


That's what they said it's going to be. A one time 24 hr cooldown to turn on the "Allow Unverified Packages" setting, not 24hr per app.

And then you have the option:

- unverified packages either temporarily (7 days)

- or indefinitely

Official docs here:

https://android-developers.googleblog.com/2026/03/android-de...


Yes. Visit https://keepandroidopen.org/ and ctrl+f "escape hatch" for more info


for now.


There is already many warnings and if the can get you to do that they can get you to other types of scams rather don't require installing an app like sharing data, putting info on websites.


What a surprising take coming from a Google employee.


Is it for safety or for collecting more rent. Certainly google can withhold installation till the new app is tested with their super duper Ai.


Do you really think there are enough affected developers that it will move the revenue needle at all for Google?

I think this was probably a very easy decision for Google after they weighed benefits and harms to users and developers.


I am certain that its not about harm but rather US supremacy doctrine. They are tightening their noose. You have to be approved to live in their digital world and pay rent.


So this will end tech support scams, then?

Also. I regularly remove malware from people's android phones pro bono in and around my community. It all comes from the play store.


Sorry, I get where your emotions are coming from with this, but it is just technically wrong on every level.

The vast majority of tech support scams come through apps on the Play Store. Not only that, but malicious apps get approved on the Play Store constantly.

There is no reason to take any claim that this change is meant to mitigate scams seriously, because there's no evidence to support that it makes a noticeable dent in such activity.

What this change does noticeably and impactfully do, is prevent, via chilling effects, users from being able to use their phones in ways that could lose Google and its partner vendors post-sales revenue.

As you said, serving people should be the end in itself, and this change doesn't do that - it hurts people.


It's like locking people out of their own home, and then when people express outrage the concern troll steps in from out of frame to point out that they're not acknowledging the very real risk that if they could access their own house gasp they might accidentally let the wrong person in, or break something, or whatever.


This comment is legitimately just "think of the children!?!!" with extra steps.

Simply add a setting to the phone for the technologically illiterate and/or young and old.

I can't even imagine how locked down and terrible the internet would be if we had this rhetoric around in the 90s.


You think the tech illiterate are going to turn on their own protection? So it's on by default, then this adds a 24 hour wait to turn it off


It's exactly the same as the people crying conspiracy about parts-locking for repairability, not acknowledging the real effects it had on phone thefts and the pressure at the national and governmental level to help solve the epidemic.


What would help a lot from Google side is:

1) make it optional

2) don't put it on a timer. What's most damning, in my opinion, is that this is the very definition of a bait-and-switch. Any rational person thinks this won't apply to their existing phone because it came before the rollout, right? It's only android 15 and onward? No. That's wrong, it'll apply to YOUR phone. Google. Non-Google. Doesn't matter. Android 12, 13, 14? Nope applies to them all. That's just an accident then?


This is nothing but a business decision to extort money from developers and you know it. It's anti-competitive at its core, locking out other, more reliable app stores and taking control of an open source operating system. It's just one more measure in a long trend of fulfilling the wet dreams of large tech, namely killing personal computing and controlling everything people can do with devices they've bought.


> You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

The propaganda I'm seeing is coming from Google. I can't tell you how many times lately I've seen ads on TV/streaming pushing the security narrative for Play Store. Google knows what it is doing is blatantly anti-consumer and they very much want public sentiment to think it's not.

There will always be means to scam individuals through technology. Pulling stunts like this is not justified simply because it closes off one means of doing so.


This sounds like know-it-all propaganda as well. Why not make it opt-in? Google (and other Big Tech companies) seem to think they know better than everyone else, even though they are also completely untransparent about what they do.


I did not discover the issue. I just wished to have a rapid and definitive way to test the patch(es).


Am I off base, or should I be surprised that you were able to get the mentioned cert issued in the first place this recently (yesterday)? It seems unexpected that certificates are being actively issued and logged coming from a to-be-forcibly-distrusted part of the hierarchy.

The bugzilla issues mentioned elsewhere suggest at least a mostly orderly removal of trust with issuance stopped several months ago. Your new cert was issued by “CN=EM DV TLS CA - G3B,O=eMudhra BV,C=NL”, which presumably chains to the G3 root, and the bugzilla issue seems to say that G3 was going to be dropped from the root lists some time ago but that maybe it would be cross-signed by something still trusted. So I assume that something else is going on.

Was that cert issued via normal means (e.g. ACME)?


I think that the Go project is lucky to have you. Thank you for what you do!


As far as I know 30 minutes validity is no one's goal, even long term.

The most aggressive plans (not Let's Encrypt's specifically) target 7 day validities.


And at how many days or minutes does it turn from security into security theater?

If we follow this line of thought it would be more secure to only serve sites to consumers through a few "trusted" third parties right?


> If we follow this line of thought it would be more secure to only serve sites to consumers through a few "trusted" third parties right?

No.


Given how expensive this computation would have been in 1997, it makes perfect sense they'd taken months, but even if we assume they tried all timestamps of 1997 and selected arbitrarily among the first 16 viable candidate of any timestamp, that's just ~30 bits of freedom.

Finding out there is a class of weak 256-bit elliptic curves so large that they can be hit randomly with 2^30 tries would be a cryptanalytic breakthrough analogous to discovering all elliptic curve cryptography is broken.

Read section 3.1 of the Koblitz and Menezes paper. It was already implausible with 160 bits of freedom. https://eprint.iacr.org/2015/1018

If you want to believe the NSA knows ECC is broken and chose to risk moving the US government to it and somehow no one figured out the same break in 30 years, you're free to do so. But pretending the seed choice plays any role in that theory is over.


This is unrelated to the above comment, but I figured I'd ask while we're here. You state at the end of your blog post on this topic that you'd now probably recommend the NIST curves over Curve25519. Why is that?


I'm guessing affinity towards prime curves vs cofactor.


As a complete layman, I do wonder why n grows with each subsequent curve, rather than with number of bits. Does this not suggest they were 'searching harder'?


Almost all of the smaller values of n are not valid curve values, so they were searching "harder" but just for valid seeds. If you look at the generator output in [1], you'll see that:

1. Only a very small number of valid seeds were discarded when compared to the number of n values. It seems we don't yet know why about half of the valid seeds were discarded but the explanation of a buggy curve validity checker doesn't seem implausible to me.

2. Directly to your point, most of the prime192 and prime239 curves required larger n values to find a valid seed and they are both smaller and used an earlier timestamp.

[1]: https://words.filippo.io/seeds-solved/


>they can be hit randomly with 2^30 tries

More precisely: not very random tries.


unless your guess is that the hypothetical ECC weakness is somehow correlated with the LCG structure, the draws from the LCG are as good as random.

It is possible such a correlation could occur. but it would be much weirder than this being the result of a random search, which would already be very weird.


I find it slightly less weird because I see potential for indirect attacks on the not-quite-so-ECC parts of actual implementations. Wherever a network client can ask many times for each of the different, but somehow not entirely uncorrelated curves, it might be able to expose previously not deemed critical side channels. Following in the general direction of the discoveries that so far resulted in IV and padding determinism/randomness being considered as important as the "actual crypto" itself. In that case the structures that would need to somehow interact would not be ECC and LCG, but merely LCG and key derivation..


Yeah... It would only be the second time they tried to do exactly that, with elliptic curve related crypto nonetheless


If your comparison here is to Dual EC, the two constructions are utterly unalike; you might as well compare it to the DES S-boxes.


Sure, the construction is different, but for all I know, there is a weakness in some subset of curves, and by not using open "nothing up my sleeve" practices for selecting their curves, they invited speculation. My point is that this is an untrustworthy actor who has shown itself to be untrustworthy on many occasions, and that you could make a similar migration argument about that, since it was pushed through FIPS. The fact that it was also EC based was not very relevant, I just thought that was funny.


I'm having trouble understanding what you're arguing here. We now know they essentially did use a nothing-up-my-sleeves seed; they just didn't care enough (it was a very different time) to reveal that.


[flagged]

Is the entire dunk here that Dan Bernstein doesn't like what I wrote about PQC? What part of what I just wrote are you trying to respond to?


  >even if we assume they tried all timestamps of 1997
Why limit to that? Especially since the official history had it as "hashed passphrase" (which would, of course, provide ample entropy).

A confusing official story doesn't disprove anything. If anything, that would be standard operating procedure for a signals intelligence plant.

  >Finding out there is a class of weak 256-bit elliptic curves so large that they can be hit randomly with 2^30 tries would be a cryptanalytic breakthrough 
NSA is the largest employer of mathematicians in the world.

A breakthrough would indeed be a terrible thing to waste. If I had one, I'd make a good and boring official cover story, and stick to it! Regular old spy-craft stuff, in other words. ;)


"..chose to risk moving the US government to it.."

Oof, about that...


go on...


There is some evidence that they have done it becore.

Specifically, that they had a backdoor for Dual EC DRBG[1], and pushed for a shorter key lenghth for DES, to intentionally weaken it.

It is, obviously, controversial. But I think there is certainly enough there that I wouldn't be confident that the NSA wouldn't recommend something they knew to be weak in some way, even to other government organizations.

[1]: https://en.wikipedia.org/wiki/Dual_EC_DRBG


3DES...


What about it?


It was widely used, even in government and military. Who knows if they actually used the same as everyone else in actuality. I guess none of this is proven beyond doubt, given the nature of all this?!

    Reporting on declassified history says the NSA pushed for a shorter DES key; the compromise was 56 bits

    NSA and a suspected cryptographic backdoor: the Dual_EC_DRBG random-number generator was the subject of reporting about an NSA backdoor and an alleged payment to RSA. RSA denied knowingly weakening its products.

    TLS 1.0’s CBC chaining made IVs predictable and enabled the BEAST attack. That’s a documented protocol weakness, allegedly put in there by US state actors on purpose.
YMMV but none of this would surprise any reasonable person given Snowden's revelations.


Please please don't bring AI generated text as arguments such discussions. Especially not without saying that that's what you are quoting.

Quoting something implies that it has certain authority (like a crypto expert) and the correctness track record of AI generated text is obviously shaky.


There's only so many formatting choices available on HN. Making a nice looking "bullet point list" of things, the best I've found is so far is to

    use
 
    monospace

    support
:shrug: That does not mean they're quotes or else there'd be a [1] with a link or names. Let me know if you have a better way; make sure it looks nice!


This CBC chaining thing is my all-time absolute favorite cryptography conspiracy theory, because on the IETF list where it happened (it happened for IPSEC, not for TLS, for what it's worth) Phil Rogaway pled with long-time standards body people --- even took up a petition of cryptographers, including Rivest --- and was openly and viciously mocked for the attempt.

The US government had no need to corrupt IPSEC standardization. The IETF did the work for them without prompting.


Hello, the US government paid the IPSEC devs to include weak and backdoored algos back then. All revealed during the Snowden era


Nobody thinks the people who shouted down Phil Rogaway, who include relatively famous standards nerds, were NSA plants. It's uncharitable for me to keep calling them out by name, but IYKYK.

You have far more to fear from standards bodies just acting like standards bodies (limited recent exceptions notwithstanding) than from government interference with standards. Like I said, all NSA usually needs to do is sit back and wait for standards groups to come up with Heartbleed on their own.


Pushing for shorter keys can be reasonable, otherwise we would all use 16 MB keys


> TLS 1.0’s CBC chaining made IVs predictable and enabled the BEAST attack. That’s a documented protocol weakness, allegedly put in there by US state actors on purpose.

This is errant nonsense. At the time SSL/TLS were designed, using CBC with block ciphers was generally considered best practice - it was not at all an unusual choice.


Using CBC is fine. TLS and (prior to that) IPSEC set the CBC IV of messages to the last ciphertext block of the previous message --- pretending as if they were encrypting one long stream, rather than discrete messages. That's never been OK, and cryptographers warned about it at the time.


Arrant nonsense, surely?


Don't know what's so sure about it, either is perfectly valid.


There are plenty of weak curves. See djb's safecurves project. Maybe the NSA found an unknown type of weakness.


There are now multiple cryptographers on this thread (not counting me; I'm not a cryptographer) explaining why this is now utterly implausible.


Unfortunately one of these cryptographers' responses are in a thread that was collapsed for wrongthink.


The word "wrongthink", always a hallmark of the arguments most worth paying attention to!


A self-promoting non-cryptographer who only relies on his message board fan club is not worth paying attention to!


Oof. Devastating.


Where do you get the 2^30 from? drand48 could be f_0, but they could have tried f_1, f_2, ... as well and chosen the f_n that yielded the desired but plausible values.

All we know is that drand48 gave values that the NSA was happy with.


Sort of.

I like to insist that the PLC Directory collects and distributes updates to highlight how it's different from a database. The latest state of the account is signed by the key that created it, or by a key that succeeded it. The directory can't inject any values, it's just a low-complexity solution for data availability: the "how do I learn about updates" part.

It could decide to hide/reject updates, but then it could just as well be forked and replaced if it did that. If downstream applications decide to get their account updates somewhere else, that's the directory now, without any loss of continuity for the accounts.

You don't get that from a simple database.

One could argue domain registrations, and so did:web, are more of a database controlled by a (large, international) organization than PLC. Plenty of tradeoffs of course.


one of the other feature of PLC compared to did:web is that it presents the identity history, but this is also problematic for some people (dead naming and right to be forgotten)

I believe there is work around did web for an extension that would enable verifiable history


IMO perfect is the enemy of good here. If your personal email account you use for literally everything is firstname.lastname@mailprovider then you're already in the same situation. This isn't any worse, but it is strictly better.

You can always create a new identity, I don't think anything has changed there. If you don't want your new identity connected to your old identity, then don't.

The right to be forgotten is whole separate problem. The only hope here, really, is that entropy takes care of it for you. I don't see how a chain of trust system can fundamentally be compatible with the right to be forgotten unless you relax the rules a bit.


Data flow: all the internet's creators ----> Jack Dorsey ----> all the internet's consumers

We're all watching the first step of enshittification and thinking "this is fine"


Oooof, thank you for catching this. This is what I get for writing spec and API before the implementation (which, to be fair, is usually the right order not to lose sight of the broader picture).

Sorry for the confusion, it's indeed the §6.1 binary format. I corrected the spec and post not to claim it's CBOR.


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: