> "Don't talk about the future," Vidyasagar says.
> "What? Why not?"
> "Look at this computer," Vidyasagar says, gesturing at the mainframe. "Computers are getting more powerful, yes?"
> "Sure."
> "What is the most powerful computer that will be built? Ever. Not this year. Not this decade. What computer will be the most powerful? And how powerful will it be? And how big?"
> Hatt thinks on this for ten long seconds. He opens his mouth, but never actually forms a word. The scale of the question is beyond him.
> Vidyasagar says to him, "No matter what you say, you will look like a fool. Every statement about the future turns out to be foolish."
> No matter what you say, you will look like a fool
That's because the question is nonsense, not because it's about the future. If the question is "What is the most powerful computer that will be built this decade?" it's answerable. No answer will be correct but there are certainly ways to answer that aren't foolish at all.
Given a finite amount of attacker computation you're willing to defend against, you can get a real advantage from key stretching (though not from mere salting). If you want a password strength of 256 bits, you can memorize a password of 226 bits and require work equivalent to 2³⁰ key-hashing operations to derive the actual encryption key or crypted password. This is normally called a KDF; reasonable ones are scrypt, bcrypt, and Argon2, in ascending order of goodness.
If you make the work factor unreasonably large, you won't be able to use the password in practice, because you have to do that work every time you use it. For example, if you try to memorize 170 bits of password and use a 2¹⁷⁰ work factor in your KDF to reach the 340-bit security level, recommended here, you have to do 2¹⁷⁰ work on your laptop every time you log in. Assuming a trillion operations per second (a safe upper bound for current laptops) each login will take about 47 nonillion years, about a sextillion times longer than the history of the universe so far and about 50 times longer than the expected lifetime of the last galaxies (see https://en.m.wikipedia.org/wiki/Timeline_of_the_far_future). It may be inconvenient to wait that long.
For the same reason that a KDF is a safe way to derive keys for decrypting data at rest, in a client-server system, you can generally do this work on the client safely, so it doesn't pose a denial-of-service risk.
This is exactly the question I was asking me when starting the article, and it is answered perfectly.
However, despite things like Ed25519 using 512-bit curve points for 256-bit security (you lose a factor 2 off your exponent because math), this particular instantiation fails much harder if a quantum computer running Shor's algorithm ever becomes reality.
Meanwhile, 123456 still tops the password charts wherever it is allowed.
https://en.wikipedia.org/wiki/Industrial_espionage#/media/Fi...
First it uses the current average temperature of the universe. Lowering the temperature can be done by just waiting a while before turning the machine on. I assume that powering a sufficiently powerful fridge is not an option, given the origin of the theoretical limit, but I can't quite point out why it wouldn't work.
Secondly it assumes that an unsuccessful attempt must flip at least some bits in an semi-permanent manner. This is obviously true of all current computers, but doesn't have to be true for all possible apparatuses. A specialized hyper-efficient password cracking system should be expected to get below this limit. Will we ever build one? Who knows.
Arguably this latter 'loop-hole' is just pointing out that quantum computers or more efficient algorithms could do better, so maybe we should absorb it into the definition of 'brute-force'.
5 picoseconds to respond, then you are disconnected from the system by the laws of physics.
No amount of frame-jacking via time dilation using black holes can cheat that captcha, or brute force that keyspace.
By the time you find the key, we are no longer connected in space-time/causality
> "I'd just like to interject for a moment. What you’re referring to as Linux, is in fact, GNU/Linux,"
If someone were to prove one of these assumptions is true, then I suppose the answer to your question is yes, but I wouldn't hold my breath waiting for such a proof :)
What does “understanding” means when talking about an inanimate thing?
> It seems weird that there can be a set of information in the universe that can be hidden from the rest of the universe.
Why should the rest of the universe “know” anything about other parts of the universe?
Ascribing “understanding” and “knowledge” to the universe sounds questionable from the start, it doesn't seem weird to me that the universe doesn't have these properties.
But there's an implicit assumption here that all keys are equally strong, so this doesn't apply to asymmetric encryption. At least not as straightforwardly. And it's possible that P is in fact equal to NP. And there's a bunch of other assumptions here too, like that we really do have a secure source of entropy and really can share keys securely.
Anyway, if we take all these assumptions as read, this suggests that symmetric key lengths will saturate at a certain point (and not much wider than they are today). Big if true.
So the data was impossible to exfiltrate remotely: it simply wasn't physically possible to do remotely (it would be way too slow).
I forgot the name and what the data was used to protect/derive: maybe some authentication scheme?
Anyone knows what I could be talking about? I'm pretty sure I saw that posted here on HN in the past.
It's a variant of salted passwords, where the "salt" is a huge file that sits on a server somewhere. To validate any given password, it only requires accessing a few bytes that are deterministically but randomly determined. This isn't a problem when validating passwords, but if you're an attacker trying to exfiltrate the file (so you can run offline bruteforce attacks on it), the huge file becomes prohibitively expensive to exfiltrate.
Bigger issue in the context of this article is that it ignores reversible computing, which would nullify the core part of the thesis.
What if it's E = mc^2 + AI?
Intuitively, there are a finite number of passwords that can be stored on earth, so a large enough system should be able to enumerate them? Whilst also existing in the observable universe.
The phrase "stored on Earth" is a red herring. You don't need to store all possible passwords for those passwords to be possible to generate here. And really, a consequence of the article is that if enumerating even a couple hundred bits is prohibitive, then enumerating all possible information that could be generated by and stored in an earth-size system, as you seem to be suggesting, is no better.
Yeah that’s correct.
> The phrase "stored on Earth" is a red herring. You don't need to store all possible passwords for those passwords to be possible to generate here.
A password used to protect a system must be persistently stored inside that system.
The number of passwords that can be generated on earth is greater than the number that can be persistently stored on earth.
For example, an iPhone must locally store a user’s unlock PIN code. However, it could theoretically generate a 20TB password for an external site in chunks without ever storing the full password locally.
Energy is a binding for password generation; but size is a constraint for password storage, which likely kicks in a lot earlier.
>An excerpt from a religious text with a trailing space:
>"I'd just like to interject for a moment. What you’re referring to as Linux, is in fact, GNU/Linux, "
Followed by the deadpan sage advice:
>Don’t use actual excerpts from pre-existing works as your password.
IOW don't try this yourself unless you make up your own religion. Established scriptures of all other kinds have been completely compromised long ago ;)
KDFs are good at protecting "okay but not great" passwords used to gain online access, but they add no protection to extremely secure, unique passwords, and they don't add enough protection to extremely weak, common, or reused passwords. They are there to frustrate attacks, not make them physically impossible. Many credentials are time-sensitive, and many attacks are not targeted; KDFs are good in these common situations. You still need to pick a password that will take long enough to crack that an attacker moves on instead.
However, some data needs to be protected practically forever, and some attacks are definitely targeted at specific people or systems. In these cases, KDFs don't do very much. Taking a 256-bit key just from the raw bits of 32 random ASCII letters and numbers will already get you 190 bits of entropy and frustrate all practical attacks for the next several decades at the very least. Feeding that through a KDF first won't add any practical security. Even so, KDFs can be used for a different reason, enabling passphrases, which are long strings with low per-character entropy but high overall entropy. At least, assuming that the KDF preserves that entropy well.
Regardless of bcrypt, you should always pick security keys with sufficient entropy, where "sufficient" is measured relative to the importance of the thing being protected, how long it remains important and accessible by that key, and what attacks are viable now and foreseeable in that time.
Does that help me build resistance to physical torture?
