I'm not convinced requirements 3 and 4 are actually needed.
3) make internal state not useful to the attacker.
4) assuming the ciphertexts won't leak seems silly. Might as well hand them out.
Which leads to what they call "trial decryption" to be a better solution. If you are that worried about the scalability of your whistleblower protocol at that level, we are trying to solve the wrong problem.
> Bitmessage is in need of an independent audit to verify its security. If you are a researcher capable of reviewing the source code, please email the lead developer. You will be helping to create a great privacy option for people everywhere!
Oh I don't recommend using bitmessage. It's a huge illegal content hazard. But it's design is the right set of tradeoffs for the situation this article describes.
In Australia you can be sentenced for up to 5 years for refusing to testify (in a secret hearing you can't tell anyone about). 2 years for refusing to give encryption keys. In general one should not rely on a protocol to protect you if someone comes at you with a wrench.
They say don't roll your own encryption protocol (if something similar or same already exists and it's maintained), but these guys just can't resist.
Using a secure decentralized messenger to share a download (or upload) location on a Hidden S3 Service or one of those decentralized S3 services can't possibly be worse than this.
To commenter in https://news.ycombinator.com/item?id=40289777: BitMessage doesn't solve anything, it uses broadcast and Bitcoin peer nodes that first get the message know where it came from. And BitMessage is not an illegal content hazard of any kind (what a ridiculous statement!).
3) make internal state not useful to the attacker.
4) assuming the ciphertexts won't leak seems silly. Might as well hand them out.
Which leads to what they call "trial decryption" to be a better solution. If you are that worried about the scalability of your whistleblower protocol at that level, we are trying to solve the wrong problem.