+# 2019-09-06

+

+The birthdate can be in the encrypted area.

+

+Using the reconstructed secret as a private key might be a problem. Say you have 2-of-3 and you reveal the last byte of 2 of the shares. You think you're perfectly safe. But since the secret sharing is done bytewise, then you have revealed the last byte of the... So you can hash the secret. You use the PBKDF to distribute the entropy evenly. Once you get information about bits from the private key, you are opening up to attacks on elliptic curves. So just do a hash, and that will be fine. Hash it, and derive several keys like an encryption key and a signing key, and you derive many more bits than is the actual entropy of the secret. You don't want to reuse the key of course for the.. purposes. There aren't any good signcryptions yet, like AEAD.

+

+Yesterday we decided to maintain SLIP 39 compatibility.

+

+The checksum property violates the Shamir property. You're collecting some theoretic amount of information about the final result. You don't have 32 bytes of entropy left, you only have 28 bytes of entropy left. Instead, you can hash the original secret and store that hash. The checksum on each shard is okay, to make sure the shard information is stored correctly.

+

+A pure shamir in theory when you have a 6-of-7-of-10, you have no knowledge of the secret. But in our secret, because of the checksums, if you have the 6 of the 7-of-10, you have a tiny amount of the 7th, perhaps as much as 4 bytes. Not the actual 4 bytes of it, but 4 bytes of its entropy. You've reduced the search space by 32 bits. We should probaly mention this in passing. Probably in the future, when there's 1000s of shares, there might be something where the it actually becomes feasible for you to restore it missing a share or something--- this might impact us or something. No, I don't think so. This doesn't scale that way. As you scale out more shares, you're adding more entropy to the stuff required to deal. So that scales the right way for security purposes. The problem would be decreasing the size of the secret. We said in SLIP 39 the minimum is 128 bits. In the worst case, if everything goes bad, you only have 96 bits of security, regardless of the number of shares.

+

+I don't think we're going to have the checksum in our binary serialization. Are we talking about the same checksum? The last three words? No, it's a different checksum. There's a checksum for each share. So if you make a mistake in typing one of the words, you can immediately see it. But it's not cryptographic, in that anyone can false that. You are talking about a checksum on the actual secret, which is a result of combining the shares. In SLIP 39, I think this is called a digest. Yes, we call it a digest, to differentiate it from the checksum on each share.

+

+It's really useful to be able to tell at the end of this thing, that you have got the right one. We already have a way of doing that, because we have a signature. We're pre-authenticating that the shares are correct when you receive them, because they have a valid signature. So we don't need a digest. Other than the SLIP 39, does not have a way to do that. Can you initialize a trezor device with SLIP 39 without the digest? It would not be valid shares.

+

+<https://github.com/BlockchainCommons/sss/pull/2>

+

+Large engineering project risk management using a bayesian belief network <http://sci-hub.tw/https://www.sciencedirect.com/science/article/pii/S095741740800448X>

+