4 ms·

Solution: sign every log entry with its own key. To repudiate an entry, publish the private key you used to sign it. But of course, it needs to be baked in the

Solution: sign every log entry with its own key. To repudiate an entry, publish the private key you used to sign it. But of course, it needs to be baked in the protocol from the start.

jefftk 4y ago
A: Why did you say X? B: You can't prove that I said X! Here's where I published private key used to sign that message. A: Do you normally publish the private keys of your messages? B: No A: Okay, while I agree I do not have cryptographic proof that you said X, I think it's extremely likely that you said X and then later attempted to retract it by publishing the private key. So I'm going to go ahead and act as if you said X.
- immibis 4y ago
  Solution: publish every private key after, say, one week. I believe there are point-to-point protocols that publish every private key after the recipient receives the message, but I don't see how it generalizes to publish-subscribe.
  - renox 4y ago
    OK can you explain to me the interest of using private keys if you publish them afterwards?? I'm missing something..
    - immibis 4y ago
      The recipient knows you sent the message, because they received it before you published the key. Nobody can prove you sent the message, because they received it after you published the key, and even if they did receive it earlier, they can't prove it in court. That's why the key should be published as soon as possible. In a point-to-point protocol, it would be published as soon as the recipient confirms receipt of the message. That's why I'm not sure how it generalizes to group chat protocols.
    - progval 4y ago
      They attest you are the author between the publication of the message (and of the public key) and the publication of the private key.
- rtkwe 4y ago
  Another problem with that; time. You publish the key after you sign and post the message in question. It's tough to prove 100% but you're only really invalidating posts from after the date you publish the private key. It also doesn't solve another part of the problem with append-only, accidental oversharing. Even if we take this 'publish the keys' process as actually working the data is still out there so if you publish info you shouldn't like locations or PII it's always out there.
  - yellowapple 4y ago
    > the data is still out there so if you publish info you shouldn't like locations or PII it's always out there That's true no matter what, purely by virtue of being shared with others.

Solution: sign every log entry with its own key. To repudiate an entry, publish the private key you used to sign it. But of course, it needs to be baked in the protocol from the start.

jefftk 4y ago

A: Why did you say X? B: You can't prove that I said X! Here's where I published private key used to sign that message. A: Do you normally publish the private keys of your messages? B: No A: Okay, while I agree I do not have cryptographic proof that you said X, I think it's extremely likely that you said X and then later attempted to retract it by publishing the private key. So I'm going to go ahead and act as if you said X.

immibis 4y ago
Solution: publish every private key after, say, one week. I believe there are point-to-point protocols that publish every private key after the recipient receives the message, but I don't see how it generalizes to publish-subscribe.
- renox 4y ago
  OK can you explain to me the interest of using private keys if you publish them afterwards?? I'm missing something..
  - immibis 4y ago
    The recipient knows you sent the message, because they received it before you published the key. Nobody can prove you sent the message, because they received it after you published the key, and even if they did receive it earlier, they can't prove it in court. That's why the key should be published as soon as possible. In a point-to-point protocol, it would be published as soon as the recipient confirms receipt of the message. That's why I'm not sure how it generalizes to group chat protocols.
  - progval 4y ago
    They attest you are the author between the publication of the message (and of the public key) and the publication of the private key.
rtkwe 4y ago
Another problem with that; time. You publish the key after you sign and post the message in question. It's tough to prove 100% but you're only really invalidating posts from after the date you publish the private key. It also doesn't solve another part of the problem with append-only, accidental oversharing. Even if we take this 'publish the keys' process as actually working the data is still out there so if you publish info you shouldn't like locations or PII it's always out there.
- yellowapple 4y ago
  > the data is still out there so if you publish info you shouldn't like locations or PII it's always out there That's true no matter what, purely by virtue of being shared with others.