From paddler86@gmx.de Sun Nov 4 15:27:01 2007
From: paddler86@gmx.de (Benjamin Wilde)
Date: Sun, 4 Nov 2007 16:27:01 +0100
Subject: [OTR-users] japanese/chinese signs when beginning conversation + wrong character encoding
Message-ID: <001201c81ef7$265725a0$6401a8c0@hiob>
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C81EFF.8763FD70
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
hi folks
since i've upgraded to miranda 0.7 (problem stays with 0.7.1), all my =
friends receive different japanese or chinese signs at the beginning of =
a conversation.
the problem occurs everytime, wether i or them start the conversation. =
it does not depend on the client software they use or if they use OTR or =
not.
additionally all german umlauts (like =F6,=E4, ....) are not encoded =
correctly (dr=FCber =3D dr=C3=BCber). when i disable the otr-plugin, =
they are encoded correctly.
all of this worked fine under miranda 0.6.8; referring to miranda 0.7 =
changelog (major updates concerning encoding) i'd guess the kind of =
handling character encoding changed in a way that produces these errors.
i found no help in the forum, so can anyone offer me a solution or =
workaround for these problems?
(further information: i'm running windows XP SP2, miranda 0.7.1, OTR =
version is 0.5.2.0)
thanks for any help
------=_NextPart_000_000F_01C81EFF.8763FD70
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
hi folks
since i've upgraded to miranda 0.7 =
(problem stays=20
with 0.7.1), all my friends receive different japanese or chinese signs =
at the=20
beginning of a conversation.
the problem occurs everytime, wether i =
or=20
them start the conversation. it does not depend on the client =
software they=20
use or if they use OTR or not.
additionally all german umlauts (like =
=F6,=E4, ....)=20
are not encoded correctly (dr=FCber =3D dr=C3=BCber). when i =
disable the=20
otr-plugin, they are encoded correctly.
all of this worked fine under miranda =
0.6.8;=20
referring to miranda 0.7 changelog (major updates =
concerning encoding)=20
i'd guess the kind of handling character encoding changed in a way that =
produces=20
these errors.
i found no help in the forum, so can =
anyone offer=20
me a solution or workaround for these problems?
(further information: i'm running =
windows XP SP2,=20
miranda 0.7.1, OTR version is 0.5.2.0)
thanks for any =
help
------=_NextPart_000_000F_01C81EFF.8763FD70--
From michael_reichenbach@freenet.de Sat Nov 10 00:08:03 2007
From: michael_reichenbach@freenet.de (Michael Reichenbach)
Date: Sat, 10 Nov 2007 01:08:03 +0100
Subject: [OTR-users] pidgin, jabber, otr and offline messages
Message-ID: <4734F663.5020704@freenet.de>
It seamed I had still an active otr session with my interlocutor. He
gone offline before and he ended the private conversation.
OTR Error: You sent encrypted data to jabberid, who
wasn't expecting it. Many times... All messages lost.
Next issues, my interlocutor is offline and I want to send him some
messages he shall read next time he goes online. Each time I write
something it comes Attempting to start a private conversation...
jabberid: text... All messages will be also lost.
Otr is working stable and well now if both are online. But if someone
loses connection, goes offline or is offline it won`t work well.
We also set to require private messenging and then you can`t even send a
message if the other one is offline. An important feature got lost
(offline messages). Isn`t it possible to make otr work also with stored
messages on the server?
I would love to see the offline message support a bit improved.
From paul@cypherpunks.ca Sat Nov 10 16:10:30 2007
From: paul@cypherpunks.ca (Paul Wouters)
Date: Sat, 10 Nov 2007 11:10:30 -0500 (EST)
Subject: [OTR-users] pidgin, jabber, otr and offline messages
In-Reply-To: <4734F663.5020704@freenet.de>
References: <4734F663.5020704@freenet.de>
Message-ID:
On Sat, 10 Nov 2007, Michael Reichenbach wrote:
> It seamed I had still an active otr session with my interlocutor. He
> gone offline before and he ended the private conversation.
> OTR Error: You sent encrypted data to jabberid, who
> wasn't expecting it. Many times... All messages lost.
Yes. The bug appears somewhat regularly, but it is very hard to
reproduce, and we haven't caught it yet with a full packet capture to
determine what is going on.
> Next issues, my interlocutor is offline and I want to send him some
> messages he shall read next time he goes online. Each time I write
> something it comes Attempting to start a private conversation...
> jabberid: text... All messages will be also lost.
Yes. OTR requires state and for full functioning interactivity (doing
diffie hellman key exchanges). So either 1) the computer keeps state while
offline or 2) you cannot work offline. The first solution is very dangerous
to support, as "offline" would be the same as "attacker filtering packets",
forcing you to perhaps send all messages with the same one key.
> Otr is working stable and well now if both are online. But if someone
> loses connection, goes offline or is offline it won`t work well.
Yes. It is the price you have to pay.
> We also set to require private messenging and then you can`t even send a
> message if the other one is offline. An important feature got lost
> (offline messages). Isn`t it possible to make otr work also with stored
> messages on the server?
Require private messages requires a handshake between the two parties.
Obviously you cannot do that without the other party being there. See
above.
> I would love to see the offline message support a bit improved.
The only way I can see it, is if support is added for "short term"
symmetric keys, that can be used for a limited period of time to
do "multiple encryption" rounds. This could then be used for other
things too, such as video/audio streams and session keys. Though at
that point, you're getting dangerously close to re-implementing IPsec,
so what I'd really like to see instead, is a "channel binding" of
OTR with IPsec (possible in IKEv2) where you setup an anonymous IPsec
tunnel between the two parties, and through that, do an OTR verification.
This then gives you a "secure end to end tunnel".
The danger of implementing these session keys, is that the policy to
the enduser becomes much more complicated, and you want to protect the
enduser from confusion. Most of them who are not CS students, already
find the three state "not private, "unverified", "private" confusing.
Paul
From klhrevolution@yahoo.com Wed Nov 21 07:26:44 2007
From: klhrevolution@yahoo.com (Ken Hensley)
Date: Tue, 20 Nov 2007 23:26:44 -0800 (PST)
Subject: [OTR-users] Off The Record: Instant Messaging
Message-ID: <126635.71637.qm@web45609.mail.sp1.yahoo.com>
Any chance that otr will be implementing it's features
into gajim http://www.gajim.org/ or possibly gnuyahoo:
http://gnuyahoo.sourceforge.net/
Thanks.
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
From blackest_knight@hotmail.com Sat Nov 24 13:09:30 2007
From: blackest_knight@hotmail.com (john owen-jones)
Date: Sat, 24 Nov 2007 13:09:30 +0000
Subject: [OTR-users] file transfer via OTR?
Message-ID:
Hi
Would it be possible to modify OTR for fle transfer.
through pidgin?
What I was thinking would be to drag and drop a file.
First it would be uuencoded to convert it to text.
encoded by OTR sent as chunks over the IM network
decoded by OTR to reassemble the uuencoded file
and then uudecoded to recreate the original file.
Possibly it could even work as a push system as long as
your logged on friends and colleagues would be able to
send you files direct to your desktop.
any thoughts
john
_________________________________________________________________
Get free emoticon packs and customisation from Windows Live.
http://www.pimpmylive.co.uk
From alex323@gmail.com Sat Nov 24 14:53:35 2007
From: alex323@gmail.com (Alex)
Date: Sat, 24 Nov 2007 09:53:35 -0500
Subject: [OTR-users] file transfer via OTR?
In-Reply-To:
References:
Message-ID: <20071124095335.40ecfbea@mx.google.com>
On Sat, 24 Nov 2007 13:09:30 +0000
john owen-jones wrote:
>
>
> Hi
> Would it be possible to modify OTR for fle transfer.
> through pidgin?
>
> What I was thinking would be to drag and drop a file.
>
> First it would be uuencoded to convert it to text.
> encoded by OTR sent as chunks over the IM network
> decoded by OTR to reassemble the uuencoded file
> and then uudecoded to recreate the original file.
>
> Possibly it could even work as a push system as long as
> your logged on friends and colleagues would be able to
> send you files direct to your desktop.
>
> any thoughts
>
Make sure it has MD5, RIPEMD150, and/or SHA512 verification to make sure
that the file is reassembled properly. Each chunk would need to be
verified and resent if decoding fails. This would require that the
traffic be two way as opposed to just a blind send in one direction.
Having communication in both directions would ensure that OTR is used
to the best of its abilities, and would ensure the integrity of the
file at the same time (for example, if there is a legit transmission
error).
I am not a fan of drag and drop. I would go more for a right-click menu
option that says "Send file".
--
Alex
From alex323@gmail.com Sat Nov 24 14:55:40 2007
From: alex323@gmail.com (Alex)
Date: Sat, 24 Nov 2007 09:55:40 -0500
Subject: [OTR-users] file transfer via OTR?
In-Reply-To: <20071124095335.40ecfbea@mx.google.com>
References:
<20071124095335.40ecfbea@mx.google.com>
Message-ID: <20071124095540.3d00476d@mx.google.com>
On Sat, 24 Nov 2007 09:53:35 -0500
Alex wrote:
> Make sure it has MD5, RIPEMD150, and/or SHA512 verification to make
> sure that the file is reassembled properly.
I did mean to say RIPEMD160.
--
Alex
From ian@cypherpunks.ca Sat Nov 24 20:05:10 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Sat, 24 Nov 2007 15:05:10 -0500
Subject: [OTR-users] Off The Record: Instant Messaging
In-Reply-To: <126635.71637.qm@web45609.mail.sp1.yahoo.com>
References: <126635.71637.qm@web45609.mail.sp1.yahoo.com>
Message-ID: <20071124200510.GD7500@yoink.cs.uwaterloo.ca>
On Tue, Nov 20, 2007 at 11:26:44PM -0800, Ken Hensley wrote:
> Any chance that otr will be implementing it's features
> into gajim http://www.gajim.org/ or possibly gnuyahoo:
> http://gnuyahoo.sourceforge.net/
OTR is a protocol; you'd have to ask the developers of those apps if
they'd be willing to support the OTR protocol. We'd of course love to
see more apps support OTR, and can provide integration assistance if
needed.
- Ian
From paul@cypherpunks.ca Sun Nov 25 03:17:29 2007
From: paul@cypherpunks.ca (Paul Wouters)
Date: Sat, 24 Nov 2007 22:17:29 -0500 (EST)
Subject: [OTR-users] file transfer via OTR?
In-Reply-To:
References:
Message-ID:
On Sat, 24 Nov 2007, john owen-jones wrote:
> Would it be possible to modify OTR for fle transfer.
> through pidgin?
Yes, but not like you think.
OTR uses a diffie hellman exchange every message. Your CPU
won't be able to do that for large streams (files, audio, video).
What needs to be done is that OTR negotiates a key for a symmetric
cipher (3des, aes, twofish), then uses that to encrypt the file,
and send it via the "regular" sendfile method.
Paul
From h.iverson@gmail.com Sun Nov 25 23:20:59 2007
From: h.iverson@gmail.com (Harlan Iverson)
Date: Sun, 25 Nov 2007 17:20:59 -0600
Subject: [OTR-users] new user, comments on authentication
Message-ID: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
------=_Part_3013_9656555.1196032859168
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
I am a new OTR user and have shared it with a few of my privacy conscious
friends. Overall, getting it going using Pidgin has been an extremely smooth
experience, but one hiccup has been explaining authentication. The two
people I use OTR with now are 'authenticated', but only in that we have
confirmed each others' keys (advanced > [I Have] ...); when I mentioned
authenticating using some secret that we both know, like the name of a place
that fits some description, they became confused. If privacy conscious
hackers don't understand without reading a lot of documentation, I think
there is a weakness in usability.
For my friends, they just 'knew' at the time that they were talking to me,
so authenticating using a shared secret was not something that they cared to
investigate further. Confirming the key was 'good enough' to make the icon
say "OTR: Private". If authentication were more streamlined and explained in
the GUI (smaller learning curve), chances are we would have used a shared
secret. It may seem like a pebkac issue, but really if the goal is to get
people to take full advantage of OTR it needs to be addressed.
My initial thoughts are to make sort of a wizard that runs each time OTR is
used with an unverified client. Prompt the person initiating the
conversation to enter some text that the other person can derive the shared
secret from, for example "The name of the place we spilled the iced tea all
over the waiter", and the receiver would then be prompted for the shared
secret when they receive the message. For usability sake, I also think it
would also be beneficial to give the option to ignore case/space/punctuation
in the answer (convert secret to lower case, eliminate spaces and
punctuation).
Thoughts?
------=_Part_3013_9656555.1196032859168
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hi,
I am a new OTR user and have shared it with a few of my privacy conscious friends. Overall, getting it going using Pidgin has been an extremely smooth experience, but one hiccup has been explaining authentication. The two people I use OTR with now are 'authenticated', but only in that we have confirmed each others' keys (advanced > [I Have] ...); when I mentioned authenticating using some secret that we both know, like the name of a place that fits some description, they became confused. If privacy conscious hackers don't understand without reading a lot of documentation, I think there is a weakness in usability.
For my friends, they just 'knew' at the time that they were talking to me, so authenticating using a shared secret was not something that they cared to investigate further. Confirming the key was 'good enough' to make the icon say "OTR: Private". If authentication were more streamlined and explained in the GUI (smaller learning curve), chances are we would have used a shared secret. It may seem like a pebkac issue, but really if the goal is to get people to take full advantage of OTR it needs to be addressed.
My initial thoughts are to make sort of a wizard that runs each time OTR is used with an unverified client. Prompt the person initiating the conversation to enter some text that the other person can derive the shared secret from, for example "The name of the place we spilled the iced tea all over the waiter", and the receiver would then be prompted for the shared secret when they receive the message. For usability sake, I also think it would also be beneficial to give the option to ignore case/space/punctuation in the answer (convert secret to lower case, eliminate spaces and punctuation).
Thoughts?
------=_Part_3013_9656555.1196032859168--
From gmaxwell@gmail.com Mon Nov 26 03:07:47 2007
From: gmaxwell@gmail.com (Gregory Maxwell)
Date: Sun, 25 Nov 2007 22:07:47 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
Message-ID:
On Nov 25, 2007 6:20 PM, Harlan Iverson wrote:
> Hi,
> I am a new OTR user and have shared it with a few of my privacy conscious
> friends. Overall, getting it going using Pidgin has been an extremely smooth
> experience, but one hiccup has been explaining authentication. The two
> people I use OTR with now are 'authenticated', but only in that we have
> confirmed each others' keys (advanced > [I Have] ...); when I mentioned
> authenticating using some secret that we both know, like the name of a place
> that fits some description, they became confused. If privacy conscious
> hackers don't understand without reading a lot of documentation, I think
> there is a weakness in usability.
Long time OTR user here. With the new authentication mode I took the
opportunity to get some more of my contacts using OTR. I found that,
as in the past, my contacts had no trouble with the general concept of
authentication but getting them to understand that the match is not
fuzzy and must be exact was hard. They all seemed to think that the
text in the dialog would be shown to me and that I would approve it.
ugh.
Perhaps changing the dialog so that it asks for a "passphrase" might
make it more clear that the spacing matters. If this results in
people being mislead into thinking the passphrase will be used to
encrypt their communication, then so be it. I think that would be
better than the current state.
It might also be worthwhile to explore including normalization, i.e.
case-folding and whitespace removal. That would reduce security, but
any secret which is weak after normalization was probably weak before
normalization.
All in all I'm happy to see this new authentication mode in OTR,
thought I would have preferred an alternative design
(http://lists.cypherpunks.ca/pipermail/otr-users/2006-March/000602.html,
I prefered the idea of using a strengthened additional shared secret
as an additional input to the symetric cipher to avoid DH weaknesses).
On the subject of OTR usability I still frequently suffer from the
"multiple client problem" with AIM users, where a user logs in
multiple OTR enabled clients and all respond to my OTR messages. This
especially problematic with the Mac contacts that I have who run OTR
without even knowing it. While it is really good that OTR is enabled
by default for these users, they get really confused when we run into
a multiple client issue.
This family of problems has resulted in a few of my contacts keeping
OTR disabled most of the time, so at least as far as my contact go
it's still a larger security problem than the authentication issue.
I also still run into cases where the OTR overhead makes hitting the
maximum message size in aim much easier, especially with HTML pastes.
It's not obvious to users that OTR is causing their suffering, so it
doesn't get turned off in response. I understand that the requirement
for blind forgability pretty much rules out compression (which is too
bad because algorithms like XML-WRT w/ dictionary do an amazing job
averaging 6.886 bits per char on my shortest messages and 3.2 bits per
char on my size-rejected IMs) ... but automatic message splitting
would be really nice. Even if you had to manually set the MTU.
From michael_reichenbach@freenet.de Mon Nov 26 15:11:50 2007
From: michael_reichenbach@freenet.de (Michael Reichenbach)
Date: Mon, 26 Nov 2007 16:11:50 +0100
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
Message-ID: <474AE236.4010104@freenet.de>
I did like the old way to authenticate. Go to plugin`s preferences and
check each others fingerprint, that way it`s really secure.
The new "secret" is quite confusing, yes. A "password" would make more
point, but however, I find it best to check the fingerprint.
From michael_reichenbach@freenet.de Mon Nov 26 15:24:32 2007
From: michael_reichenbach@freenet.de (Michael Reichenbach)
Date: Mon, 26 Nov 2007 16:24:32 +0100
Subject: [OTR-users] What we can expect in future? / file transfer via OTR?
In-Reply-To:
References:
Message-ID: <474AE530.9060900@freenet.de>
john owen-jones wrote
>
> Hi
> Would it be possible to modify OTR for fle transfer.
> through pidgin?
>
> What I was thinking would be to drag and drop a file.
>
> First it would be uuencoded to convert it to text.
> encoded by OTR sent as chunks over the IM network
> decoded by OTR to reassemble the uuencoded file
> and then uudecoded to recreate the original file.
>
> Possibly it could even work as a push system as long as
> your logged on friends and colleagues would be able to
> send you files direct to your desktop.
>
> any thoughts
>
> john
Imho OTR is a protocol and it`s in final version and no good idea to
change it because many clients implement it. We can`t expect the
developers from this project to add real new features, just improvements
for the security (if needed later), user support and an updated version
of their own implementation for pidgin. But the developers may give a
final verdict on this.
Sure I would love to use Pidgin also for encrypted and authenticated
file transfers. Because it does not have this feature yet we are
currently using some complicated setup with ftp over ssl. It does not
provide Deniability and Perfect forward secrecy but it`s better then no
encryption and authentication at all.
Because Deniability and Perfect forward secrecy are the main reasons for
OTR and them won`t work well with audio/video/filesend yet I think a
request for encrypted file transfers is out of scope the OTR project.
Some other project would be worth, anyone who has time may make it. :)
Would "just" need to "wrap" any Open Source server/client in a Pidgin
plugin. Any thoughts for a well designed protocol for file transfer? I
am thinking about something user friendly with nat-to-nat / proxy /
socks support. Ftp won`t work so well without open ports. Is there some
file transfer protocol where you can use free stun servers very well?
From gmaxwell@gmail.com Mon Nov 26 15:31:47 2007
From: gmaxwell@gmail.com (Gregory Maxwell)
Date: Mon, 26 Nov 2007 10:31:47 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <474AE236.4010104@freenet.de>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<474AE236.4010104@freenet.de>
Message-ID:
On Nov 26, 2007 10:11 AM, Michael Reichenbach
wrote:
> I did like the old way to authenticate. Go to plugin`s preferences and
> check each others fingerprint, that way it`s really secure.
>
> The new "secret" is quite confusing, yes. A "password" would make more
> point, but however, I find it best to check the fingerprint.
>From a security standpoint the new approach is quite solid:
Authentication will only succeed if both parties type in the same
'password'.
The password can not be brute forced, and later disclosure of the
password wouldn't harm your privacy (but it would make it possible for
someone to impersonate you if you continued to use the same password
with your contacts for future authentications).
You can still verify fingerprints if you want but fingerprints are
hard for people to verify. I've seen many people try to verify
fingerprints in OTR by simply typing them them into their OTR
sessions. :( Even a phone call is not MITM proof... but a shared
secret can be exchanged in advance.
My past somewhat negative comments on this approach were not intended
to claim that it isn't secure. Rather I was disappointed that OTR
wouldn't also use the shared secret to increase resistance to any
possible future DH weakness. However, if DH is found to be
substantially weaker than expected OTR will probably be the last of
our problems...
From gmaxwell@gmail.com Mon Nov 26 15:42:27 2007
From: gmaxwell@gmail.com (Gregory Maxwell)
Date: Mon, 26 Nov 2007 10:42:27 -0500
Subject: [OTR-users] What we can expect in future? / file transfer via OTR?
In-Reply-To: <474AE530.9060900@freenet.de>
References:
<474AE530.9060900@freenet.de>
Message-ID:
On Nov 26, 2007 10:24 AM, Michael Reichenbach
wrote:
[snip]
> Imho OTR is a protocol and it`s in final version and no good idea to
> change it because many clients implement it. We can`t expect the
> developers from this project to add real new features, just improvements
> for the security (if needed later), user support and an updated version
> of their own implementation for pidgin. But the developers may give a
> final verdict on this.
>
> Sure I would love to use Pidgin also for encrypted and authenticated
> file transfers. Because it does not have this feature yet we are
> currently using some complicated setup with ftp over ssl. It does not
> provide Deniability and Perfect forward secrecy but it`s better then no
> encryption and authentication at all.
It may be possible for OTR to help offer encrypted file transfer with
very little change to the protocol. Simply provide an interface in
OTR for OTR to send an empty message then return the encryption key
and mac key used for that message. The client would then encrypt the
file using those keys and send the file through the normal file
transfer means. The remote client could use the same keys.
Some work would need to be included to defer the release of that mac
key until the file was received... but we're not talking a complete
protocol overhaul.
Generally the ability for OTR to act as a person to person key
producer would be pretty useful. Especially now that it offers the
secure millionare based real-time authentication, which is a feature
not offered by anything else.
Sending files as in-band OTR messages, as was suggested, is pretty
much a non-starter: most IM systems rate limit messages.
From ian@cypherpunks.ca Mon Nov 26 23:23:17 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Mon, 26 Nov 2007 18:23:17 -0500
Subject: [OTR-users] What we can expect in future? / file transfer via OTR?
In-Reply-To:
References: <474AE530.9060900@freenet.de>
Message-ID: <20071126232317.GK7500@yoink.cs.uwaterloo.ca>
On Mon, Nov 26, 2007 at 10:42:27AM -0500, Gregory Maxwell wrote:
> On Nov 26, 2007 10:24 AM, Michael Reichenbach
> wrote:
> [snip]
> > Imho OTR is a protocol and it`s in final version and no good idea to
> > change it because many clients implement it.
In fact, it was built for extensibility, so adding a feature like this
wouldn't break anything.
> It may be possible for OTR to help offer encrypted file transfer with
> very little change to the protocol. Simply provide an interface in
> OTR for OTR to send an empty message then return the encryption key
> and mac key used for that message. The client would then encrypt the
> file using those keys and send the file through the normal file
> transfer means. The remote client could use the same keys.
>
> Some work would need to be included to defer the release of that mac
> key until the file was received... but we're not talking a complete
> protocol overhaul.
Indeed, adding a new TLV type which basically says "expect a file
transfer with this specified transfer cookie, to be encrypted and MACd
with keys derived from this message's encryption key" should be
sufficient.
> Generally the ability for OTR to act as a person to person key
> producer would be pretty useful. Especially now that it offers the
> secure millionare based real-time authentication, which is a feature
> not offered by anything else.
>
> Sending files as in-band OTR messages, as was suggested, is pretty
> much a non-starter: most IM systems rate limit messages.
For sure.
- Ian
From ian@cypherpunks.ca Mon Nov 26 23:35:42 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Mon, 26 Nov 2007 18:35:42 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
Message-ID: <20071126233542.GL7500@yoink.cs.uwaterloo.ca>
On Sun, Nov 25, 2007 at 05:20:59PM -0600, Harlan Iverson wrote:
> For my friends, they just 'knew' at the time that they were talking to me,
> so authenticating using a shared secret was not something that they cared to
> investigate further.
How could they possibly know this? Without doing some kind of
authentication (either the manual fingerprint check or the shared
secret), there's no way to distinguish a working OTR connection and one
that's going through a MITM (say, the automated OTR MITM plugin for
ejabberd: http://www.ejabberd.im/mod_otr ).
- Ian
From ian@cypherpunks.ca Mon Nov 26 23:36:37 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Mon, 26 Nov 2007 18:36:37 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To:
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
Message-ID: <20071126233637.GM7500@yoink.cs.uwaterloo.ca>
On Sun, Nov 25, 2007 at 10:07:47PM -0500, Gregory Maxwell wrote:
> I also still run into cases where the OTR overhead makes hitting the
> maximum message size in aim much easier, especially with HTML pastes.
> It's not obvious to users that OTR is causing their suffering, so it
> doesn't get turned off in response. I understand that the requirement
> for blind forgability pretty much rules out compression (which is too
> bad because algorithms like XML-WRT w/ dictionary do an amazing job
> averaging 6.886 bits per char on my shortest messages and 3.2 bits per
> char on my size-rejected IMs) ... but automatic message splitting
> would be really nice. Even if you had to manually set the MTU.
Are you still seeing this with 3.1? Automated message splitting is
indeed turned on in that version.
- Ian
From ian@cypherpunks.ca Mon Nov 26 23:38:32 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Mon, 26 Nov 2007 18:38:32 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <474AE236.4010104@freenet.de>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de>
Message-ID: <20071126233832.GN7500@yoink.cs.uwaterloo.ca>
On Mon, Nov 26, 2007 at 04:11:50PM +0100, Michael Reichenbach wrote:
> I did like the old way to authenticate. Go to plugin`s preferences and
> check each others fingerprint, that way it`s really secure.
>
> The new "secret" is quite confusing, yes. A "password" would make more
> point, but however, I find it best to check the fingerprint.
But most people have no clue what a fingerprint is. They have *some*
clue what a secret is. So I think we're better off.
That said, we're working on an actual user study of OTR right now.
- Ian
From ian@cypherpunks.ca Mon Nov 26 23:41:47 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Mon, 26 Nov 2007 18:41:47 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To:
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de>
Message-ID: <20071126234147.GO7500@yoink.cs.uwaterloo.ca>
On Mon, Nov 26, 2007 at 10:31:47AM -0500, Gregory Maxwell wrote:
> My past somewhat negative comments on this approach were not intended
> to claim that it isn't secure. Rather I was disappointed that OTR
> wouldn't also use the shared secret to increase resistance to any
> possible future DH weakness. However, if DH is found to be
> substantially weaker than expected OTR will probably be the last of
> our problems...
Indeed, if DH is weak, we're pretty much hosed all around. The other
problem is that requiring the shared secret to be entered before the
first DH was calculated would have been bad for UI, and prevented
agreement on the secret.
As for normalization: that's hard to do when you don't know what the
users will be entering. But the users can say (in-band) "that
restaurant we went to that time, all lowercase, no spaces".
- Ian
From perrin@apotheon.com Mon Nov 26 23:49:52 2007
From: perrin@apotheon.com (Chad Perrin)
Date: Mon, 26 Nov 2007 16:49:52 -0700
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <20071126233832.GN7500@yoink.cs.uwaterloo.ca>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126233832.GN7500@yoink.cs.uwaterloo.ca>
Message-ID: <20071126234952.GB35227@demeter.hydra>
On Mon, Nov 26, 2007 at 06:38:32PM -0500, Ian Goldberg wrote:
> On Mon, Nov 26, 2007 at 04:11:50PM +0100, Michael Reichenbach wrote:
> > I did like the old way to authenticate. Go to plugin`s preferences and
> > check each others fingerprint, that way it`s really secure.
> >
> > The new "secret" is quite confusing, yes. A "password" would make more
> > point, but however, I find it best to check the fingerprint.
>
> But most people have no clue what a fingerprint is. They have *some*
> clue what a secret is. So I think we're better off.
>
> That said, we're working on an actual user study of OTR right now.
Well . . . this user was pleasantly surprised by the inclusion of the
"shared secret" functionality. I've only used it with one person thus
far, but that made it a lot easier to authenticate with someone more than
1500 miles away than to contact him by telephone and use military
phonetic alphabet to verify "fingerprints". We briefly discussed the
idea of a shared secret, he said something about a fact nobody else would
have known, and boom -- we were authenticated.
If there's a "better" way to explain it so people more intuitively grasp
the concept, that's great. Go for it. I didn't have any touble with it
at all, and neither did my friend. For the sake of not wanting to screw
up, we just agreed to a particular letter case scheme, assuming it was
case sensitive. No confusion.
It's just one data point, but as far as I'm concerned it works.
--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Amazon.com interview candidate: "When C++ is your hammer, everything starts
to look like your thumb."
From h.iverson@gmail.com Tue Nov 27 01:47:36 2007
From: h.iverson@gmail.com (Harlan Iverson)
Date: Mon, 26 Nov 2007 19:47:36 -0600
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <20071126233542.GL7500@yoink.cs.uwaterloo.ca>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<20071126233542.GL7500@yoink.cs.uwaterloo.ca>
Message-ID: <25097ca30711261747q3f7cd8b3hddb25ea3a576594c@mail.gmail.com>
------=_Part_7949_11166147.1196128057030
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Ian,
We didn't 'know' for sure, hence the quotes. When you chat with a person
regularly you pick up on their grammar, slang usage, punctuation, etc. It's
not scientific, but it's certainly relevant to my experience with the
authentication process and I'll explain. They already 'know' they're talking
to me, and I already 'know' I'm talking to them based on those factors,
combined with the minuscule probability that we are targets of covert
surveillance or subject to a MITM attack. Others might not be so safe in
those assumptions.
You are correct that we certainly do not know with 100% certainty, and this
is the reason I would like authentication to be more accessible. As it
stands right now, authenticating properly feels like an extra, unnecessary
step because 1) There is the aforementioned assumption that the person is
who you think it is, and 2) the "OTR: Private" icon can easily be displayed
without going through that step, by blindly confirming the other party's
fingerprint. I realize in theory there is some chance that is not correct,
but the average user doesn't think that way. If a way can be found to make
it easier, why not explore it?
The conversations have all gone something like this:
Me: Hey, have you heard about Off The Record?
Them: No, what's that?
Me: [explanation of encryption, authentication, deniability, perfect forward
secrecy, link to website with gaim plugin]
Them: Cool [download and enable]
OTR Started, make sure to verify and authenticate
Me: Alright, lets authentication with the ____ of _____
Them: Alright, it says Private. cool
Me: Did you use the pass phrase?
Them: I don't know, but it says private.
Me: Did you get any kind of dialog or anything? It says it's waiting.
Them: It says it's private, so it must have worked.
Me: Here, I'll cancel it. Try going to Authenticate and typing in the answer
to that question
Them: I don't know, it says it's private though.
[by this time I'm feeling like a pain in the ass and drop it, because I have
my false sense of certainty that it's them anyway]
Nobody wants to feel like a pain in the ass, and by having felt that way
three times now it's seeming like a usability issue. I'm not trying to
insult your work or be a pebkac, I do honestly want to see *everyone *adopt
secure and private messaging. You can write it off as me and everyone I've
shared it with being clueless if you wish, I just thought I'd try to help
out.
Best regards,
Harlan
On Nov 26, 2007 5:35 PM, Ian Goldberg wrote:
> On Sun, Nov 25, 2007 at 05:20:59PM -0600, Harlan Iverson wrote:
> > For my friends, they just 'knew' at the time that they were talking to
> me,
> > so authenticating using a shared secret was not something that they
> cared to
> > investigate further.
>
> How could they possibly know this? Without doing some kind of
> authentication (either the manual fingerprint check or the shared
> secret), there's no way to distinguish a working OTR connection and one
> that's going through a MITM (say, the automated OTR MITM plugin for
> ejabberd: http://www.ejabberd.im/mod_otr ).
>
> - Ian
> _______________________________________________
> OTR-users mailing list
> OTR-users@lists.cypherpunks.ca
> http://lists.cypherpunks.ca/mailman/listinfo/otr-users
>
------=_Part_7949_11166147.1196128057030
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Ian,
We didn't 'know' for sure, hence the quotes. When you chat with a person regularly you pick up on their grammar, slang usage, punctuation, etc. It's not scientific, but it's certainly relevant to my experience with the authentication process and I'll explain. They already 'know' they're talking to me, and I already 'know' I'm talking to them based on those factors, combined with the minuscule probability that we are targets of covert surveillance or subject to a MITM attack. Others might not be so safe in those assumptions.
You are correct that we certainly do not know with 100% certainty, and this is the reason I would like authentication to be more accessible. As it stands right now, authenticating properly feels like an extra, unnecessary step because 1) There is the aforementioned assumption that the person is who you think it is, and 2) the "OTR: Private" icon can easily be displayed without going through that step, by blindly confirming the other party's fingerprint. I realize in theory there is some chance that is not correct, but the average user doesn't think that way. If a way can be found to make it easier, why not explore it?
The conversations have all gone something like this:
Me: Hey, have you heard about Off The Record?
Them: No, what's that?
Me: [explanation of encryption, authentication, deniability, perfect forward secrecy, link to website with gaim plugin]
Them: Cool [download and enable]
OTR Started, make sure to verify and authenticate
Me: Alright, lets authentication with the ____ of _____
Them: Alright, it says Private. cool
Me: Did you use the pass phrase?
Them: I don't know, but it says private.
Me: Did you get any kind of dialog or anything? It says it's waiting.
Them: It says it's private, so it must have worked.
Me: Here, I'll cancel it. Try going to Authenticate and typing in the answer to that question
Them: I don't know, it says it's private though.
[by this time I'm feeling like a pain in the ass and drop it, because I have my false sense of certainty that it's them anyway]
Nobody wants to feel like a pain in the ass, and by having felt that way three times now it's seeming like a usability issue. I'm not trying to insult your work or be a pebkac, I do honestly want
to see everyone adopt secure and private messaging. You can write it off as me and everyone I've shared it with being clueless if you wish, I just thought I'd try to help out.
Best regards,
Harlan
On Nov 26, 2007 5:35 PM, Ian Goldberg <
ian@cypherpunks.ca> wrote:
On Sun, Nov 25, 2007 at 05:20:59PM -0600, Harlan Iverson wrote:
> For my friends, they just 'knew' at the time that they were talking to me,
> so authenticating using a shared secret was not something that they cared to
> investigate further.
How could they possibly know this? Without doing some kind of
authentication (either the manual fingerprint check or the shared
secret), there's no way to distinguish a working OTR connection and one
that's going through a MITM (say, the automated OTR MITM plugin for
ejabberd: http://www.ejabberd.im/mod_otr ).
- Ian
------=_Part_7949_11166147.1196128057030--
From ian@cypherpunks.ca Tue Nov 27 02:15:26 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Mon, 26 Nov 2007 21:15:26 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <25097ca30711261747q3f7cd8b3hddb25ea3a576594c@mail.gmail.com>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <20071126233542.GL7500@yoink.cs.uwaterloo.ca> <25097ca30711261747q3f7cd8b3hddb25ea3a576594c@mail.gmail.com>
Message-ID: <20071127021526.GP7500@yoink.cs.uwaterloo.ca>
On Mon, Nov 26, 2007 at 07:47:36PM -0600, Harlan Iverson wrote:
> Ian,
>
> We didn't 'know' for sure, hence the quotes. When you chat with a person
> regularly you pick up on their grammar, slang usage, punctuation, etc. It's
> not scientific, but it's certainly relevant to my experience with the
> authentication process and I'll explain. They already 'know' they're talking
> to me, and I already 'know' I'm talking to them based on those factors,
> combined with the minuscule probability that we are targets of covert
> surveillance or subject to a MITM attack. Others might not be so safe in
> those assumptions.
But that's just it: with a MITM attack, you *really are* talking to your
friend. You'll get all the grammar, slang, etc. that you expect from
your friend. But the IM server operator is also logging your
supposedly private conversation.
> You are correct that we certainly do not know with 100% certainty, and this
> is the reason I would like authentication to be more accessible. As it
> stands right now, authenticating properly feels like an extra, unnecessary
> step because 1) There is the aforementioned assumption that the person is
> who you think it is, and 2) the "OTR: Private" icon can easily be displayed
> without going through that step, by blindly confirming the other party's
> fingerprint. I realize in theory there is some chance that is not correct,
> but the average user doesn't think that way. If a way can be found to make
> it easier, why not explore it?
Indeed, you're right. As I mentioned in another post, we're currently
doing user studies in order to see where the user issues with OTR are,
so we can improve them.
> The conversations have all gone something like this:
>
> Me: Hey, have you heard about Off The Record?
> Them: No, what's that?
> Me: [explanation of encryption, authentication, deniability, perfect forward
> secrecy, link to website with gaim plugin]
> Them: Cool [download and enable]
> OTR Started, make sure to verify and authenticate
> Me: Alright, lets authentication with the ____ of _____
> Them: Alright, it says Private. cool
If it says "Private" (as opposed to "Unverified"), then he must have
successfully authenticated. Unless he somehow found the
"Authenticate Buddy" > "Advanced" > "I have" sequence?
> Nobody wants to feel like a pain in the ass, and by having felt that way
> three times now it's seeming like a usability issue. I'm not trying to
> insult your work or be a pebkac, I do honestly want to see *everyone *adopt
> secure and private messaging. You can write it off as me and everyone I've
> shared it with being clueless if you wish, I just thought I'd try to help
> out.
We're really happy with your user reports, for sure! We also want to
see all messaging be secure and private. Ideally, it'll be that way by
default, and without the user even knowing it. [Of course, the user
won't be able to defend against MITM in that situation, but they'd be no
worse off than they are now.]
Thanks,
- Ian
From klhrevolution@yahoo.com Tue Nov 27 03:13:04 2007
From: klhrevolution@yahoo.com (Ken Hensley)
Date: Mon, 26 Nov 2007 19:13:04 -0800 (PST)
Subject: [OTR-users] another supported Messenger
Message-ID: <657271.64252.qm@web45613.mail.sp1.yahoo.com>
Yeah, in my quest to find a simple client I found that
mcabber supports OTR. and along with the server at
jabber.no I can use otr through jabber w/ otr!
http://www.lilotux.net/~mikael/mcabber/
little FYI not advertising...
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
From paul@cypherpunks.ca Tue Nov 27 16:55:46 2007
From: paul@cypherpunks.ca (Paul Wouters)
Date: Tue, 27 Nov 2007 11:55:46 -0500 (EST)
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <20071126234147.GO7500@yoink.cs.uwaterloo.ca>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<474AE236.4010104@freenet.de>
<20071126234147.GO7500@yoink.cs.uwaterloo.ca>
Message-ID:
On Mon, 26 Nov 2007, Ian Goldberg wrote:
> As for normalization: that's hard to do when you don't know what the
> users will be entering. But the users can say (in-band) "that
> restaurant we went to that time, all lowercase, no spaces".
That's opening a dangerous door. If you have geo tagged flickr
photos of that dinner that was memorable enough.
I found in general, people do not understand what a man in the middle
is. Numerous of my (not really dumb) friends, tend to believe that
you can do something like the above, but with the answer supplied
in-band as well.
I would much rather suggest the user to pick up the phone.
Paul
From paul@cypherpunks.ca Tue Nov 27 17:03:30 2007
From: paul@cypherpunks.ca (Paul Wouters)
Date: Tue, 27 Nov 2007 12:03:30 -0500 (EST)
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <20071126234952.GB35227@demeter.hydra>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<474AE236.4010104@freenet.de> <20071126233832.GN7500@yoink.cs.uwaterloo.ca>
<20071126234952.GB35227@demeter.hydra>
Message-ID:
On Mon, 26 Nov 2007, Chad Perrin wrote:
>
> Well . . . this user was pleasantly surprised by the inclusion of the
> "shared secret" functionality.
It's important to upgrade all clients though. We now run into the issue
where older clients cannot do this to newer clients, and it is even more
confusing to the enduser. (add to that we only do this new authentication
on pidgin, not gaim, and some distros are stuck with gaim)
Paul
From paul@cypherpunks.ca Tue Nov 27 17:40:46 2007
From: paul@cypherpunks.ca (Paul Wouters)
Date: Tue, 27 Nov 2007 12:40:46 -0500 (EST)
Subject: [OTR-users] another supported Messenger
In-Reply-To: <657271.64252.qm@web45613.mail.sp1.yahoo.com>
References: <657271.64252.qm@web45613.mail.sp1.yahoo.com>
Message-ID:
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323328-50082762-1196185246=:4497
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
On Mon, 26 Nov 2007, Ken Hensley wrote:
> http://www.lilotux.net/~mikael/mcabber/
I just tested it. OTR is not autodetected, you need to ./configure --enable-otr
then you need to add "set otr = 1" to your ~/.mcabberrc file and create the
directory ~/.mcabber/otr/
It failed to read my generated OTR key because my alias had spaces in them,
creating spaces in the filename, which didnt get handled properly.
(I mixed up login name with nick name)
After fiddling with a command line only client. I managed to invite myself and send
my other self an OTR request. However, I got:
11-27 12:27 --> test
│11-27 12:27 <== ?OTR?v2?
│ PaulWouters@jabber.org/Gaim has
│ requested an Off-the-Record private
│ conversation
│ . However,
│ you do not have a plugin to support
│ that.
│ See http://otr.cypherpunks.ca/ for more
│ information.
Trying to start OTR failed:
/otr smpr paulwouters@jabber.org mysecret
[12:34:39] /otr smpr [jid] secret
[12:34:39] Respond to the Initiation of the jid with the secret
[12:34:39] /otr smpa [jid]
[12:34:39] Abort the running Socialist Millionaires Protocol
[12:34:54] You have to start an OTR channel with paulwouters@jabber.org before you can use SMP.
It took me a little bit to figure out [jid] are not 3 options, but one (the jabber id)
I think some of the help text might also be scrolling out of my 4 line status window.
Man, command line cliens are hard :P
Paul
--8323328-50082762-1196185246=:4497--
From ian@cypherpunks.ca Wed Nov 28 16:42:43 2007
From: ian@cypherpunks.ca (Ian Goldberg)
Date: Wed, 28 Nov 2007 11:42:43 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To:
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <474AE236.4010104@freenet.de> <20071126234147.GO7500@yoink.cs.uwaterloo.ca>
Message-ID: <20071128164243.GM24383@thunk.cs.uwaterloo.ca>
On Tue, Nov 27, 2007 at 11:55:46AM -0500, Paul Wouters wrote:
> On Mon, 26 Nov 2007, Ian Goldberg wrote:
>
> > As for normalization: that's hard to do when you don't know what the
> > users will be entering. But the users can say (in-band) "that
> > restaurant we went to that time, all lowercase, no spaces".
>
> That's opening a dangerous door. If you have geo tagged flickr
> photos of that dinner that was memorable enough.
>
> I found in general, people do not understand what a man in the middle
> is. Numerous of my (not really dumb) friends, tend to believe that
> you can do something like the above, but with the answer supplied
> in-band as well.
>
> I would much rather suggest the user to pick up the phone.
I would much rather the users actually pick up the phone. But they
won't, and there's nothing we can do about that. So we need to provide
them a method that's at least plausible for them to use securely.
We're definitely open to ideas of ways to make it as easy to use
securely as possible.
- Ian
From gmaxwell@gmail.com Wed Nov 28 18:02:04 2007
From: gmaxwell@gmail.com (Gregory Maxwell)
Date: Wed, 28 Nov 2007 13:02:04 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <20071126234147.GO7500@yoink.cs.uwaterloo.ca>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<474AE236.4010104@freenet.de>
<20071126234147.GO7500@yoink.cs.uwaterloo.ca>
Message-ID:
On Nov 26, 2007 6:41 PM, Ian Goldberg wrote:
> Indeed, if DH is weak, we're pretty much hosed all around. The other
> problem is that requiring the shared secret to be entered before the
> first DH was calculated would have been bad for UI, and prevented
> agreement on the secret.
Eh, once the secret is agreed on (as it now does now, though perhaps
agreeing on a strengthened hash of the secret instead), compute
secretID=PBKDF2('id' +lowerfingerprint+upperfingerprint+ secret)
savedsecret=PBKDF2('otr'+lowerfingerprint+upperfingerprint+ secret)
save the savedsecret along with the remote parties fingerprint.
Now, for all future times DH is run, also exchange secret ID (in the
clear or with the encryption established the last time DH was run). If
both sides have matching secret IDs, they both XOR the savedsecret
into the DH derived key before using it.
Thus even if DH is weak, someone would need the secret or the
savedsecret from one of the computers to recover the messages.
Obviously the savedsecrets are a target for theft... but so are logs
and otr private keys. I'd really like it if my client could use the
gnome-keyring stuff to store an encryption key that protects my logs,
otr private keys, etc but thats outside of the scope of OTR.
Perhaps the additional DH weakness resistance is of too little value
to make this interesting, on the other hand it might be easier to
explain to people that they should authenticate so their conversations
are secured with a password than it is to explain that they should
authenticate to avoid MITM.
> As for normalization: that's hard to do when you don't know what the
> users will be entering. But the users can say (in-band) "that
> restaurant we went to that time, all lowercase, no spaces".
Eh, the software could still apply a default normalization with the
assumption that they are writing text. For example:
s/(\s\s+)/ /g //Fold all whitespace into a single space.
s/(^\s+)//g //Squash all leading whitespace.
S/(\s+$)//g //Squash all trailing whitespace.
Removing trailing punctuation, Folding case, Reducing repeated
characters to a single character.. all these might be reasonable.
Of course, doing this will lower the key entropy... but it would
mostly be reducing bad entropy that humans aren't likely to use. If
users keys differ by only these factors it's really really unlikely
that the users choose a really clever password like
"Thedogjumped" and
there is a MITM who is right except for the spaces, but it is really
likely that someone just mistyped something.
It could probably go as far as running double metaphone on every
contiguous span of five or more ascii characters and still not really
reduce security.
Paul Wouters wrote:
>> As for normalization: that's hard to do when you don't know what the
>> users will be entering. But the users can say (in-band) "that
>> restaurant we went to that time, all lowercase, no spaces".
>That's opening a dangerous door. If you have geo tagged flickr
>photos of that dinner that was memorable enough.
A MITM with the determination and resources to pull off monitoring the
conversation and conduct a quick real-time flickr search for the
involved parties, could probably find a pair of people to impersonate
the voices of the folks on the phone. The phone is probably better
than a weak secret, but probably not better than a strong one.
Ian Goldberg wrote:
On Sun, Nov 25, 2007 at 10:07:47PM -0500, Gregory Maxwell wrote:
>> I also still run into cases where the OTR overhead makes hitting the
>> maximum message size in aim much easier, especially with HTML pastes.
>Are you still seeing this with 3.1? Automated message splitting is
>indeed turned on in that version.
oh.. now that you mention it. Not on any 3.1 clients. THANKS!
Ian Goldberg wrote:
[snip]
> I would much rather the users actually pick up the phone. But they
> won't, and there's nothing we can do about that. So we need to provide
> them a method that's at least plausible for them to use securely.
> We're definitely open to ideas of ways to make it as easy to use
> securely as possible.
Bonus prize if you can invent a web-of-trust authentication system
that uses common members on the users buddy-list without disclosing a
users social network to the whole world... ;)
[snip]
> We also want to see all messaging be secure and private. Ideally, it'll be that way by
> default, and without the user even knowing it.
To really get there OTR needs to be included and enabled in quality
clients *by* *default*. Half my AIM contacts have OTR ... but this is
only because 1/4 are Mac users with a client that has OTR by default.
Asking windows contacts to switch clients is a tall request, but
pidgin has a lot of advantages over the default stuff. ... but to also
ask them to install OTR, oy.. thats starting to ask too much in some
cases.
From paul@cypherpunks.ca Wed Nov 28 20:39:28 2007
From: paul@cypherpunks.ca (Paul Wouters)
Date: Wed, 28 Nov 2007 15:39:28 -0500 (EST)
Subject: [OTR-users] new user, comments on authentication
In-Reply-To:
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<474AE236.4010104@freenet.de>
<20071126234147.GO7500@yoink.cs.uwaterloo.ca>
Message-ID:
On Wed, 28 Nov 2007, Gregory Maxwell wrote:
> Bonus prize if you can invent a web-of-trust authentication system
> that uses common members on the users buddy-list without disclosing a
> users social network to the whole world... ;)
And eternal fame if you can build in a reputation system too (user X always
clicks "verified" even if they didn't, but user H will always call before
verifying)
Paul
> To really get there OTR needs to be included and enabled in quality
> clients *by* *default*. Half my AIM contacts have OTR ... but this is
> only because 1/4 are Mac users with a client that has OTR by default.
> Asking windows contacts to switch clients is a tall request, but
> pidgin has a lot of advantages over the default stuff. ... but to also
> ask them to install OTR, oy.. thats starting to ask too much in some
> cases.
I think we are seeing a clear momentum grow. Without having hard
statistics, it seems that OTR is being used much more then other IM
encryptions. And broken alternatives like Scatterchat have died out.
A lot of opensource IM clients are using it, the closed source ones
will follow I think (in so far they have a large market left at all)
Paul
From gmaxwell@gmail.com Thu Nov 29 03:55:34 2007
From: gmaxwell@gmail.com (Gregory Maxwell)
Date: Wed, 28 Nov 2007 22:55:34 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <20071126233637.GM7500@yoink.cs.uwaterloo.ca>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<20071126233637.GM7500@yoink.cs.uwaterloo.ca>
Message-ID:
On Nov 26, 2007 6:36 PM, Ian Goldberg wrote:
> Are you still seeing this with 3.1? Automated message splitting is
> indeed turned on in that version.
After some more testing it seems that this isn't quite perfect .. at
least not with pidgin-2.2.2-1.fc8 and libotr-3.1.0-1.fc8 (in Fedora
8). Pastes of HTML IMs that span multiple messages lose their
HTMLness.
Still better than a rejection, but there is room for improvement. ;)
From michael_reichenbach@freenet.de Thu Nov 29 07:57:32 2007
From: michael_reichenbach@freenet.de (Michael Reichenbach)
Date: Thu, 29 Nov 2007 08:57:32 +0100
Subject: [OTR-users] new user, comments on authentication
In-Reply-To:
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com> <20071126233637.GM7500@yoink.cs.uwaterloo.ca>
Message-ID: <474E70EC.7020507@freenet.de>
1) Well, if the shared secret is weak against mitm (because of dh) then
you should drop it.
2) I think otr is about chatting secure with friends. In this case there
can be not trusted third party like a web of trust. With a web of trust
there is always the risk these days that some authority uses legal power
to compromise that system.
Web of trust can be only useful in commercial use (like ssl for
communicating with bank. A web of trust has a point in this situation,
but can be broken by authority with power over the web of trust / or
even more simply the bank).
3) As long checking the fingerprint is secure (even if there is an
active mitm from beginning from the first time for all times) I am happy.
4) This fingerprint needs to be checked either over a pre-secure channel
or in a real life meeting. While saying "pre-secure" channel we are also
back at complicated encryption and pgp.
Phone is not that good for checking fingerprint (ok, voice synthetic
attack is only in very little cases these days but it`s no real secure
solution).
I wish there would be a more easy solution, but I am afraid there isn`t.
5) The otr team did their job. Secure encryption between friends always
need confirmation anything (fingerprint or public key) within a meeting
in real life. Only if you suspect there are no logs / mitm for the first
time of communication, then also dh and trusting the fingeprint without
checking it might work but this is much less secure because you better
should not suspect that.
From gmaxwell@gmail.com Thu Nov 29 16:52:19 2007
From: gmaxwell@gmail.com (Gregory Maxwell)
Date: Thu, 29 Nov 2007 11:52:19 -0500
Subject: [OTR-users] new user, comments on authentication
In-Reply-To: <474E70EC.7020507@freenet.de>
References: <25097ca30711251520sf625ed5t8d3443f63f5dfd09@mail.gmail.com>
<20071126233637.GM7500@yoink.cs.uwaterloo.ca>
<474E70EC.7020507@freenet.de>
Message-ID:
On Nov 29, 2007 2:57 AM, Michael Reichenbach
wrote:
> 1) Well, if the shared secret is weak against mitm (because of dh) then
> you should drop it.
It's not. Thats the *whole point*. Shared secret is only weak against
MTIM if you give away the secret first: "lets authenticate, the
password is the type of pet you have cat or dog." or if the underlying
cryptographic construct turns out to be weak, which is a risk of the
same nearly unavoidable sort we get from using DH to build keys or
even AES to encrypt messages.
> 2) I think otr is about chatting secure with friends. In this case there
> can be not trusted third party like a web of trust. With a web of trust
> there is always the risk these days that some authority uses legal power
> to compromise that system.
>
> Web of trust can be only useful in commercial use (like ssl for
> communicating with bank. A web of trust has a point in this situation,
> but can be broken by authority with power over the web of trust / or
> even more simply the bank).
SSL certs are not web of trust.
(http://en.wikipedia.org/wiki/Web_of_trust#Contrast_with_typical_PKI)
By definition web of trust lacks a single party to turn. Web of trust
has other problems, unrelated to the points you've raised against
signing authorities.
> 3) As long checking the fingerprint is secure (even if there is an
> active mitm from beginning from the first time for all times) I am happy.
>
> 4) This fingerprint needs to be checked either over a pre-secure channel
> or in a real life meeting. While saying "pre-secure" channel we are also
> back at complicated encryption and pgp.
>
> Phone is not that good for checking fingerprint (ok, voice synthetic
> attack is only in very little cases these days but it`s no real secure
> solution).
Which is why virtually no one does it.
> I wish there would be a more easy solution, but I am afraid there isn`t.
There is. OTR includes it now. You can authenticate with a previously
established shared secret. Using the zero-knowledge socialist
millionaire protocol.
> 5) The otr team did their job. Secure encryption between friends always
> need confirmation anything (fingerprint or public key) within a meeting
> in real life.
Or a shared secret, which is easier for humans to work with...
From michael_reichenbach@freenet.de Fri Nov 30 17:08:26 2007
From: michael_reichenbach@freenet.de (Michael Reichenbach)
Date: Fri, 30 Nov 2007 18:08:26 +0100
Subject: [OTR-users] encryption on mobile phone?
Message-ID: <4750438A.30101@freenet.de>
I am interested in encrypting messages using some mobile phone. (using
messengers or sms/mms or internet)
Can you recommend any serious solutions in this environment?
From paul@cypherpunks.ca Fri Nov 30 19:58:43 2007
From: paul@cypherpunks.ca (Paul Wouters)
Date: Fri, 30 Nov 2007 14:58:43 -0500 (EST)
Subject: [OTR-users] encryption on mobile phone?
In-Reply-To: <4750438A.30101@freenet.de>
References: <4750438A.30101@freenet.de>
Message-ID:
On Fri, 30 Nov 2007, Michael Reichenbach wrote:
> I am interested in encrypting messages using some mobile phone. (using
> messengers or sms/mms or internet)
>
> Can you recommend any serious solutions in this environment?
I am still waiting for my Openmoko photo with GSM+Wifi. Then I will be
looking into porting OTR into whatever Openmoko's IM/SMS client is.
Paul
--
Building and integrating Virtual Private Networks with Openswan:
http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
From michael_reichenbach@freenet.de Fri Nov 30 20:05:47 2007
From: michael_reichenbach@freenet.de (Michael Reichenbach)
Date: Fri, 30 Nov 2007 21:05:47 +0100
Subject: [OTR-users] encryption on mobile phone?
In-Reply-To: <4750438A.30101@freenet.de>
References: <4750438A.30101@freenet.de>
Message-ID: <47506D1B.1010500@freenet.de>
I don`t think it`s needed until any 100% Open Source mobile device is done.
Afaik the most used common platform is java j2me, followed by symbian
C++, followed by windows mobile.
Are there any Open Source messengers out for any of this well used
platforms?
Also any Open Source solution which is packing sms / using internet (to
write longer messages for same money) are interesting for that.
From sven.lug-dorsten@gmx.de Fri Nov 30 22:28:44 2007
From: sven.lug-dorsten@gmx.de (Sven)
Date: Fri, 30 Nov 2007 23:28:44 +0100
Subject: [OTR-users] encryption on mobile phone?
In-Reply-To: <47506D1B.1010500@freenet.de>
References: <4750438A.30101@freenet.de> <47506D1B.1010500@freenet.de>
Message-ID: <1196461724.6375.5.camel@bluebox>
I use the Nokia N800. It has no GSM, but WLAN and Bluetooth. It runs a
debian-like system. Search for maemo if you want to dive into nokia's
open plattform.
It is shipped with a jabber messenger, which is the one i use at the
moment. There are pidgin packages available allready, but i dont think
otr is already available.
br, Sven