OTR Encryption

[GoogleCodeExporter]

An needed feature for GTalkSMS is encryption of the traffic between the phone 
and the user.
As many chat-applications support OTR I think this would be the best solution 
for GTalkSMS, even though it might be a huge thing to implement.

Original issue reported on code.google.com by abber...@gmail.com on 26 Jul 2011 at 7:45

[GoogleCodeExporter]

There is already an encryption option in the advance server settings. 
It's the TLS security mode.
Did you try this one ?

Original comment by Florent....@gmail.com on 31 Jul 2011 at 4:40

[GoogleCodeExporter]

Off the record encryption would sure be nice. Also more and more clients are 
implementing it. But I am unsure about the interoperability. Also we have first 
to decide an a library. A quick search showed the following candidates:
java-otr-0.1.0: http://www.cypherpunks.ca/otr/index.php#downloads that is the 
one gibberbot uses, from Oct 2009
otr4j: http://code.google.com/p/otr4j/ - last change Aug 2010

Original comment by fschm...@gmail.com on 23 Aug 2011 at 8:35

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by fschm...@gmail.com on 23 Aug 2011 at 8:35

• Changed title: OTR Encryption
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Replying to @1, TLS security mode, if I understand it correctly, is only going 
to encrypt the connection from the phone to its designated XMPP provider. Even 
using encryption from your own GTalk or Jabber account to the XMPP server may 
not guarantee encryption. The connection then between XMPP providers themselves 
may not be reliably encrypted.

Example: I use a Jabber account for my phone, and it sends updates to my GTalk 
account, so the overall chain looks like: phone --> Jabber --> GTalk --> me. 
The connection from my phone to Jabber is secure. The connection from Gtalk to 
my computer is secure. But the connection between Jabber and GTalk may not be 
secure, depending on how the connection is made, and we have no control over 
this.

This necessitates an additional encryption layer, such as OTR, to ensure at 
least one layer of encryption for all links in the communication chain. Hope 
this helps.

Original comment by devm...@gmail.com on 4 Nov 2011 at 7:32

[GoogleCodeExporter]

This would really be a nice feature, do you think that it will happen any time 
soon?

Original comment by r...@teeuwen.be on 15 Oct 2012 at 1:20

[GoogleCodeExporter]

This request is nearly two years old now, any news? :)

Original comment by burritob...@gmail.com on 23 May 2013 at 4:08

[GoogleCodeExporter]

What's the point of this? If you don't trust your XMPP provider, you should 
trust your cellular provider even less.  If you threat model includes a person 
or entity spying on your XMPP service provider's logs to decode what SMSes 
you're sending / what phone calls you're making, etc., they definitely should 
include a person or entity spying on your telecom provider for the same.

OTR, in this case, does not provide any additional benefits, while being hard 
to do right (managing OTR keys, signalling trust level, etc.)

Original comment by the.soli...@gmail.com on 17 Aug 2014 at 2:44

[GoogleCodeExporter]

What's the point of leaving it out in the open?

Original comment by Nato...@gmail.com on 17 Aug 2014 at 5:49

[GoogleCodeExporter]

Indeed, I closing this issue as it is not planned to provide another encryption 
layer (than TLS for the server connection).

Original comment by Florent....@gmail.com on 17 Aug 2014 at 6:50

• Changed state: WontFix

[GoogleCodeExporter]

*sigh* I guess I'm okay with that since I'm using a more appropriate solution 
right now. I actually meant what's the point of leaving the communication so 
that the server can see it?

Original comment by Nato...@gmail.com on 17 Aug 2014 at 6:57