This is useful for the following threat-model:
> The randomness generated by the CPU/OS is assumed weak, but otherwise the user trusts the CPU/OS to execute code as-is.
> The user can inspect the source code to see what they provide as custom entropy is used in a sane way.
As the extra entropy is simply XOR-ed in, into the OS-generated randomness, it cannot be used as a footgun.
Note this significantly differs from the old custom_entropy option [0] that existed between version ~2.0 and 3.1.2 [1]:
- the old option *replaced* the OS-entropy with the user-provided entropy
- e.g. if the user provided what looked like 64 bits of entropy, and by default we wanted to create a 132 bit seed,
the resulting seed only used 132-64=68 bits of os.urandom()
- hence I think the old option was a footgun -- it required expert knowledge to use properly
- instead, the new option mixes the user-provided entropy with os.urandom(), in a way that can never make the
result have less entropy
- with the old option, the "custom_entropy" arg was an int, of which every "bit" was used as-is
- for example, if the user wanted to provide some dice rolls,
e.g. "6 3 5 2 6 6 2", and they passed the int "6352662" (base 10), they lost a lot of entropy by not using high decimal digits
- i.e. the user was required to know *how* to convert their entropy to the expected format
(e.g. dice rolls as base6, and then convert to base10)
- instead, the new option takes an arbitrary string, which is then hashed internally, hence it is not possible to misuse the API
- e.g. it is safe to provide dice rolls as a string, e.g. "6 3 5 2 6 6 2" or "6352662" or in any imaginable way
- the old option exposed a "check_seed" CLI command, that could be used to verify the user-provided entropy was used
as part of the seed-generation. This is not possible with the new option.
related spesmilo#523 (comment)
[0]: https://github.com/spesmilo/electrum/blame/883f9be7d15cf1aba16895a0848f0d7af99f2ff3/lib/mnemonic.py#L149
[1]: 5e5134b