- Some examples for review/discussion.
- Alternative: local password generated key for internal use in encryption-key access control API.
- Entropy and increasing it.
1. Some examples for review/discussion
In systems that take a user's pass-word/-phrase in order to derive the encryption key, what is the relationship between that password's strength and the key's strength?
This depends entirely on how you use the password to derive the key. If you're just hashing, or even hashing and salting your password, your function might look like this:
generateKey(password, salt) := cryptoHash(password, salt)
If I took a table of the weakest passwords I could probably calculate the potential hashes, and from there I would have the possible encryption keys. Then given a
message I could crack it with this function:
crack(message, saltLen, weakPassList):=
for salt in 0..saltLen:
for weak in weakPassList:
let k := generateKey(weak, salt)
if decrypt(message, k) looks okay:
This might take a really long time to run based on how big
weakPassList are; however you could cache the
k generated above in a table and just try them out one at a time, to eliminate the factor of experimental key generation.
There are definitely better ways to generate a password, but without a more detailed specification or use case it's difficult to analyze or recommend which method is best.
2. Alternative: local password generated key for internal use in encryption-key access control API.
I know password strength matters in authentication; is it a moot point in encryption?
I feel like there's no difference unless you are talking about a particular method of key generation or some other specific use case. A key is a key.
Personally I'd go with using the password to generate a local encryption key
kLocal, used to obscure a properly generated cryptographic key
kMessage that can be used to encrypt messages for sending over non-secure channels.
This way the password is just an access control mechanism to filter users who can type commands into the system, and prevent them from using each other's encryption keys (if they can't get the right
kLocal they can't discover the contents of
kMessage). This is apt because you can use a secure API with, for example, a leaky bucket, to prevent people from doing password guessing attacks on the local machine.
It's not as straightforward to prevent password-guessing attacks against a ciphertext message that's already been sent out in the open! By making the password-generated
kLocal for internal, API-restricted usage only, you bound the attacker's effective computation power, which is a really good thing in software security.
3. Entropy and increasing it.
From my understanding, human-created passwords tend to have very low entropy, and that's why keys are derived from them.
Be careful! Entropy is just the measure of how unpredictable something is. If I take some values with
X amount of entropy, and run them each through some adversary-known function, the results can have no more than
X entropy. That is, if the adversary could guess the original values and also knows the function for manipulating/extending them, he'll have just as easy of a time guessing the manipulated/extended values as he would the originals.
You're not increasing the size of the domain unless you add more information; and you're not increasing the entropy unless the information you add has some entropy itself (is somehow unpredictable/secret).