[messaging] Provable (private) conversation while allowing (somewhat) precise redaction

[Tamme Schichler]

Am 09.10.2014 um 22:07 schrieb Dave Crocker:
> On 10/9/2014 9:08 AM, Tamme Schichler wrote:
>> Thanks for these links, the proofs of receipt are definitely something I
>> need to look into. Ideally it should be simultaneous, but I don't know a
>> scheme that can do that without a witness.
> ...
>> Since I'm thinking about a chat protocol 
> ...
> 
> 
> Non-repudiation of receipt throughout a conversation.  Interesting
> requirement.

It's so that none of the participants can pull the plug on their
connection to make it unverifiable, and to ensure that the other side is
at least somewhat honest about using a compatible client.

The community I'm talking about is one where a lot of claims are
repeated without verification, based on the senders reputation alone.
(I'm not directly involved but have been doing some research for the
past month or so. Some of the stuff I've seen has been rather wild, to
say the least, but I'm not going to go into more details on-list.)


The requirement isn't exactly "hard", it would technically be enough to
display a very clear warning if no proof arrives for one of the messages.

I'd prefer to require it for protocol compatibility though, which should
be possible by making the protocol sequential. (It still wouldn't be
simultaneous, but new messages couldn't be sent before receipts for the
previous ones. Group conversations would be fairly unstable with the
simplest implementation though.

Maybe having the latter isn't that important for this protocol though,
since then there would be witnesses in the first place... or not.
Thinking about it it would definitely be good to have them, but I think
then a lot of the group-OTR problems apply.)

>
> Yeah, I doubt there's a deployed solution, though I'm not plugged in to
> the right communities to be sure.
> 
> FWIW, what I've been used to seeing, for non-repudiation mechanisms, is
> a requirement for an independent time-stamping service, rather than for
> a more elaborate third-party role.
> 

That's great for public information and I've come to appreciate
archive.today, archive.org and the various specialised undeleter
websites a lot in the past month.


For the unilateral proof I think it's only important to ensure that the
proofs are simultaneously in transit at any point in time. An example
half-transaction would just contain

request: |plain-text|A's signature|B's public key|
answer:  |B's signature|

with the server matching up the plain-text and verifying the signatures
accordingly before sending any answers. (I think there may be
performance issues with common plain-texts though, maybe the request
would also have to contain A's public key to make invalid matches
uncommon enough.)

The "plain-text" sent to the server would of course just be a hash
authenticating an original message here.

> 
> Relevant links that popped up on non-rep, recipient, conversation:
> 
>    Non-Repudiation in Internet Telephony
> 
> http://sit.sit.fraunhofer.de/smv/publications/download/VoIP_Non_Repudiation.pdf
> 

This could be useful for ensuring the timing isn't manipulated, but the
protocol isn't redactable... it may fit on the overarching layer
chaining the messages together though. I'll have to read a bit more
thoroughly to see how they handle disconnections.

> 
> http://security.stackexchange.com/questions/29550/recipient-non-repudiation-in-secure-e-mail-transport
> 

I think this part of the accepted answer sums it up nicely:

| Summary
|
| This is a hard problem for which no solution exists yet; the
| technical tools are ready (e.g. asymmetric signature algorithms), but
| it also needs some infrastructure which will need official support,
| will be expensive, and won't be of any use until is has become so
| important that it cannot be ignored. This looks like a problem which
| will not be solved any time soon.

Implementing non-repudiation for conversations may be a lot easier
though, since what must be proven is not that a message was received but
what something was in reply to.

(For example let's say A insults B in message n. Then A would have to
send their proof together with the message for it to go through, or B
will only see an error instead and disconnect.

Similarly, B can be forced to confirm the receipt of message n-1 before
being able to send message n, so if message n misrepresents message n-1
A can reveal n-1.)

A great side-effect of the signature of tree-compressed of the chunk
hashes that was proposed earlier is that additional parts of the message
can be verified against the original revelation, which will have been
witnessed at that point. (The compressing hash function has to be fairly
strong in order not to allow brute-forcing chunk nonces for arbitrary
chunks.)
This means the receiver is unable to undisprovably misrepresent a
message with signature even if the receipt was not confirmed yet. (In
addition to [REDACTED] showing up all over the place.)

> 
> http://docs.oracle.com/cd/E13214_01/wlintegration/v2_0/collaborate/security/nonrep.htm
> 

This isn't very helpful from a technical point of view, but it's
certainly interesting to see how this issue is handled in a business
context. Even if I was considering to make this in Java I'd probably not
use that class though... everything about the code sample reminds me of
one business application's database access I had the "pleasure" to work on.

The secure services seem interesting though, if there's a specification
of the protocol it may be possible to use them (but I suspect they
aren't publicly available and that it's easier to write one from scratch
than to possibly interface with Java remoting).

> 
> (I was amused to see that the end of the google list for that search was
> a pointer to my previous message to you...)
> 
> 
> d/
> 

It seems non-repudiation is a bit less popular among people who
regularly look into cryptography than the other applications.

I suspect it's because the groups that would benefit from it the most
are those responsible for larger business transactions and those doing
activism in reputation-minefields, both of which don't necessarily have
that much to do with computer science.

On the surface it's also less cool than being able to send deniable
messages completely hidden from public view ;)


Tamme