@peg that's great! yes I can trust @keks to make a suggestion like that. my only addition then is to also use such a scheme for sending the shards to begin with, so that you can revoke shards (i.e. holders are able to choose to forget a shard)

I'm wondering if it makes sense to have such a forward secrecy within an encrypted thread mechanism, as a generic pattern that is useful for other ssb applications? It would mean you could use ssb to transfer a small secret and then forget it - although the metadata (that you told them a secret) wouldn't be forward secret. Can anyone think of another application that might benefit from this?

@peg also to put the commenters suggestion to use 32 byte checksums in perspective - bitcoin mining can generate 64 bit (8 byte) partial collisions, but that costs thousands of dollars to generate, and each additional bit doubles that cost. There are plenty of trustworthy systems that use 16 byte (128 bits). 128 bits of security is considered the standard. I normally don't truncate hashes, I just suggested this over using sha1. My earlier suggestion to use libsodium secretbox also implies a 16 bit mac, although not inside the share, and wouldn't require altering a primitive. (I'm confidant the difference here is just a matter of taste though)