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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
