bip85: require direct HMAC use when sufficient

[scgbckbone]

No description provided.

[murchandamus]

cc: @akarve

[akarve]

@scgbckbone Requiring derivation paths that consume <= 512 bits to use the raw HMAC output creates a few problems:

1. Inconsistent codepaths within the same application (harder to test and prove correct)
2. A "back and forth" correctness dance during application development where we realize things like "oh, powers of 2 do not require re-rolls for DICE". Or "my app consumes a variable number of bits (like RSA key generation), how do I partition this into cases under and above the 512 bit limit?" This will lead to unwarranted test vector complexity and more carve-outs for backward compatibility (as was proposed for DICE).

A more consistent and sustainable policy would be to require that any application that could, under any of its derivation paths, consume more than 512 bits of pseudorandomness MUST use the DRNG. All other apps MUST use the HMAC output. For instance PWD BASE85 was designed so that all of its paths obey the 512 bit ceiling. In exchange for the gain in consistency and clarity, it is true that we trade away hardware wallet reach for the time being. That is a fundamental limitation of the already finalized and accepted DRNG application. I would rather see us put energy into noting in the BIP the fact that apps that depend on the DRNG have little to no hw wallet support as of today. The RSA app is already in this category.

[BenWestgate]

cACK: All other apps MUST use the HMAC output.

This is worth adding to the BIP. I agree with akarve an application intended to support every HWW should try to use <= 512-bits to avoid the DRNG.

However for the BIP93 app we run into a conflict where BIP93 can't be implemented with only 512-bits so its unfortunately a DRNG app. Future codex32 profiles like extended private keys or passwords would need even more bits (for shares).

[scgbckbone]

@scgbckbone Requiring derivation paths that consume <= 512 bits to use the raw HMAC output creates a few problems:

1. Inconsistent codepaths within the same application (harder to test and prove correct)

2. A "back and forth" correctness dance during application development where we realize things like ["oh, powers of 2 do not require re-rolls for DICE"](https://github.com/bitcoin/bips/pull/1958#issuecomment-5655138809). Or "my app consumes a variable number of bits (like RSA key generation), how do I partition this into cases under and above the 512 bit limit?" This will lead to unwarranted test vector complexity and more carve-outs for backward compatibility (as was proposed for DICE).

A more consistent and sustainable policy would be to require that any application that could, under any of its derivation paths, consume more than 512 bits of pseudorandomness MUST use the DRNG. All other apps MUST use the HMAC output. For instance PWD BASE85 was designed so that all of its paths obey the 512 bit ceiling. In exchange for the gain in consistency and clarity, it is true that we trade away hardware wallet reach for the time being. That is a fundamental limitation of the already finalized and accepted DRNG application. I would rather see us put energy into noting in the BIP the fact that apps that depend on the DRNG have little to no hw wallet support as of today. The RSA app is already in this category.

both are non-reasons, sorry.

1. you fear to add if statement to the code
2. is any app with at least one user (besides your reference implementation) using this DICE app ?

I have no idea what your're trying to optimize for - but definitely not usability.

[scgbckbone]

cACK: All other apps MUST use the HMAC output.

This is worth adding to the BIP. I agree with akarve an application intended to support every HWW should try to use <= 512-bits to avoid the DRNG.

However for the BIP93 app we run into a conflict where BIP93 can't be implemented with only 512-bits so its unfortunately a DRNG app. Future codex32 profiles like extended private keys or passwords would need even more bits (for shares).

I really cared about the BIP93 app here - but in this current form I rather not implement it and do my own thing