This kind of thing always brings me down a bit. It's not rational, but it does.
I mean I truly admire these folks skills, the math involved is obviously remarkable.
But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.
It's not security only, nothing seems to work in the long term.
Imagine an engineer receiving a call at midnight about his bridge because gravity changed during daylight saving in a leap year. That's our field.
There's an MC Frontalot song called "Secrets from the Future" and the refrain is "You can't hide secrets from the future." It's something of a useful mantra to remind oneself that if "the future" is a part of your threat model, yes your encryption likely isn't enough because on a long enough timescale it is likely "the future" will crack it.
As with any other security issue, the question is "what is your threat model?" You can still justify encrypting your backup today if your threat model includes today's actors, however much you worry about "the future".
> 10 years from now, it might be as good as plain text.
Or 10 years from now it might be the next Linear A tablets to confuse cryptoarcheologists, unreadable and untranslatable and entirely foreign. If "the future" is in your threat model, don't forget the other fun forms of entropy beyond encryption being cracked such as encodings changing, file formats falling out of service/compatibility, "common knowledge" about slang or memes lost to the ages leaving things indecipherable, and so on and so forth. Most of those things are probably unlikely on only a 10 year time horizon, but you never can tell with "the future".
"You can’t hide secrets from the future with math.
You can try, but I bet that in the future they laugh
at the half-assed schemes and algorithms amassed
to enforce cryptographs in the past."
Didn't expect to see Front on HN today, what a pleasant surprise.
The point about archeologists is a good one because it speaks to motive. In general, we should be very supportive of the efforts of distant historians who want to understand what humanity used to be like. We should not WANT to hide secrets from a sufficiently far future. I can't think of any secret that deserves to be hidden from them for any reason besides perhaps modesty.
Relatedly, that is a part of why I love the term "cryptoarcheology" in general, as a reminder that digital spaces will need archeologists too.
There's it's somewhat shortened form "cryptarch", generally more used as a title ("cryptoarcheologist"), which was used in places in the Quantum Thief trilogy of books and is most probably already burned into your brain if you have played any of the Destiny series of videogames (and I presume was heavily influenced by Quantum Thief).
Hmm, I thought cryptarch was just crypt + arch with the arch part meaning “leader” (i.e. this sense https://www.etymonline.com/word/arch-), not archaeologist. Is there something about this in the Quantum Thief trilogy I’ve forgotten?
It's been a bit since I read it, but I recall the meaning overlap/double meaning between leader -arch (such as plutarch) and arch- from archaeo- was directly intentional word play in the book trilogy, and yes that leader -arch meaning does add spice to the neologism.
(I don't think Destiny does much with the playful dual meaning, though. Certainly the cryptarchs in Destiny have never yet been meaningful leaders.)
Well I would assume that as long as you live you'll keep updating your crypto as new tech comes out. That way the clock only starts ticking when you die.
> Or 10 years from now it might be the next Linear A tablets
At some point in the future, after the universe has expanded to the extent that other galaxies are moving away from ours faster than the speed of light, someone might read our astronomy papers and wonder whether they can believe something that cannot be verified.
This biblical prophecy from Luke 12,3 is solo true: " What you have said in the dark will be heard in the daylight, and what you have whispered in the ear in the inner rooms will be proclaimed from the roofs."
It’s basically “don’t try to get fresh with God”. Which conveniently translates into a call to humility and honesty towards its earthly representatives.
> other fun forms of entropy beyond encryption being cracked such as encodings changing, file formats falling out of service/compatibility, "common knowledge" about slang or memes lost to the ages leaving things indecipherable
I wonder what the digital archaeologists of the future will make of today's programming languages.
(I was going to point out how far we've come since the languages of yesteryear, but we still have such horror-shows as Perl and Bash.)
Bridge engineers don't have to fear the progress of science working against them, but computer security is not alone here. Consider designing body armor or military aircraft and hoping that the state of the art will stay the same! An adversary who can use the progress of science against you is always dangerous. Computer security has been rather lucky so far: the asymmetry between hashing and cracking a hash, for example, is much more favorable to the defense than the balance between bulletproof vests and bullets.
On a long enough time scale Bridge Engineers still have to worry about decay, entropy, collisions. Some of that can even be attributed to the "progress of science", as bridges have collapsed because earlier assumptions were invalidated by larger trucks, for instance.
An issue so far for computer security is less that decay and entropy happen, but that they happen so fast that the timescales are decades or even years rather than lifetimes.
This is a great point in general: sometimes the problem isn't an adversary using knowledge in your field against you, it's the unintended consequences of progress / changes in adjacent fields.
It also underscores that, when dealing with things like passwords, it's helpful to be able to seamlessly upgrade to more robust methods down the line, e.g. "if this password hash was generated using the old method, check the login using that method but rehash and update the database using the new method after authentication."
> Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.
When has that happened? Public key cryptography and symmetric key cryptography are still doing fine as far as I'm aware, and the latter doesn't even seem to be vulnerable to quantum computing.
Moreover, SHA-1 has been considered insecure for, what, at least 10 years? The fact that a cryptographic hash function has been widely considered insecure and widely recommended for deprecation a decade before a proof of concept even emerges is, to me, something to feel very good about.
"Public/symmetric key cryptography" is just the name of the practice, of course it's doing fine. What's not doing fine is picking a particular set of ciphers/hash functions/signature scheme and expecting to not fail in 40 years.
Incorrect, particular sets of ciphers are themselves doing just fine. There is no hint of well studied symmetric-key algorithms (like AES, which is in fact now over 20 years old) with long known sufficient key lengths "failing" (in terms of cold ciphertext being cracked) in 40 years, or 400 years for that matter. Even with a fully scalable general quantum computer, the best known improvement is Grover's Algorithm, which results in roughly a quadratic improvement (so a 128-bit key cracked in 2^64 iterations, 256-bit in 2^128, etc). This obviously is trivially defeated by doubling the key length, and AES-256 has been available from the beginning and has been becoming more standard for a while as well.
Now, there are various kinds of hot attacks, such as side channel leaks, that always present a serious challenge in many threat scenarios. And it's certainly possible to have bad implementations of a solid algorithm. But for AES implementations are very mature, and side channel attacks do not apply to data at rest. So in the context of "will my encrypted ciphertext with all my deepest secrets [sitting on a drive/in the cloud/wherever] be crackable in 40 years" no, symmetric-key crypto with 256-bit keys is dependable at this point.
A false sense of defeatism is itself plenty dangerous to security.
DES is a good example here: it was designed ~45 years ago and it's still theoretically surprisingly strong when you compare it with other areas of cryptography. By that, I mean it's held up very well to cryptanalysis that attempts to find faster-than-brute-force techniques, with the best attack taking 2^43 time (vs. the 2^56 brute-force time).
To be clear, 2^56 is trivially brute-force-able today, but that can be mitigated with constructs like 3DES, which are still (barely) secure despite being based on a 45-year-old cipher.
(So no one mistakes my intent, there are many reasons to prefer AES over DES. I just wanted to provide it as an example, especially since it happened to line up with the 40-year timeframe.)
Having to rent thousands of dollars in GPU-hours or using specialized hardware doesn't sound "trivial" to me. Practical, yes. Accessible even to a layman with money to spare, yes. Trivial? Hell no.
It's funny to see how different the various people here have on the definition of "trivial". 10 years ago, I generated MD5 collisions in a few minutes with a tiny little executable I downloaded. That's what I call trivial.
If I had some DES-encrypted files that I'd lost the key to, and they were important enough that I needed their contents, I would probably be happy that I could crack the key today and recover them if I spent enough, but doing so would still not be "trivial".
Oh, sure, maybe trivial isn't the best word for it, but it's all relative (to me). $20k is remarkably cheap for a practical cryptographic attack compared to the rest of the field, and there's plenty of software to do it, and it's been done before (many times).
Apparently there's even a SaaS offering to do it for you in some cases (for staggeringly cheap, like $300), but I had no idea that existed when I wrote my comment.
Encrypting is still better than not encrypting and if you care about keeping your data private then you can take additional measures to ensure that. Nothing will last forever but that's not a good reason to be nihilistic.
It's like locking my front door. I chose to lock the door to prevent random acts of burglary. But that lock will not stop someone determined from BnE my house.
I think GP was taking about the general nature of “previously assumed to be unbreakable” methods being broken. Not sure if he has implying using a checksum also for encryption
What do you mean by "previously assumed to be unbreakable" ? SHA-1 has been known to be unsafe for a dozen years, we just went from "assumed to be breakable" to "yep, definitely breakable, here's how one exact attack will work".
I can see why backups might be needed for a dozen years, and I can see why encrypted backups might be needed, but outside plainly fake requirements like those of "national security" why would encrypted backups be needed for a dozen years? Aren't we throwing everything sensitive away after seven years? After that isn't it mostly about preserving history? Even things like balance sheets that might be sensitive today will be too out-of-date to be sensitive a dozen years from now.
The obvious counter-example is my library, however old my photos or music or videos are I'd like to keep them for as long as possible, and because they're private I'd like to keep them in an encrypted form
If you use SHA-256 to encrypt your backup, then I just need to steal your backup and wait 20 years, until that is cracked, and then I can decrypt your backup, even though today you’re using the “correct” encryption.
To be excessively pedantic you can encrypt securely (but slowly for the SHA series) with a hash function of sufficient capacity by running the hash function in CTR mode. You turn it into a stream cipher. Ideally you also MAC the ciphertext, nonce, and other associated data. That's is pretty easy with such a hash function (either use HMAC or a MAC mode of the hash function if supported).
Salsa20 & ChaCha20 cores are hash functions (though not collision-resistant compression functions since it's not needed for their design goal and would be slower) run in CTR mode.[1]
Can you explain the relevance? If I put N items randomly into >> N buckets the chance of there being a second item in a particular bucket is small (as opposed to there merely being a bucket with two items, as in the birthday "paradox").
From my numerical experiments (I hope I didn't mess up...) using the random oracle model, the probability that a given key is collision-free is 99.6% if the input is one byte shorter than hash, 1/e if input is same size as hash and 6.6e-112 if the input is one byte longer than hash.
And this holds basically irrespective of key size.
If you're planning to brute-force count through 2^(128x8) possible bit inputs, it will be quite a few decades indeed. And you'll need a few spare solar systems to annihilate to get enough energy to drive your counting engine through that many states.
Hashing is a separate problem from encryption. There is no proof that one way functions (the idea behind hashing) even exist (by proving this, you would actually prove P!=NP, IIRC).
Encryption has a slightly better track record of being broken. AES still holds its promise and is also secure against quantum computing (you might want longer keys, but that's it).
And if you want really, provably unbreakable encryption, there is still OTP. But then you'd need a key, that is as long as the data you want to encrypt.
The best known attack against AES reduces attack complexity by about two bits over brute force. Given the history of block ciphers, the idea that AES might not be broken in this life time is not uncommon.
> Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.
That is an absurd statement. Every backup you encrypted 10 years ago with then up-to-date security is still well encrypted.
The SHA1-thing came coming over a timespan of 15 years. It still doesn't threaten past usage, only active attacks are really relevant.
FWIW, a lot of very smart people seem to think that we actually do have symmetric encryption in a state where it "works" and is "understood" and that AES is unlikely to be "broken". What we don't really feel so great about is asymmetric encryption, but at least that feels like something P != NP might imply can be done... hashing algorithms just have this problem where if you glance at the information theory you would have guessed they couldn't be possible until someone shows you one that seems to work.
> something P != NP might imply can be done... hashing algorithms just have this problem where if you glance at the information theory you would have guessed they couldn't be possible until someone shows you one that seems to work
I'm confused what you mean by this? Why does the info theory suggest hashing wouldn't be possible? Also, you can easily derive a secure hash function from a secure symmetric cipher and vice-versa, so why would one seem to be possible but not the other?
1) The premise of a hash function is that you are going to take a large set of inputs and map it to a small set of outputs such that you don't find collisions, with the use case that the result is somehow so unique that the input file can be henceforth named by its hash and looked up in some giant dictionary of everything we have so far ever bothered to hash.
The hash is this tiny bit of information, and somehow is expected to be sufficient to uniquely describe some arbitrarily large amount of information? That just flies in the face of the naive expectation. The only argument that it is even sort of reasonable to expect would be the idea that while there are an insane number of files very similar but not quite your file, very few of them are "interesting" to a human in any way, and so the set of "interesting" files might be super small... but it isn't like we designed the hash functions to know that.
The reality that it seemingly can be done well enough that no one notices most of the time is fascinating and surprising--the kind of thing that inspires awe and wonder at the universe if true or calls into question our hubris if it isn't--not something obvious in the way the existence of symmetric ciphers nor something reasonable to expect in the way asymmetric ciphers are: to the extent to which reality lets us pull this one off we should be thankful.
2) If one can truly "easily" derive a "secure" hash function from a secure symmetric cipher, then why don't we ever have secure hash functions, despite seemingly having secure symmetric ciphers? If this is so easy, I suggest you do it and then wait 30 years and see if someone figures out how to break it (and we can see it AES is still holding strong).
>The hash is this tiny bit of information, and somehow is expected to be sufficient to uniquely describe some arbitrarily large amount of information
It doesn't really describe the information it just indexes each piece. For that it is a very large key space. A 128 bit key could index 10^38 objects. That's a lot of slots. Provided your hash has sufficient mixing you will need a lot of shots to hit anything.
>If one can truly "easily" derive a "secure" hash function
Semantic security has a precise definition. We just have to make empirical assumptions about whether an input cipher is semantically secure. The hash is only secure if the cipher was but the derivation is easy.
1) Oh I see what you mean now. Yeah I guess it depends on your intuition.
2) I mean, I'm not sure how correct your premise that symmetric ciphers are more secure than hash functions is, but it literally is something that is done. You can read more about it in [1], including the possible pitfalls. The transformation should provide more than enough intuition to see why both are equally plausible, which was the point of my reply. Whether or not it's best to actually implement them that way in practice is a separate question which I'm not trying to answer here.
So, the intuition defying part happens in the transformation you're talking about.
The block cipher behaves how we expect, I'm confident that many of the ciphers used inside real hashes like SHA-256 are good block ciphers and either would not be broken if we used them as block ciphers or could be repaired by competent cryptographers to be robust enough so that they didn't get broken over their lifetime after the repairs were done.
But the transformation to get a hash introduces the effect that your parent sees (I think correctly) as unintuitive. Normally if I put a megabyte of plaintext into a cipher I get back a megabytes (or slightly more depending on my mode of operation and rounding up due to block size) of ciphertext, but this transformation ensures we always get one block back, the hash of a Wikipedia dump and of my address book are the same length for a particular hash function. The "block" is bigger than we're used to from popular block ciphers but that's what it is, one block.
And that's where the concern appears. Why is that safe? Surely that shouldn't be safe at all? And yet, it seems, it is successful, more or less, until it isn't.
All of this stuff is so new so we'd expect to see churn. Many people involved in the discovery that asymmetric crypto was even possible (Diffie, Hellman, Rivest, etc) are still alive. If the people that first invented bridges were still alive we'd be running into all kinds of failures in bridge building techniques. Bridges have been built in the last 100 years that the wind blew down!
At least in our case problem can be solved by re-encryption. Yes, we have to keep up to date with developments before everything is completely broken, but it is not bad as discovering a bridge needs to be rebuilt. Speaking of which, it is common to have to retrofit for earthquakes which probably wasn’t the rule when they built the original bridge
That depends on your threat model. A patient attacker can store all of your encrypted messages till some future point where decryption is economically feasible. Since they already have the weakly encrypted data, encrypting it again doesn't solve anything.
No, the bridge collapsed because it was never touched again after initial deployment, for 10 years. How are buildings doing in Chernobyl? Don’t neglect your data, if you want to keep it safe always. :P
Dude, Chernobyl reactor by design was nuclear bomb.
P.S. My father (still alive) was one of thousands of common liquidators of Chernobyl disaster from May to July 1986. Many of his coworkers, that lived with him in same tent, already dead.
Chernobyl was not quite a "nuclear bomb" in the sense that Pripyat isn't a charred crater. Nuclear reactors, when they fail, just spread their radiation all over.
Concrete is pretty resilient and even if it cracks it can still hold up quite well but when it does, the rebar gets exposed and starts to oxidize until the building finally crumbles.
This can really apply to almost everything though, since if I understand you, it seems to be about progress in the face impermanence. The history of science is basically a constant process of things kind of working, then breaking. But overall it goes forward and things are better off for it. In contrast, I find it kind of inspiring.
DES is still basically as good as its insufficient key length. AES is 20 years old and holding strong. MD5 is still not fully broken (still nowhere near a practical preimage attack).
> 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.
> Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.
Realistically, any archive is going to have to re-record data to stay ahead of age and equipment becoming obsolete. I've heard the lifetime for the physical media of tape backups is in the 10-30 year range.
Updating the encryption isn't a big deal once you're already rewriting everything.
The thing to remember about cryptography is that as long as it's based around computational power, it can always be broken at some point. Especially if we're building exponentially more powerful computers every N years.
Assuming the universe is infinite in some sense. Otherwise the exponential growth has to stop at some point. So base your cryptography around computational power beyond physical limits and you are safe.
Even if you could make it secure for all you life time, this is always at play: https://xkcd.com/538/ - In general probably nobody give a dime about our backups but if they did they will find a way to get the data before it encrypted or when we are decrypting the backup.
> We have tried to contact the authors of affected software before announcing this attack, but due to limited resources, we could not notify everyone.
Many in the 'security industrial complex' make as if they are doing god's work by their 'research' but from a common sense, man/woman on the street, and layman point of view that is not what appears to be going on at all.
What they do is self serving and a detriment. Then they try to justify it in some way as being good when it's not good. It's like going around and compiling a list of doors in a neighborhood that are open, attempting to contact everyone but not getting some people and then saying 'hey look at what we did for you'. Meanwhile if a list were not compiled at all almost all people would do just fine.
> But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.
Figure out the amount of issues there would be if there was not such open disclosure and an entire industry surrounding breaking things vs. same not being done. That is the issue.
> Imagine an engineer receiving a call at midnight about his bridge because gravity changed during daylight saving in a leap year. That's our field.
No because nobody is able to or actively trying to change gravity (or is able to).
The idea behind your complaint is "if we tell good people about risks, then bad people will know about them. If we keep them secret from good people, then bad people won't find out about them". Or, "if we don't make a list of open doors, then bad people can't find which doors are open". Which is .. not true. Bad people will already be making their own list of open doors, and sneaking through them without being noticed, over and over again.
> all almost all people would do just fine
Here's an ongoing ransom attack in the UK, started on New Year's Eve: https://www.bbc.com/news/business-51017852 The ransom is in the millions of dollars range, Travelex websites in 30 countries down for a week, Sainsbury's money exchange websites down for the same time, and "Dates of birth, credit card information and social security numbers [of customers] are all in their possession, they say."
Not looking at problems doesn't stop problems from existing.
> "if we tell good people about risks, then bad people will know about them. If we keep them secret from good people, then bad people won't find out about them". Or, "if we don't make a list of open doors, then bad people can't find which doors are open".
You are not recognizing the nuance which is typically the case with people who supports practically any and all disclosure and thinks it's good plain and simple. With almost no downside at all (not the case).
In particular this: "then bad people won't find out about them"
My point is that disclosure makes it simpler for more bad people to find and learn and inflict damage damage. Unclear to me how you could think that isn't what has and is happening. If someone say publishing how to create a card skimmer at a gas station then more people (who are bad actors) will then have what they need to give it a try. If not there will be people who have figured it out and people who will put the effort into figuring it out but you must realize vastly less will do that, right? The disclosure removes a great deal of friction.
The amount of effort and friction and the amount of 'bad people' that can be actors is many magnitudes larger (I would argue) as a result of disclosure.
What I think you're missing is that the disclosure could come from a bad person who doesn't care about any of your arguments. It's like I'm saying "banks should invest in vaults to protect against theft" and you're saying "that costs money and disruption of building work, what if you just don't talk about where the money is kept". I agree that if people didn't steal the money, that would be nice. But most of the people who are talking about where banks keep money with a view to stealing it, aren't going to shut up in order to keep the money safe, because they don't care about keeping the money safe. So if us bank customers stop talking about it, a) that doesn't keep it quiet, and b) our money gets stolen.
It would be a nice world if we could tell companies about flaws and they fixed them, and nothing went public, but instead we tell companies with "responsible disclosure" and they ignore it, don't spend any effort on it, act incompetently leaving it with first line support people who don't understand it and have no path to escalate it, have no security contacts available for reports, cover it up or deny it or try to silence it with NDA style agreements, prioritise shareholder profit or public image over it, and generally behave irresponsibly in all possible ways that avoid them having to deal with it, with very few companies excepted.
In light of that, public disclosure with all its risks, actually does kick companies into taking action, and closing risk vectors for good. Like companies who say "we put customers first!" but it takes a complaining public Twitter thread for them to even respond at all. Telling people to not take it to Twitter ignores the fact that there's no other way which seems to actually work.
Give an alternative which also gets problems fixed, and I'll be much more in favour of it.
"Which is .. not true. Bad people will already be making their own list of open doors, and sneaking through them without being noticed, over and over again."
But the vast majority of people do literally have front doors which cannot guard them from 1% of the possible attacks in the world, if they were targeted. Never mind the best ones in the world.
The internet brings a much bigger attack surface than local people who can reach a front door, and home users access the same openssh as companies do, but companies (can) afford stronger doors. "Most people's home doors can't withstand a hit from a sledgehammer" -> "we shouldn't talk about cryptographic weaknesses in case someone abuses them" is a stretch, the comparison does break down.
[1] is a fun YouTube video about physical pen testing; one example at 13:45 in the video, the presenter is walking home from a bar, walks up to a locked high street bank, spits a mouthful of beer through the gap in the doors, triggers the presence sensor on the inside which lets people out, and the door opens and lets him in.
"The internet brings a much bigger attack surface than local people who can reach a front door"
"Local people", huh. My front door is visible to everyone on the internet, and I have no practical way to prevent that. Some obscure company went by with their mapping vehicle and...
Now, some people do live in big buildings where less is exposed to the outside, but millions don't.
and... what? Unless telekinesis has been invented, a photo of your door doesn't increase the amount of people who are able to try opening your door. If you're about to say "someone might choose to come a long way just for my door" then that seems like an argument in favour of what I'm saying - in that case, wouldn't you like to know about any vulnerabilities your door has which you could address, before they arrived, instead of relying on silence and hoping they won't know about them?
I'm not really arguing in favor of doing anything in particular; I was just pointing out that people rely on "security by obscurity" in day to day life, despite the fact that everything is connected to the internet. Perhaps there are some subtleties in exactly what "obscurity" is.
I'm saying the ideas I read about how the world is don't seem to be connected to my view of reality. I don't have to argue with your conclusions to find fault with your premises, and I'm feeling too lazy to do it right now.
The percentage of people that are impacted by NSA et al is exceedingly small compared to the pain and impact on everyday citizens and companies by disclosures. Not all disclosures and for sure an upside but it's out of control and has been for a long time.
The government (in the US) does not have the resources to go after everyone who commits a crime and that would assume they are actually scooping up info and know of the crimes (they aren't and they don't). They don't even have the resources to audit tax returns (other than a very small percentage). This idea that you are being watched all the time is fantasy. In the US. Other countries? Unfortunate when that's the case but that does not mean as a US citizen I can't view it as detrimental to me that this type of security disclosure makes it so easy for hackers to do a better job (and it does nobody is going to dispute that fact, right?).
The government (in the US) does not have the resources to go after everyone...
In point of fact, since Snowden's revelations we know not only that the USA state actually does have the resources to monitor everyone, but also that it does so. Furthermore, the state is not a monolith. While it may not be in the interest of the state as a whole to capriciously victimize individual humans, it is often in the interest of particular officers and organizations that comprise the state to do so. Cf. "parallel construction".
I mean I truly admire these folks skills, the math involved is obviously remarkable.
But I think the feeling is related to not being able to rely on anything in our field. Hard to justify going to the trouble of encrypting your backup. 10 years from now, it might be as good as plain text.
It's not security only, nothing seems to work in the long term. Imagine an engineer receiving a call at midnight about his bridge because gravity changed during daylight saving in a leap year. That's our field.