Nothing is Fully Secure

You think encrypted objects can be fully secure? Not really. Normal encryption used to be secure; but when computing power increases, it grows not. Pseudo-random number generator (PRNG) generating those numbers are based on either a "seed" (some value you gave it), or based on non-deterministic value (which is actually based on the computer giving it a "seed" depending on various factors (perhaps time, date, or any other CPU states, whatever it can use to generate a seed).

Then, we have cryptographically-secure PRNG (CSPRNG), which mentioned to be secure cryptographically. These uses non-symmetrical encryption and decryption keys; unlike a symmetrical one (which have same key used for encryption and decryption). A symmetrical is easy to break; for a hacker that gains access to the key when it transfers from one location to the other, the hacker can break the actual data. With a different key for encryption and decryption, and longer keys (128-bit, 256-bit, 512-bit) allows much difficult breaking.

Yet, to say they're unbreakable is futile. For we assume that hackers don't have sufficient computing power to derive the private (decryption) key based on known public (encryption) key and the encrypted data, that doesn't mean hackers can't break it in the future. SDNL (Store-Now, Decrypt-Later) is the hacker's solution: we just store the encrypted data and public key now, and wait for a few years when computing power is strong enough (actually, when quantum computer's power is strong enough, which we now only have baby quantum computers not strong enough to break existing encryption yet) to break them, then they break. CSPRNG RSA encryption isn't that secure after all.

Then, quantum encryption. We know that quantum computer are random by nature, based on currently existing Physics (at least, when one got out of college, that's what one learnt, 2 years ago). Random number aren't "pseudo-random" anymore. Hackers can't use a "seed" state to re-generate the random number, for quantum computers don't need that. But we never know: in the future, there may be other methods to break encryption. It may not be existing methods but new methods, we never know. Furthermore, quantum computing's "random nature" cannot be disprove now; that doesn't mean it cannot be disprove in the future. Science is a research to disprove existing theories and facts; and we cannot say 100% certain that what we now know won't be replace with something shockingly different in the future. Who knows?

Of course, what one speaks about is encryption and "decrypt-able" decryption. There are other methods of encryption where you don't need the actual value, just a comparison of hash (like md5 or sha256): which one heard to be encrypt-able and not decrypt-able? One isn't sure, one didn't study that deep. Irregardless, consider that a few data are use to generate the hash, including a random number (they called nonce) and password. If only the password is not known (and the nonce is known, especially if nonce is generated via a PRNG), hackers might brute force the password and find that out with sufficient computing power (or maybe they have a more clever technique than brute force). Irregardless, it's also not completely secure.

Conclusion

We can have something that's sufficiently secure, but nothing is completely secure. Especially with one case, one wants to send something over through the blockchain, and there are libraries that don't cooperate with wasm and NEAR protocol's on-chain machines (especially with, say, "openssl" libraries in Rust won't work on normal wasm compilation). WE can't use a hash/digest because we're not comparing values: the contract don't know the actual value yet, hence it can't generate a digest to compare against. Contract is not a quantum computer, so quantum RNG (qRNG) isn't possible. Sending a qRNG over blockchain means exposing the value in a transaction receipt, so it's also not possible. Generating it from frontend requires backend also have the key, which needs to send over the blockchain, exposing it in transaction receipt, so not possible. We need to generate it from the frontend, for only a "view method" (that doesn't change the contract's state) retrieving the key won't be expose in a transaction receipt and non-discoverable. That means writing a (non-cryptographically secure) PRNG to deal with.

Ok, enough of the babble, nothing is totally safe if you need encryption. Perhaps the safest is not to send them out; just storing it in one's computer is the safest. That also, if you are targeted by hackers and they hack your computer, it's also not safe. So perhaps writing it down might be the safest. But also, if a thief come to your house and stole that paper containing your secret... it's also not safe. So maybe the safest is storing it inside your brain. That also, if someone drugged you (with alcohol or other substances) you might not know you said your secret stuffs and get known by others.

Nothing is fully secure.

Remember to Like and Subscribe!