Do not describe recovery data as "public" and mention deriving an encryption key from the deed.

[jonasnick]

In the design section, it currently says:

Simple backups: The capability of ChillDKG to recover devices from a static seed and public recovery data avoids the need for secret per-session backups, enhancing user experience.

If the recovery data is public it might reveal sensitive information. We mention that clearly about that in the later sections, but ideally we would have a less misleading phrasing here.

Additionally, we should consider mentioning that it's possible to derive an encryption key from the seed (and maybe how to do that), such that recovery from encrypted recovery data requires no additional secret besides the seed.

[real-or-random]

Additionally, we should consider mentioning that it's possible to derive an encryption key from the seed (and maybe how to do that), such that recovery from encrypted recovery data requires no additional secret besides the seed.

We could consider just adding an individual encryption/decryption method as part of the spec. When we had discussed this earlier, I was hesitating to suggest this due to scope creep. But symmetric encryption is just a few lines of code, so perhaps it's not too much overhead in terms of complexity, and it will save others the work to come up with their own method encryption (and agree on it).