# Zero Knowledge Message Franking

## Intro
With Facebook enhanced message abusive report protocol a line of research work designed message franking protocols, which are faster, more secure and operate in different settings[citations]. All those schemes follow an all-or-nothing approach whereby if the sender has sent according to the receiver an abusive message the latter in order to verifiably report it to a third party platform it is forced to open the entire plaintext message to the platform thus giving away confidentiality and privacy. That sounds acceptable at a first view. Imagine in real world you are receiving a box parcel with inappropriate content from a known sender. Then you go to the police department with the parcel and you file a report for that specific sender. Alas, what if the sender has attached in in the box parcel personal objects refering to information you do not want to reveal to anyone - including police authorities? E.g the sender has marked with a non-erasable marker your credit card numbers and pins or a very personal picture which cannot be detouched from the original object. In that case the receiver would be relunctant in proceeding in any form of reporting.

The authors in [citations] addressed the aforementioned issue with privacy preserving message franking protocol. Namely throughout a per block encrypting and commiting the privacy of the message is not completely given away, since only the abusive blocks of the emssage are opened to a third party. In [a] the aurhors used a merkle tree to prove membership of a block as part of an entire message that has been sent from the sender to the receiver. The high level idea is to commit to each block with a different key and during the reporting phase the third party verifies consistency only for the open blocks be the receiver and not the entire message. Similarly in [b] the authors presented a solution using vector commitments for selective opening. Both solutions minimize privacy exposure of the message only to the required blocks that the abusive information is being present. However in extreme scenarios an adversary can potentially craft special messages that include a private sensitive bait such a pin number or a password to the abusive blocks, hoping the sender will not open that block to the third party as the private bait is confidential. Under that extreme circumstances the receiver of the abusive blocks is willing to ideally open only at the level of bits the ctafted abusive content and skip the private bait inside that block.
A first solution would be to follow the vanilla approach of [a,b] at the granularity of the bit level. Encrypt and commit to each bit separately. However, that would be prohibitive in terms of storage and network overhead.

### Real Private Franking Model
* Sender, Receiver, Third party

---

* EncryptCommit(k,m)->c=c0,c1
* Decrypt(k,c)->m/0
* Blame({i...j},c)
* RevertLodge()