Not logged in. · Lost password · Register
Forum: Community Feature Requests RSS
Off-the-Record (OTR) Messaging

Announcement

11-16-2005, 13:33 by halr9000
Subject: Psi Groupchat (new address)
Join us at the Psi Groupchat (MUC)! Room name: psi@conference.psi-im.org
Page:  previous  1  2  3  4  next 
fracam #31
Member for 2 months · 2 posts
Group memberships: Members
Show profile · Link to this post
I know there was someone in germany how made a plugin for a pimped linux version of psi, but as far as i know its not realy easy to get it running.

A great plugin api in psi and an easy to use otr-plugin for all OSs would be great. Unfortunately I'm no hacker :-/
Yuri #32
Member since 07/2008 · 2 posts
Group memberships: Members
Show profile · Link to this post
I really think you should implement OTR, it seems like a killer application to me. Only reason I'm still using Psi instead of an OTR-capable alternative is that I dislike Pidgin and Miranda.

Why are you against including it?
Avatar
infiniti (Administrator) #33
Member since 09/2002 · 1459 posts · Location: California, USA
Group memberships: Administrators, Developers, Members
Show profile · Link to this post
Quote by Yuri on 12-07-2008, 18:21:
Why are you against including it?

Psi is close to the standards organizations (e.g. IETF, XSF), and we believe it is best to go by their recommendations, especially those related to security.  I guess the simplest answer for you is that no standards organization we trust is recommending the use of OTR, but they are recommending the use of alternatives.

Currently the XSF is preparing a proposal for the use of TLS in client-to-client encryption.  This will likely be the way forward.
-Justin
Yuri #34
Member since 07/2008 · 2 posts
Group memberships: Members
Show profile · Link to this post
What kind of alternatives?

I only know of PGP, which is kind of unhandy and doesn't offer all the features OTR has; plus there are lots of people who use OTR or use OTR-only clients.

As far as I'm concerned, TLS does not offer perfect forward security or deniability - or does it?
debianuser #35
Member since 01/2007 · 108 posts
Group memberships: Members
Show profile · Link to this post
I would really like to see otr in psi, too.  :)
Avatar
infiniti (Administrator) #36
Member since 09/2002 · 1459 posts · Location: California, USA
Group memberships: Administrators, Developers, Members
Show profile · Link to this post
Some years ago, the XSF actually proposed an OTR-like spec called Esessions.  In response, security consultants suggested that existing proven technologies be used instead, such as PGP, TLS, or CMS.

I agree that PGP is cumbersome.  TLS stands a better chance of offering a simpler presentation.  It also has perfect forward secrecy, but not deniability.

Given that deniability is an unproven concept (and a fringe one, at that), I think TLS is a wise choice over OTR.  You may disagree, but try to imagine yourself in our shoes having to make a decision like this.
-Justin
torkiano #37
Member for a month · 1 post · Location: Vigo, Spain
Group memberships: Members
Show profile · Link to this post
Seems that XEP-0116 (Encrypted Session Negotiation) has been Deferred because of inactivity.

See http://jabberforum.org/showthread.php?t=192

And this from Gajim developer (only client that implement XEP-0116): http://necronomicorp.com/lab/gajim-0.12-esessions-ui
InCo #38
Member for 2 weeks · 4 posts
Group memberships: Members
Show profile · Link to this post
Could someone who is aware of the design of the security system clarify one point please?

Isnt OTR simply vulnerable to Man-in-the-Middle attacks? if all of the traffic is intercepted? Are there way to transfer the inital keys over the channel which is encrypted with pre-shared keys? If not, is it possible to do so with GPG? (if the latter is true, psi gets at least 6 more users :) )
Voker57 #39
User title: ~quirks mode~
Member since 06/2007 · 17 posts
Group memberships: Members
Show profile · Link to this post
It shouldn't be, as OTR uses Diffie-Hellman algorithm for key exchange.

GPG offers this as well, also its encryption is stronger.
InCo #40
Member for 2 weeks · 4 posts
Group memberships: Members
Show profile · Link to this post
Hm, but how can a person initiate a secured chat with another person when the channel is transparently monitored? There is a MiM attack on the SSL which uses key exchange, and it is very simple and straighforward, as long as all of the traffic is intercepted.
debianuser #41
Member since 01/2007 · 108 posts
Group memberships: Members
Show profile · Link to this post
You have to test, if there is no man in the middle. You do this though verification. See the homepage:
http://www.cypherpunks.ca/otr/

and especially how it works:
http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html

Yes, the crypto is stronger, but there were some mails on the mailinglist, where a dev explained, why this is the case, and why it is okay, as it is:
http://lists.cypherpunks.ca/pipermail/otr-users/2008-May/…

I really like otr :)
Avatar
infiniti (Administrator) #42
Member since 09/2002 · 1459 posts · Location: California, USA
Group memberships: Administrators, Developers, Members
Show profile · Link to this post
The only way to avoid a man-in-the-middle attack is with pre-shared information.  Thanks to public key cryptography, this pre-shared information doesn't even need to be secret.  Fingerprints (or public keys themselves) just need to be exchanged without them getting tainted along the way.

X.509 and PGP attempt to relieve the burden of trading fingerprints.  All other systems I'm aware of (SSH, OTR) require a fingerprint trade.  Of course, it's possible to bootstrap one system with another.  For example, you could PGP sign your OTR fingerprints, thus pushing the authentication burden into the PGP space.

Practically speaking, every system is vulnerable to a man-in-the-middle attack.  Obviously SSH and OTR are vulnerable if used improperly (e.g. not checking fingerprints), and the same can pretty much be said of PGP.  Only X.509 has a chance of being bulletproof from user error, however most software allows the user to skip key/fingerprint validation.  If Firefox 3 is any indication, we may see a trend in future X.509 software to make it difficult or impossible to bypass validation.

There is an ejabberd plugin to perform a man-in-the-middle attack on OTR sessions:
  http://blog.bepointbe.be/index.php/2007/03/29/20-mod_otr

Hopefully no evil server admins are running that...

Diffie-Hellman does not prevent man-in-the-middle attacks.  The DH algorithm offers a handy way for two parties to agree on a shared secret, and it is used in protocols like TLS and OTR to provide forward secrecy (often called "ephemeral DH keys").

SSL/TLS (using X.509 certificates) is not vulnerable to a man in the middle attack if the system and software are used properly.  For example, if you go to the website of your bank and the browser shows a gold/green bar without any sort of warning popups, then you are safe.  That said, this works because you've connected to a responsible organization (a bank).  If the parties involved are only regular people, then X.509 breaks down quickly.

Most-likely, TLS for client-to-client encryption in XMPP would not involve the use of certificate authorities and the result would be no better or worse than OTR.
-Justin
InCo #43
Member for 2 weeks · 4 posts
Group memberships: Members
Show profile · Link to this post
I would have  to disagree again. As you said correctly. Asymmetric  keys protect the session from packet injection and provide forward secrecy. But just theoretically it is _impossible_ to provide a safe encryption if the keys are exchanged over the same channel as the content (as far as I understand the basic principle of that).

What I would like to know if ORT exchanges the public keys once, or does it create a new certificates every time? (i.e. if the first session is done over a secure channel, will all further sessions be safe from MiM attacks?)


The main problem are not the evil servers that play with MiM attacks (but I do consider that as a possibility). ANY wi-fi hotspot can be monitored by anyone with wifi card, or even just if you are unlucky and got HUB instead of a Switch in your house. I know this can be solved with pre-shared openvpn, but I dont really care if someone will steal my password for msn account.
debianuser #44
Member since 01/2007 · 108 posts
Group memberships: Members
Show profile · Link to this post
OTR creates a key with a fingerprint only once. This lasts a few seconds and is used to verify the identity of the user.

If you start to talk a new session will be opened and a new temporary key will be created. This key is used to encrypt the session. If you start a new session a new temp key will be created and you can still be sure the there is no mitm attack.
(As far as I understand this)

But you can read this more correctly and more completely on the homepage I think.
Avatar
infiniti (Administrator) #45
Member since 09/2002 · 1459 posts · Location: California, USA
Group memberships: Administrators, Developers, Members
Show profile · Link to this post
InCo: Sorry, I should have clarified.  By "exchange" I meant using a separate, secure channel (phone, in person, whatever).  This exchange is essentially the same as pre-shared information.  You either need to have shared something in advance, or you need to share something at the time of negotiation, but in both cases this information cannot be shared over the hostile channel.

OTR, like SSH, creates primary public keys once and caches fingerprint information.  This means you only need to manually trade/verify fingerprints with a contact one time and all other sessions are protected.  If anyone uses a fresh OTR installation then the process has to be repeated.
-Justin
Close Smaller – Larger + Reply to this post:
Smilies: :mellow: :huh: ^_^ :o ;) :P :D :lol: B) :rolleyes: -_- <_< :) :wub: :angry: :( :unsure: :wacko: :blink: :ph34r:
Special characters:
Page:  previous  1  2  3  4  next 
Go to forum
Unclassified NewsBoard devel of 20051113 © 2003-5 by Yves Goergen
Current time: 01-06-2009, 08:39:46 (UTC -05:00)