-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include note on BIP 32 in README #2
Comments
Random thoughts: So, it has one "fault", that it depends on secure input entropy, but I really think that's not only a reasonable assumption, but best practice. Since this first assumption should be true, salts should be utterly useless. It's as efficient as possible to address any single key. It's very fast. It has as minimal security assumptions as possible. Security wise: Branch values cannot be used to calculate:
Knowledge of a seed allows calculation of all descendant branch values Is Tree A Password Hashing Function?Tree is not a password hashing function. Unfortunately, the industry names password hashing functions like Argon2 "KDF"'s even though that's not their design objective. The industry should reject this confusing naming and use "password hashing functions" exclusively for functions like Argon2. Password hash functions are designed to be slow, are designed to be use with salts, and may have low entropy inputs. Being slow is a waste for (true) KDFs, salts aren't relevant (although nonces may be), and are designed for high entropy inputs. The naming overlap between the two is bad, so the industry has tried to move towards naming the two differently. Password hashing functions are not ideal KDFs, even though a particular primitive may be secure for use as a KDF. That's a root of some of the confusion. Hash functions themselves are general purpose and don't protect against low entropy inputs (low entropy passwords). They also don't protect against rainbow tables (pre-calculated digests for common or popular passwords). For password hashing you want something slow and something with unique entropy for each user's password to prevent rainbow attacks. These methods for password hash functions don't solve the problem of weak passwords, but it's the best that can be done with weak passwords. The only improvement is to enforce strong passwords. Password hash functions are intentionally designed to be extremely slow (at an exponential scale). While this makes perfect sense for password hashing, it is nonsensical to have such an intentional, configurable slowdown mechanism in KDFs. KDFs have computational cost, but having the kind of extreme slowdown that password hash functions have makes no sense for purpose designed KDFs, especially when needing to derive many keys. Security Assumptions:
Limitations:
|
BIP 32 is somewhat related prior work.
Also, "hierarchical deterministic key derivation function", although Key Derivation Function (KDF) is also true.
"Reverse Merkle Tree"
Also, I'm sold on "digest tree". It's elegant in its succinctness.
The text was updated successfully, but these errors were encountered: