The methods that perform the encryption/decryption are: void p3ChatService::receiveTurtleData() void p3ChatService::sendTurtleData()
... in libretroshare/src/services/p3chatservice.cc The key is generated just below, in bool p3ChatService::createDistantChatInvite() As you can see, it is signed and then encrypted. Only the destination knows who issued the invite. When using a tunnel to talk, intermediate peers have no information about who is the source and destination of the tunnel (by design). There's a few places for improving that code. In particular the fixed buffer sizes that might cause problems, and the lack of padding before AES encryption. Distant chat invites are decrypted in bool p3ChatService::initiateDistantChatConnexion() On 05/12/14 10:26, Neal H. Walfield wrote: > At Sun, 11 May 2014 21:59:12 +0200, > Cyril Soler wrote: >> >> Well, the shared AES key for distant chat is a totally random key that is >> valid for a specific >> triplet (chat invitation, source, destination). That is precisely what PFS >> achieves as well. >> >> PFS needs to do it in a way that is safe to man in the middle attacks. That >> is why EDH in Retroshare >> for instance uses authenticated diffye Helmann. >> >> When you think about it, the two (SSL+EDH and RS distant chat) are very >> similar, but with a >> different time frame. Of course, if you keep using the same chat invite for >> a long time, it is >> similar to not renewing a PFS key during a long session. Not more. > > PFS relies on the use of short-lived keys that can't be rederived once > they are discarded. Based on what you've said and what is in the blog > post I'm not yet convinced this is the case. Ideally, I'll find the > time to read the code (if you could point me to the right place, I'd > appreciate it). > >> What is the problem you are suspecting exactly? > > I need to look a the details of RS's distant message protocol to > better convince myself that it satisfies the requirements of PFS. > > But, repudiability is, citing the OTR paper, "no one should be able to > prove Alice sent any particular message, whether she actually did, or > not." Thus, if Alice signs her messages with her private key, then we > know she sent the message. OTR works around this problem by have a > share private key that both Alice and Bob use to sign their messages. > Thus, Bob knows, by the process of elimination that a signed message > that he didn't compose came from Alice, but he cannot prove to a third > party that a signed message came from him or Alice. > > > Thanks for the quick response! > > :) Neal > >> On 05/11/2014 09:08 PM, Neal H. Walfield wrote: >>> I was reviewing the chat service protocol as described here: >>> >>> >>> https://retroshareteam.wordpress.com/2013/08/08/distant-chat-and-messaging-using-generic-tunnels/ >>> >>> I found the following description a bit worrisome: >>> >>> Messaging and chat however need confidentiality. Therefore messages >>> are end-to-end encrypted. This is made possible by two different >>> mechanisms: distant chat uses a pre-shared symmetric AES key, that >>> is known only from the two chatting peers. Distant messages are >>> encrypted using the PGP public key of the destination and possibly >>> signed by the source. >>> >>> It seems that RS's chat protocol doesn't PFS or reputability. See the >>> paper on OTR for details of what this entails: >>> >>> https://otr.cypherpunks.ca/otr-wpes.pdf >>> >>> Is this correct? I'd appreciate any clarification! >>> >>> Thanks! >>> >>> :) Neal ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Retroshare-devel mailing list Retroshare-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/retroshare-devel
