A one-time pad generated correctly and used correctly will remain highly secure, provided you have a highly secure means of sharing the key material. There's a lot rolled into those assumptions.
That type of security comes at a cost.
I don't think it's that hard to get true randomness. Just measure something random in nature like radio static.
I've heard other approaches including that static too, ie the famous analog TV without real signal, IIRC its cosmic microwave background, or camera watching water drops fall or similar. There are many other ideas (and probably products too), the only thing is one needs to keep it 100% reliable across long time.
I would think that for crypto it’s very important to not just have random numbers, but to have a uniform random distribution. Many natural sources would be either Poisson or Gaussian; if you make an assumption for the distribution you could of course make it uniform, but that assumption would be a weakness if inaccurate or changing over time.
So how is a true random source usually used to ensure uniform random outputs?
You can take a collection of those values and convert them to an index in the set of all possible permutations of those values. That index will be uniformly distributed in the range of the number of permutations, regardless of the input distribution so long as it's IID.
Once you have a uniform value on a range you can extract uniform bits from it.
See also: Von Neumann's debiasing algorithm.
In practice RNGs use some kind of debiaser, though often they use ones that leave a lot of entropy on the floor. OTOH, stronger debiasers are more harmed by failures to be completely IID (e.g. some inter-output correlation, or the distribution changing over time with temperature).
Which does kind of further your point that one time pad makes more secure the parts that are already incredibly secure, while not helping the real weaknesses of cryptosystems i.e. the human element.
Yes. No one seems to have mentioned VENONA.[1]
Instead of trying to suggest "security by obscurity is fine, actually, and don't worry about it", it's time for us to just stop being pithy and start being precise: your cryptosystem should be secure even if your adversaries understand everything about it. If that is true, then you can (and, in the real world, almost certainly should) add defense in depth by adding layers of obscurity, but not before.
The reason is that, without any exception, every time when some system that used “security by obscurity” has been reverse engineered, regardless if it was used for police communications, mobile phone communications, supposedly secure CPUs etc. it was discovered that those systems have been designed by incompetent amateurs or perhaps by competent but malevolent professionals, so that those systems could be easily broken by those who knew how they worked.
“Security by obscurity” is fine for secret organizations, but for any commercial devices that incorporate functions that must be secure it is stupid for a buyer to accept any kind of “security by obscurity”, because that is pretty much guaranteed to be a scam, regardless how big and important the seller company is.
Obscurity is OK only when it is added by the owner of the devices, over a system that is well known and which has been analyzed publicly.
That is the point. It is a good rule of thumb for people who don't know much about security. Anything they create trying to add more security to their system is more likely to do the opposite.
If you think you know better, feel free to ignore it. Just be aware you wouldn't be the first who thought they knew what they were doing or even the first who did know, yet still messed up.
This history repeated later, with people making shoddy cryptography where they didn't want anyone to know how it worked, and similar things, most of which got broken in embarrassing ways. This sort of obscurity was actively harmful and let people sell defective products that people relied upon to their detriment.
Meanwhile, there are good types of obscurity, too. For example, there are the information disclosure CWEs that tell users of products not to disclose version numbers, stack traces, etc. to users, and this sort of "obscurity" is perfectly reasonable and widely accepted.
So it's not the case that all things that might be termed "obscurity" are bad.
Things are more secure if you share your file with a specific set of users, but that requires your counterpart to have an account with the system you’re using (eg a Google Account for Google Drive). When sharing files with an arbitrary counterparty, it’s often sufficient to generate a publicly available, unlisted/unindexed, hard to guess URL. Even better if it’s time boxed.
I’m sure there are attackers who attempt to identify and enumerate these URLs. If they’re well designed though, it should be infeasible to guess the link.
Unless a service is leaking or spidering the URL into a public index.
https://positive.security/blog/urlscan-data-leaks
https://arstechnica.com/information-technology/2014/05/dropb...
https://security.stackexchange.com/questions/239762/how-are-...
It is much harder than it would seem to keep these links secret. If one of your assets gets caught by other means, they could endanger the entire network if they use the same methodology.
The CIA thought they had a super great system, and then many of their assets got rolled up at once in a hugely embarrassing (and deadly) blunder.
im not sure i understand what this means, can you provide an example and why its controversial?
do you mean a one time pad using memes via image steganography on heavy traffic forums? I recall this is what North Korean spies used to do in early 2000s
There is a longstanding tradition of vendors of mediocre 'security' systems using trade secrets/restrictive license terms/anti-hacking laws to cover up their mediocrity.
If you're shopping for a garage door opener and one vendor publicly documents their security system and well known experts have given it their thumbs up, while another vendor says their system is secret and has sued people for attempting to reverse engineer it? Knowledgeable folk would have far more trust in the former than the latter.