Re: Off-the-record [Was: ID theft (offtipicish), but is now more on topic]
On Mon, 5 Feb 2007, Oded Arbel wrote: You seem to imply that with off-the-record, both a third party that has access to the entire session can prove the identity of at least one side of it (destroying deniability) and that on a second session one cannot be assured of the identity of the other person w/o again performing manual verification (destroying authentication). So you are essentially calling the OTR guys liars, right ? I am not familiar with OTR but I have good reasons to believe that if a third party (like an OTR client's ISP) intercepts all the client's communications with otr during a session then they may be able to play man-in-the-middle after that. Unless the otr client and otr (or another client) share a secret that is not communicated through the intercepted channels. So I'm not calling them liars, please don't put words in my mouth, I hate that. I assume that with sufficient effort the powers that be could eavesdrop on the communication without trying very hard. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Off-the-record [Was: ID theft (offtipicish), but is now more on topic]
On Mon, 2007-02-05 at 21:24 +0200, Peter wrote: > On Mon, 5 Feb 2007, Oded Arbel wrote: > > > That doesn't work with simple session only encryption, and what I don't > > understand is how they both offer assurance and deniability, if the next > > time I'm talking with the same guy I can be assured of his identity but > > he can later claim that it wasn't him. > > Think about how the unique session key is generated: a pubilc key > exchange occurs, with or without second factor authentication (on the > phone as you said), then a session key is generated and used based on > this. The session key is used only once and then destroyed. The next > time you connect you cannot in theory know that you are talking to the > same person without using the second factor again imho (otherwise you > are relying on communication possibly crypted with a private public key > sent during the second factor communication). Deniability relies on both > sides destroying the session keys immediately after use, the server not > storing or saving any. After the fact, only a lie detector can find out > if you did talk to the other guy. Of course anybody having run a packet > sniffer all the time on either connection (and having listened in on the > phone) will only pretend to be using the lie detector since he already > knows what he needs to know. You seem to imply that with off-the-record, both a third party that has access to the entire session can prove the identity of at least one side of it (destroying deniability) and that on a second session one cannot be assured of the identity of the other person w/o again performing manual verification (destroying authentication). So you are essentially calling the OTR guys liars, right ? -- Oded ::.. "He looked a lot bigger when I didn't see him" -- Jayne (Adam Baldwin), "Firefly" = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Off-the-record [Was: ID theft (offtipicish), but is now more on topic]
On Mon, 5 Feb 2007, Oded Arbel wrote: That doesn't work with simple session only encryption, and what I don't understand is how they both offer assurance and deniability, if the next time I'm talking with the same guy I can be assured of his identity but he can later claim that it wasn't him. Think about how the unique session key is generated: a pubilc key exchange occurs, with or without second factor authentication (on the phone as you said), then a session key is generated and used based on this. The session key is used only once and then destroyed. The next time you connect you cannot in theory know that you are talking to the same person without using the second factor again imho (otherwise you are relying on communication possibly crypted with a private public key sent during the second factor communication). Deniability relies on both sides destroying the session keys immediately after use, the server not storing or saving any. After the fact, only a lie detector can find out if you did talk to the other guy. Of course anybody having run a packet sniffer all the time on either connection (and having listened in on the phone) will only pretend to be using the lie detector since he already knows what he needs to know. Peter = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: Off-the-record [Was: ID theft (offtipicish), but is now more on topic]
On Mon, 2007-02-05 at 17:55 +0200, Peter wrote: > On Mon, 5 Feb 2007, Alon Altman wrote: > > > On Mon, 5 Feb 2007, Oded Arbel wrote: > >> > >> It seems like they claim both deniability and and assurance (which is > >> what you get from signing, except w/o the signing part) at the same > >> time. > > > > I think that the trick is to give the other party the signing key right > > after you signed the message. > > The usual trick with just-on-time crypto like that is to use a > public/private key system to generate and exchange a unique key to be > used just for that session, and then destroy it. Problem - it maintains authentication across sessions: when at first I talk with someone, I get a crypto thumbprint that I need to verify manually that it belongs to the person I'm supposed to be talking (for example - by phone). After I do that once, whenever I talk with the same person, I am assured that its the same person. That doesn't work with simple session only encryption, and what I don't understand is how they both offer assurance and deniability, if the next time I'm talking with the same guy I can be assured of his identity but he can later claim that it wasn't him. -- Oded ::.. "It's sort of a threat, you see. I've never been very good at them myself, but I'm told they can be very effective." = To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
