Skip to content
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

Open
zamicol opened this issue Feb 6, 2025 · 1 comment
Open

Include note on BIP 32 in README #2

zamicol opened this issue Feb 6, 2025 · 1 comment
Labels
documentation Improvements or additions to documentation

Comments

@zamicol
Copy link
Contributor

zamicol commented Feb 6, 2025

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.

@zamicol zamicol added the documentation Improvements or additions to documentation label Feb 6, 2025
@zamicol
Copy link
Contributor Author

zamicol commented Feb 16, 2025

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:
The security of this tree structure depends solely on the security of the chosen digest algorithm

Branch values cannot be used to calculate:

  • Parent seed values
  • Sibling branch values
  • Any values in other parts of the tree

Knowledge of a seed allows calculation of all descendant branch values
Requires secure random seed input: the structure does not attempt to strengthen weak entropy input

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:

  1. The security of this tree structure depends solely on the security of the chosen digest algorithm
  2. Branch values cannot be used to calculate:
  • Parent seed values
  • Sibling branch values
  • Any values in other parts of the tree
  1. Knowledge of a seed allows calculation of all descendant branch values
  2. Requires secure random seed input - the structure does not attempt to strengthen weak entropy input

Limitations:

  1. Like all deterministic structures, reuse of a seed will generate the same tree
  2. Disclosure of a seed compromises all descendant branches
  3. Cannot be used to prove path relationships without disclosing seeds (one-way property)
  4. Branch size restrictions based on digest algorithm output size
  5. Though the tree can be infinite, practical implementations need defined branch level sizes (BLS)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

1 participant