Let's say Alice sends a message to Bob in their P2P chat app asking him to complete some work. Bob is lazy, so he deletes the message off his machine, does not complete the work, and just claims that he never received the message in the first place. Their boss needs to fire someone, but is unsure who is telling the truth.

Is there a way they could improve the chat app so that Alice could prove to her boss that she sent a message, assuming that Bob is completely uncooperative?

  • Alice sending the message and Bob not receiving it are not mutually exclusive.
    – nobody
    Feb 14, 2021 at 12:48
  • @nobody Sure, but really what I'm trying to figure out is can Alice prove that she sent a message assuming that Bob cannot be trusted at all, i.e. he deleted the message on his end. I'll edit the question to make that more clear
    – JGut
    Feb 14, 2021 at 12:58
  • Bob can always claim that he didn't receive the message by blocking delivery & read receipt if there is one. You need a server which can prove delivery of the message even if Bob blocks delivery & read receipt.
    – defalt
    Feb 14, 2021 at 13:08
  • 1
    One can surely write a chat app which keeps log files about the delivery - as long one has control over the implementation and behavior of the chat clients. But within the scope of your business problem this can usually be ensured. Such a chat app can even log if the message was explicitly deleted by the client. It does not know the actual intend behind the deletion though: was it accidentally or by purpose? Feb 14, 2021 at 14:30
  • This is an interesting reminder about legally-certified and certified-timestamped email systems Feb 15, 2021 at 10:34

1 Answer 1


An interesting question, related to the topic of non-repudiation. In this case, the thing Bob wants to do is repudiate having ever received the message. Here's one way to build a system which is secure against that:

All members of the P2P network have a public/private key pair (this is useful for lots of other things too, like end-to-end encryption). For the purposes of this question, we'll assume that the public keys of Alice and Bob are known both to each other and to the boss.

To ensure non-repudiation of messages both sent and received, the P2P software/protocol is such that:

  • When a message is sent, the sender uses their private key to create a signature of the message, the timestamp, and a sequence number (unique identifier). These values and the resulting signature are transmitted along with the message itself. Now, the recipient can always prove that the sender sent the message and can't fake when it was sent.
  • When a message is received, the recipient signs the message (including the sender's signature, timestamp, sequence number, etc.) with their receipt timestamp, using their (recipient's) private key, and sends that signature back to the sender. Until the sender receives (and verifies) this countersignature from the recipient, the message is considered undelivered; the sender can see an indication of message state. Thus, if the sender ever sees that the message is delivered, they can prove that it showed up on the recipient's chat client, and when.
  • Both signatures and all their metadata, on every message, are stored in both clients.

Now, given these properties, let's look at how we might try to attack the system:

  1. Alice uses a modified client that will sign a message and display it as being sent with the desired timestamp, even if no such message was sent. There's no way to prove that it wasn't sent at that time, either. However, because the message doesn't have a valid recipient signature, it'll be clear that the message wasn't ever received, and if Alice wasn't lying, she should have noticed that the message wasn't received and done something about that.
  2. Bob uses a modified client that will let him see incoming messages without acknowledging receipt of them yet. Bob uses this to have messages that he wants to pretend he never saw just "silently fail" without ever sending the countersignature. However, in this case Alice will see that Bob's client "never received" the message, and will try to reach him some other way.
  3. Bob uses a modified client that will make it look like the message arrived too late for him to act on it, by altering the timestamp. However, Alice has the original message receipt (countersignature), which has the timestamp of when the message was received. She (or her client) should notice if the receipt date is in the future. If it's not - that is, if Bob's copy is modified after the receipt is sent - then Alice still has a copy of the original receipt, with the original timestamp, signed with Bob's private key.
  4. Alice, trying to make Bob look bad, crafts a fake message (that looks like it was sent but wasn't actually), and uses a modified client that displays the message as having been received. However, Alice doesn't have Bob's private key, so Alice's client can't produce a valid countersignature from Bob. When the boss looks at the messages that Alice supposedly sent, and tries to verify the supposed countersignature on Alice's message using Bob's public key, it will be revealed to be invalid.

Obviously, part of this system depends on people making sure that their messages are received. It's impossible to prove, for a message for which you have no countersignature, whether or not the recipient ever got it. So long as you get a countersignature, though, and the timestamp makes sense, either party can now prove that the message was exchanged, and when. Neither side can delete all proof of the exchange, or modify any detail, unilaterally; they would need to cooperate to fake anything.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .