Suppose you wanted any three of your six grandchildren to be able to decrypt your will, so you generated a 96-bit random key to encrypt it, then used Shamir secret sharing to split the key into six subkey shares. How big would these subkey shares have to be?
Clearly you can use the Galois field of a 97-bit prime, such as GF(131083052269145407673490965609†), and then all your polynomial coefficients and polynomial points can hold 96 bits. But your grandchildren then have to memorize or otherwise safely store 96 bits, which is a pain. For example, bitwords.py encodes the random 96-bit number 26308797542951093779994009496 as “lock fall alpha index piano verb cups barns”, which is clearly memorizable but also clearly nontrivial to memorize. (And actually they need to memorize a few more bits so that we know which coefficient or point they hold.) Couldn’t we do with less, since we’re putting in 291 bits and only getting out 96?
Not really. Suppose we come up with some scheme such that each grandchild only has to memorize 48 bits (“hans graph na laugh”, “turns high sat lust”). Now, two grandchildren colluding can rent a supercomputer and run the secret-sharing computation with their two keys and each of 2⁴⁸ possibilities from a third grandchild. On average, 20% of the way through the search space, they’ll hit one of the other grandchildren’s shares, decrypt your will, and possibly hatch a plot to kill you or or one of the more favored grandchildren.
This reasoning is entirely independent of the secret-sharing algorithm — it doesn’t depend on any special features of Shamir’s protocol — but using a slow KDF (say, 2⁴⁰ to 2⁴⁸ work per decryption attempt, minutes to hours on fast silicon) might slow down the attack by a useful amount, allowing the original secret to be of size 48–56 bits without a loss of security.
† Prime verification was deterministic, but if the factoring code was buggy, I might not know. Rely on this number’s primality at your own risk.