Passwords or pass phrases are basically a human equivalent of keys used by algorithms on computers.
However, because of that passwords also carry a lot of burden that make them unsuitable as keys:
- they are generally much less random than they symmetric key counterparts, because humans are quite incapable as random number generators;
- they may be dynamically sized, which makes them unsuitable for many cryptographic algorithms;
- they often use a specific set of characters (al alphabet) of their own;
- they can be converted to bytes in many ways, if just because there are many character encodings;
- the chances of reuse are rather high, so the leaking one password may influence security of many systems.
crypto.stackexchange.com/a/77629
- User-chosen passwords are low entropy.
When people choose a password, they sometimes use really poor passwords (you can guess the password given 10 tries), and when forced to choose better passwords they usually only get up to about 20 bits of security.
The standard today is 128 bits, so you need to select 12 words at random from a list of 2048 words using dice. That is a strong password. Nobody does this manually.
A computer generated token of length 20 which uses upper case and lower case letters and digits would be a good password.
Thus, many systems don't let users choose passwords and instead have the computer generate a token and let the user copy it.
For example, AWS IAM secret access keys work this way.2.To authenticate a password the server needs to store a "recognizer" for the password.
It can be the password itself but that is obviously very bad (an attacker can steal your password from the server's storage, even if you don't use the password while the attacker has access).
To avoid this, for user-generated low-entropy passwords the server has to use a computationally expensive password storage system like argon2id.
For a computer generated high entropy token the server can store the hash or HMAC of the token, which is computationally cheap and fast and secure.
But, the server still needs your password/token during the login process to verify that you know the password/token.
During this time when you're performing login, the server knows your password and an attacker in control of the server can steal it.
With asymmetric cryptography, the "password" (your long term private key) doesn't leave your device.
The server sends a new challenge and you compute a solution to the challenge on your device using your private key and send the result and the server has a "recognizer" stored (the public key) that lets it determine whether you have computed something that could only have been computed with access to the private key (a private key that the server has never seen).
Someone seeing your challenge-response pairs cannot compute the response to the next challenge.
This means that an attacker in full control of the server doesn't get to steal your private key.
They might be able to fool you to sign / authorize bad things, but not steal your key, and when the attacker's access is revoked you don't need to roll your key.One of the problems people have when trying to learn about asymmetric cryptography, which you appear to have not even tried to do but I hope you will now try, is that people's intuition about asymmetric cryptography is that the thing it promises to do (and actually does) is impossible.
That a Diffie Hellman key exchange or a digital signature or a KEM are impossible, there must be some trick and there must be some way to just compute the private key from the public key or something.
But no, asymmetric cryptography really does what it says, and you can't simulate that with symmetric cryptography.
security.stackexchange.com/a/259340
Passwords are often created to be memorized by users and may contain non-random information such as dictionary words.
On the other hand, a key can help strengthen password protection by implementing a cryptographic algorithm which is difficult to guess or replace the password altogether.
A password is less safe than a cryptographic key due to its low entropy, randomness, and human-readable properties.
en.wikipedia.org/wiki/Key_(cryptography)#Key_vs_password
Passwords are typically very short, so they would not be cryptographically secure, as well as the fact that they are not 100% random.
crypto.stackexchange.com/questions/77614#comment172862_77614