[jitsi-dev] otr4j integration with Jitsi


#1

Hello, George,

I think I'm missing something... Which method in OtrEngineHost is supposed
to init/start the SMP negotiation process?

I'm looking at the code right now and I'm seeing this method
net.java.otr4j.session.Session#initSmp(String question, String secret) but
I have no way of getting a Session object from the OtrEngineHost.

So how am I supposed to init the first step of the negotiation?

Regards,
Marin

···

On Wed, Oct 23, 2013 at 12:28 PM, Emil Ivov <emcho@jitsi.org> wrote:

Excellent! So, off to SMP then?

(we should have had this chat over the dev list :slight_smile: ... let's continue
there for future questions, ok?)

On Wed, Oct 23, 2013 at 11:23 AM, Marin Dzhigarov <marin@bluejimp.com> > wrote:
> Just an update,
>
> The integration of otr4j in Jitsi is done.
>
> Renaming all "org.spongycastle" imports to "org.bouncycastle" almost did
the
> trick.
> There was a problem, however, that otr4j had failing tests with
bouncycastle
> 1.49 (the version that we use in Jitsi).
>
> Following this topic:
> http://lists.jitsi.org/pipermail/dev/2013-April/004097.html I was able
to
> make it work.
>
> Regards,
> Marin
>
>
> On Wed, Oct 23, 2013 at 10:32 AM, George Politis <gp@superpointer.com> > > wrote:
>>
>> Well, it took me a while to remember it myself when we talked about it
>> in Strasbourg :slight_smile:
>>
>> On 10/23/2013 09:22 AM, Emil Ivov wrote:
>> > I think I might have misled you about the Android problem. As George
>> > said, the changes were made due to size concerns and then my brain
>> > somehow generated the Android story.
>> >
>> > --sent from my mobile
>> >
>> > On 23 Oct 2013 09:19, "Marin Dzhigarov" <marin@bluejimp.com > >> > <mailto:marin@bluejimp.com>> wrote:
>> >
>> > Thanks for the quick reply George!
>> >
>> > But wasn't 'spongycastle', If I recall correctly, a version of
>> > bouncycastle that is supposed to works on android devices?
>> >
>> > Did you created it?
>> >
>> >
>> >
>> > On Wed, Oct 23, 2013 at 10:04 AM, Emil Ivov <emcho@jitsi.org > >> > <mailto:emcho@jitsi.org>> wrote:
>> >
>> > Hey Marin,
>> >
>> > I remember that one of the problens was that OTR4J has a
>> > dependency on a modified version of bouncycastle (changed
>> > package names IIRC). We cannot continue using it because it
>> > conflicts Debian's policy. We need to use the vanilla version
>> > (the one that they ship in their repo).
>> >
>> > Emil
>> >
>> > --sent from my mobile
>> >
>> > On 23 Oct 2013 08:57, "Marin Dzhigarov" <marin@bluejimp.com > >> > <mailto:marin@bluejimp.com>> wrote:
>> >
>> > Hello, George,
>> >
>> > It is true that the methods signatures are very
descriptive.
>> > I was able to figure them out quite easily without (or at
>> > least very little) code browsing.
>> >
>> > I already integrated the newest version of otr4j in my
local
>> > Jitsi's repo so it's a matter of time to hit the smp part.
>> >
>> > If I have any questions I will seek your help.
>> >
>> > Regards,
>> > Marin
>> >
>> >
>> >
>> > On Tue, Oct 22, 2013 at 10:07 PM, George Politis > >> > <gp@superpointer.com <mailto:gp@superpointer.com>> wrote:
>> >
>> > Hello Emil, Marin,
>> >
>> > I'm sorry for the general answer, I couldn't guess
that
>> > Marin already
>> > has a good basis in OTR so I thought it might be
useful
>> > to give a very
>> > brief overview of the protocol. Anyway, I didn't want
to
>> > underestimate
>> > Marin's understanding of the OTR protocol
>> >
>> > AFAIK Gibberbot is known to support SMP and it uses
>> > otr4j, so I think it
>> > is safe to say that otr4j fully supports SMP. I
haven't
>> > personally
>> > reviewed the code.
>> >
>> > The new undocumented methods have a fairly descriptive
>> > name for someone
>> > that understands OTR and SMP. For example, when otr4j
>> > "wants/needs" to
>> > know the shared secret of a user (a step in the
>> > protocol), it calls the
>> > OtrEngineHost.askForSecret(session, secret) method. In
>> > that case, jitsi
>> > should display a dialog box to the user to type the
>> > shared secret.
>> >
>> > Another example, when otr4j detects an error in the
SMP
>> > exchange
>> > sequence, it calls the OtrEngineHost.smpError(session,
>> > tlvType, cheated)
>> > method. In that case jitsi should probably display an
>> > error box.
>> >
>> > Lastly, when otr4j detects that the remote and has
>> > aborted the SMP, it
>> > calls the OtrEngineHost.smpAborted(session) method. In
>> > that case, jitsi
>> > could probably display a message box to notify the
user
>> > that the remote
>> > end aborted the SMP.
>> >
>> > @Marin, please let me know if this answers your
>> > question. You can of
>> > course send me patches for review and validation.
>> >
>> > Cheers,
>> > George
>> >
>> > On 10/22/2013 05:33 PM, Emil Ivov wrote:
>> > > Thanks George,
>> > >
>> > > Actually I think Marin already has a good basis in
>> > OTR. He was mostly
>> > > interested in more otr4j related matters, like for
>> > example, what is the
>> > > level of support for SMP currently in there and
>> > potentially validating
>> > > some of his changes on the project before committing
>> > them.
>> > >
>> > > Marin, I'll let you continue with more specific
>> > questions.
>> > >
>> > > Emil
>> > >
>> > > On 19.10.13, 00:10, George Politis wrote:
>> > >> Hey Marin! I'd be glad to help you through this.
>> > >>
>> > >> It's true that the otr4j version included in jitsi
is
>> > a little outdated.
>> > >> The major difference between the version bundled
with
>> > Jitsi and the git
>> > >> tip is SMP support which has been contributed by
The
>> > Guardian Project.
>> > >>
>> > >> To put things into perspective, let's start with
this
>> > : OTR provides
>> > >> authentication, encryption, perfect forward secrecy
>> > and malleable
>> > >> encryption for instant messaging conversations. All
>> > those terms have a
>> > >> well defined and precise meaning. The Socialist
>> > Millionaires Protocol
>> > >> (SMP) deals with the authentication problem.
>> > >>
>> > >> Without SMP, Alice and Bob (two parties wishing to
>> > communicate) have to
>> > >> know each other’s public keys before the
>> > Authenticated Key Exchange
>> > >> (AKE) begins. If they do not, then Eve (the bad
guy,
>> > naturally) can
>> > >> pretend to be Bob and use her own key pair for
>> > signing, and Alice will
>> > >> have no way to spot the deception. This makes MITM
>> > attacks launched from
>> > >> a central IM server particularly effective. Not
good!
>> > >>
>> > >> To prevent this attack, each OTR user maintains a
>> > store of their
>> > >> buddies’ public keys. If a buddy starts a new
>> > conversation using a
>> > >> familiar public key, then OTR finds the match in
the
>> > store and
>> > >> authenticates automatically. If a match is not
found
>> > in the store, for
>> > >> example during the first conversation with a new
>> > buddy, the user is
>> > >> prompted to verify that the key is correct. In this
>> > case OTR displays
>> > >> the fingerprint (SHA-1 hash) of the unfamiliar key,
>> > and asks the user to
>> > >> verify its authenticity out-of-band. In otr4j based
>> > applications like
>> > >> jitsi, a class implementing the OtrKeyManager
>> > interface manages the key
>> > >> store.
>> > >>
>> > >> The problem with this method is that it is
difficult
>> > to use for an
>> > >> uninitiated user that does not know or care what a
>> > public
>> > >> key/fingerprint/etc is. Here's where SMP comes into
>> > play : SMP allows
>> > >> two parties with secret information x and y
>> > respectively to check
>> > >> whether (x==y) without revealing any additional
>> > information about the
>> > >> secrets!
>> > >>
>> > >> Practically this means that we can replace the
>> > regular authentication
>> > >> mechanism (the fingerprint verification popup) with
>> > an "Authenticate
>> > >> Buddy" dialog box where the user can type the
secret
>> > he shares with the
>> > >> other party. Here the user does not need to
>> > understand any cryptographic
>> > >> ideas; they need only to understand the idea of a
>> > secret or a password.
>> > >>
>> > >> I guess your job will be to update otr4j and expose
>> > the SMP
>> > >> functionality by modifying the "Authenticate Buddy"
>> > dialog in jitsi in
>> > >> order to expose the SMP functionality. To better
>> > understand how OTR
>> > >> works and how SMP improves things you could first
>> > code a small/simple
>> > >> Java program that emulates a private conversation.
>> > Or, if you feel
>> > >> comfortable with the Jitsi testing infrastructure,
>> > you can work directly
>> > >> in Jitsi and create some test cases there.
>> > >>
>> > >> I hope this helps a bit.
>> > >>
>> > >> Cheers,
>> > >> George
>> > >>
>> > >> On 10/18/2013 02:17 PM, Marin Dzhigarov wrote:
>> > >>> Hello, George,
>> > >>>
>> > >>> It's pleasure the meet you!
>> > >>>
>> > >>> I'll be glad if you could help me at improving the
>> > OTR support for
>> > >>> Jitsi.
>> > >>>
>> > >>> Since you are the author of the otr4j I might have
>> > some questions for
>> > >>> you in the next couple of weeks.
>> > >>>
>> > >>>
>> > >>> I will start with integrating the newest version
of
>> > otr4j with our
>> > >>> source. Our current version of the jar is located
>> > here
>> > >>>
>> > <
https://github.com/jitsi/libsrc/blob/master/otr4j.zip>
>> > and as you can
>> > >>> see - it's quite old. Also, the docu here
>> > >>> <https://code.google.com/p/otr4j/wiki/QuickStart>
is
>> > not very helpful as
>> > >>> it has not been updated recently.
>> > >>> I'm browsing the github repo right now and I'm
>> > seeing some changes and a
>> > >>> lot of new methods in the OtrEngineHost interface
>> > that are not
>> > >>> documented in the code.
>> > >>> So I was wondering if you could give me any
>> > directions on what these new
>> > >>> methods do and how/why me and my team should
>> > implement them in Jitsi.
>> > >>>
>> > >>>
>> > >>> Another thing is the SMP support. Could you please
>> > give me a brief
>> > >>> explanation on where are we right now regarding
>> > otr4j SMP support and
>> > >>> what should be done in the future?
>> > >>>
>> > >>> Well... I think this is all I need to know for
now.
>> > >>>
>> > >>> I'm looking forward from working with you!
>> > >>>
>> > >>> Regards,
>> > >>> Marin
>> > >>>
>> > >>
>> > >
>> >
>> >
>> >
>
>

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#2

Hey Marin,

The OtrEngineHost is used to expose the host application to otr4j and
the OtrEngine interface is used to expose otr4j functionality to the
host application. When the host needs to decrypt/encrypt a message,
initiate SMP, get the session status, etc., it should call the
appropriate method from the OtrEngine interface.

Now, say for example you wish to transform an outgoing message M for
contact C. I just expressed that in "jitsish" (jitsi's language). otr4j
doesn't speak jitsi's language, so you have to translate jitsish to
otr4jish.

Technically speaking, you need to find the sessionId associated with
contact C and then call the OtrEngine.transformSending(sessionId, msg)
method to transform the message using the sessionId you just found. As
you can imagine, the procedure is more or less similar when you wish to
transform an incoming message, initiate SMP (to be done), etc.

To avoid code duplication and improve maintainability jitsi has an
"entity" (an interface + its implementation) called ScOtrEngine which is
nothing more than an OtrEngine wrapper that "speaks jitsi's language".

In there you'll find methods such as transformSending(contact, msg).
Notice the difference in the method signature with the transformSending
method in the OtrEngine interface. You will also find many examples that
show how to use the OtrEngine interface (including getting the session
object for a given contact). There's where you should put your
initSmp(contact) method.

I hope this helps.

Cheers,
George

···

On 10/23/2013 02:20 PM, Marin Dzhigarov wrote:

Hello, George,

I think I'm missing something... Which method in OtrEngineHost is
supposed to init/start the SMP negotiation process?

I'm looking at the code right now and I'm seeing this method
net.java.otr4j.session.Session#initSmp(String question, String secret)
but I have no way of getting a Session object from the OtrEngineHost.

So how am I supposed to init the first step of the negotiation?

Regards,
Marin

On Wed, Oct 23, 2013 at 12:28 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    Excellent! So, off to SMP then?

    (we should have had this chat over the dev list :slight_smile: ... let's continue
    there for future questions, ok?)

    On Wed, Oct 23, 2013 at 11:23 AM, Marin Dzhigarov > <marin@bluejimp.com <mailto:marin@bluejimp.com>> wrote:
    > Just an update,
    >
    > The integration of otr4j in Jitsi is done.
    >
    > Renaming all "org.spongycastle" imports to "org.bouncycastle"
    almost did the
    > trick.
    > There was a problem, however, that otr4j had failing tests with
    bouncycastle
    > 1.49 (the version that we use in Jitsi).
    >
    > Following this topic:
    > http://lists.jitsi.org/pipermail/dev/2013-April/004097.html I was
    able to
    > make it work.
    >
    > Regards,
    > Marin
    >
    >
    > On Wed, Oct 23, 2013 at 10:32 AM, George Politis > <gp@superpointer.com <mailto:gp@superpointer.com>> > > wrote:
    >>
    >> Well, it took me a while to remember it myself when we talked
    about it
    >> in Strasbourg :slight_smile:
    >>
    >> On 10/23/2013 09:22 AM, Emil Ivov wrote:
    >> > I think I might have misled you about the Android problem. As
    George
    >> > said, the changes were made due to size concerns and then my brain
    >> > somehow generated the Android story.
    >> >
    >> > --sent from my mobile
    >> >
    >> > On 23 Oct 2013 09:19, "Marin Dzhigarov" <marin@bluejimp.com > <mailto:marin@bluejimp.com> > >> > <mailto:marin@bluejimp.com <mailto:marin@bluejimp.com>>> wrote:
    >> >
    >> > Thanks for the quick reply George!
    >> >
    >> > But wasn't 'spongycastle', If I recall correctly, a version of
    >> > bouncycastle that is supposed to works on android devices?
    >> >
    >> > Did you created it?
    >> >
    >> >
    >> >
    >> > On Wed, Oct 23, 2013 at 10:04 AM, Emil Ivov > <emcho@jitsi.org <mailto:emcho@jitsi.org> > >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
    >> >
    >> > Hey Marin,
    >> >
    >> > I remember that one of the problens was that OTR4J has a
    >> > dependency on a modified version of bouncycastle (changed
    >> > package names IIRC). We cannot continue using it because it
    >> > conflicts Debian's policy. We need to use the vanilla
    version
    >> > (the one that they ship in their repo).
    >> >
    >> > Emil
    >> >
    >> > --sent from my mobile
    >> >
    >> > On 23 Oct 2013 08:57, "Marin Dzhigarov" > <marin@bluejimp.com <mailto:marin@bluejimp.com> > >> > <mailto:marin@bluejimp.com > <mailto:marin@bluejimp.com>>> wrote:
    >> >
    >> > Hello, George,
    >> >
    >> > It is true that the methods signatures are very
    descriptive.
    >> > I was able to figure them out quite easily without
    (or at
    >> > least very little) code browsing.
    >> >
    >> > I already integrated the newest version of otr4j in
    my local
    >> > Jitsi's repo so it's a matter of time to hit the
    smp part.
    >> >
    >> > If I have any questions I will seek your help.
    >> >
    >> > Regards,
    >> > Marin
    >> >
    >> >
    >> >
    >> > On Tue, Oct 22, 2013 at 10:07 PM, George Politis > >> > <gp@superpointer.com <mailto:gp@superpointer.com> > <mailto:gp@superpointer.com <mailto:gp@superpointer.com>>> wrote:
    >> >
    >> > Hello Emil, Marin,
    >> >
    >> > I'm sorry for the general answer, I couldn't
    guess that
    >> > Marin already
    >> > has a good basis in OTR so I thought it might
    be useful
    >> > to give a very
    >> > brief overview of the protocol. Anyway, I
    didn't want to
    >> > underestimate
    >> > Marin's understanding of the OTR protocol
    >> >
    >> > AFAIK Gibberbot is known to support SMP and it uses
    >> > otr4j, so I think it
    >> > is safe to say that otr4j fully supports SMP. I
    haven't
    >> > personally
    >> > reviewed the code.
    >> >
    >> > The new undocumented methods have a fairly
    descriptive
    >> > name for someone
    >> > that understands OTR and SMP. For example, when
    otr4j
    >> > "wants/needs" to
    >> > know the shared secret of a user (a step in the
    >> > protocol), it calls the
    >> > OtrEngineHost.askForSecret(session, secret)
    method. In
    >> > that case, jitsi
    >> > should display a dialog box to the user to type the
    >> > shared secret.
    >> >
    >> > Another example, when otr4j detects an error in
    the SMP
    >> > exchange
    >> > sequence, it calls the
    OtrEngineHost.smpError(session,
    >> > tlvType, cheated)
    >> > method. In that case jitsi should probably
    display an
    >> > error box.
    >> >
    >> > Lastly, when otr4j detects that the remote and has
    >> > aborted the SMP, it
    >> > calls the OtrEngineHost.smpAborted(session)
    method. In
    >> > that case, jitsi
    >> > could probably display a message box to notify
    the user
    >> > that the remote
    >> > end aborted the SMP.
    >> >
    >> > @Marin, please let me know if this answers your
    >> > question. You can of
    >> > course send me patches for review and validation.
    >> >
    >> > Cheers,
    >> > George
    >> >
    >> > On 10/22/2013 05:33 PM, Emil Ivov wrote:
    >> > > Thanks George,
    >> > >
    >> > > Actually I think Marin already has a good
    basis in
    >> > OTR. He was mostly
    >> > > interested in more otr4j related matters,
    like for
    >> > example, what is the
    >> > > level of support for SMP currently in there and
    >> > potentially validating
    >> > > some of his changes on the project before
    committing
    >> > them.
    >> > >
    >> > > Marin, I'll let you continue with more specific
    >> > questions.
    >> > >
    >> > > Emil
    >> > >
    >> > > On 19.10.13, 00:10, George Politis wrote:
    >> > >> Hey Marin! I'd be glad to help you through this.
    >> > >>
    >> > >> It's true that the otr4j version included in
    jitsi is
    >> > a little outdated.
    >> > >> The major difference between the version
    bundled with
    >> > Jitsi and the git
    >> > >> tip is SMP support which has been
    contributed by The
    >> > Guardian Project.
    >> > >>
    >> > >> To put things into perspective, let's start
    with this
    >> > : OTR provides
    >> > >> authentication, encryption, perfect forward
    secrecy
    >> > and malleable
    >> > >> encryption for instant messaging
    conversations. All
    >> > those terms have a
    >> > >> well defined and precise meaning. The Socialist
    >> > Millionaires Protocol
    >> > >> (SMP) deals with the authentication problem.
    >> > >>
    >> > >> Without SMP, Alice and Bob (two parties
    wishing to
    >> > communicate) have to
    >> > >> know each other�s public keys before the
    >> > Authenticated Key Exchange
    >> > >> (AKE) begins. If they do not, then Eve (the
    bad guy,
    >> > naturally) can
    >> > >> pretend to be Bob and use her own key pair for
    >> > signing, and Alice will
    >> > >> have no way to spot the deception. This
    makes MITM
    >> > attacks launched from
    >> > >> a central IM server particularly effective.
    Not good!
    >> > >>
    >> > >> To prevent this attack, each OTR user
    maintains a
    >> > store of their
    >> > >> buddies� public keys. If a buddy starts a new
    >> > conversation using a
    >> > >> familiar public key, then OTR finds the
    match in the
    >> > store and
    >> > >> authenticates automatically. If a match is
    not found
    >> > in the store, for
    >> > >> example during the first conversation with a new
    >> > buddy, the user is
    >> > >> prompted to verify that the key is correct.
    In this
    >> > case OTR displays
    >> > >> the fingerprint (SHA-1 hash) of the
    unfamiliar key,
    >> > and asks the user to
    >> > >> verify its authenticity out-of-band. In
    otr4j based
    >> > applications like
    >> > >> jitsi, a class implementing the OtrKeyManager
    >> > interface manages the key
    >> > >> store.
    >> > >>
    >> > >> The problem with this method is that it is
    difficult
    >> > to use for an
    >> > >> uninitiated user that does not know or care
    what a
    >> > public
    >> > >> key/fingerprint/etc is. Here's where SMP
    comes into
    >> > play : SMP allows
    >> > >> two parties with secret information x and y
    >> > respectively to check
    >> > >> whether (x==y) without revealing any additional
    >> > information about the
    >> > >> secrets!
    >> > >>
    >> > >> Practically this means that we can replace the
    >> > regular authentication
    >> > >> mechanism (the fingerprint verification
    popup) with
    >> > an "Authenticate
    >> > >> Buddy" dialog box where the user can type
    the secret
    >> > he shares with the
    >> > >> other party. Here the user does not need to
    >> > understand any cryptographic
    >> > >> ideas; they need only to understand the idea
    of a
    >> > secret or a password.
    >> > >>
    >> > >> I guess your job will be to update otr4j and
    expose
    >> > the SMP
    >> > >> functionality by modifying the "Authenticate
    Buddy"
    >> > dialog in jitsi in
    >> > >> order to expose the SMP functionality. To better
    >> > understand how OTR
    >> > >> works and how SMP improves things you could
    first
    >> > code a small/simple
    >> > >> Java program that emulates a private
    conversation.
    >> > Or, if you feel
    >> > >> comfortable with the Jitsi testing
    infrastructure,
    >> > you can work directly
    >> > >> in Jitsi and create some test cases there.
    >> > >>
    >> > >> I hope this helps a bit.
    >> > >>
    >> > >> Cheers,
    >> > >> George
    >> > >>
    >> > >> On 10/18/2013 02:17 PM, Marin Dzhigarov wrote:
    >> > >>> Hello, George,
    >> > >>>
    >> > >>> It's pleasure the meet you!
    >> > >>>
    >> > >>> I'll be glad if you could help me at
    improving the
    >> > OTR support for
    >> > >>> Jitsi.
    >> > >>>
    >> > >>> Since you are the author of the otr4j I
    might have
    >> > some questions for
    >> > >>> you in the next couple of weeks.
    >> > >>>
    >> > >>>
    >> > >>> I will start with integrating the newest
    version of
    >> > otr4j with our
    >> > >>> source. Our current version of the jar is
    located
    >> > here
    >> > >>>
    >> >
    <https://github.com/jitsi/libsrc/blob/master/otr4j.zip>
    >> > and as you can
    >> > >>> see - it's quite old. Also, the docu here
    >> > >>>
    <https://code.google.com/p/otr4j/wiki/QuickStart> is
    >> > not very helpful as
    >> > >>> it has not been updated recently.
    >> > >>> I'm browsing the github repo right now and I'm
    >> > seeing some changes and a
    >> > >>> lot of new methods in the OtrEngineHost
    interface
    >> > that are not
    >> > >>> documented in the code.
    >> > >>> So I was wondering if you could give me any
    >> > directions on what these new
    >> > >>> methods do and how/why me and my team should
    >> > implement them in Jitsi.
    >> > >>>
    >> > >>>
    >> > >>> Another thing is the SMP support. Could you
    please
    >> > give me a brief
    >> > >>> explanation on where are we right now regarding
    >> > otr4j SMP support and
    >> > >>> what should be done in the future?
    >> > >>>
    >> > >>> Well... I think this is all I need to know
    for now.
    >> > >>>
    >> > >>> I'm looking forward from working with you!
    >> > >>>
    >> > >>> Regards,
    >> > >>> Marin
    >> > >>>
    >> > >>
    >> > >
    >> >
    >> >
    >> >
    >
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    Jitsi
    emcho@jitsi.org <mailto:emcho@jitsi.org>
     PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
    https://jitsi.org FAX: +33.1.77.62.47.31
    <tel:%2B33.1.77.62.47.31>


#3

Hey Marin,

The OtrEngineHost is used to expose the host application to otr4j and
the OtrEngine interface is used to expose otr4j functionality to the
host application. When the host needs to decrypt/encrypt a message,
initiate SMP, get the session status, etc., it should call the
appropriate method from the OtrEngine interface.

Now, say for example you wish to transform an outgoing message M for
contact C. I just expressed that in "jitsish" (jitsi's language). otr4j
doesn't speak jitsi's language, so you have to translate jitsish to
otr4jish.

Technically speaking, you need to find the sessionId associated with
contact C and then call the OtrEngine.transformSending(sessionId, msg)
method to transform the message using the sessionId you just found. As
you can imagine, the procedure is more or less similar when you wish to
transform an incoming message, initiate SMP (to be done), etc.

To avoid code duplication and improve maintainability jitsi has an
"entity" (an interface + its implementation) called ScOtrEngine which is
nothing more than an OtrEngine wrapper that "speaks jitsi's language".

In there you'll find methods such as transformSending(contact, msg).
Notice the difference in the method signature with the transformSending
method in the OtrEngine interface. You will also find many examples that
show how to use the OtrEngine interface (including getting the session
object for a given contact). There's where you should put your
initSmp(contact) method.

I hope this helps.

Cheers,
George

···

On 10/23/2013 02:20 PM, Marin Dzhigarov wrote:

Hello, George,

I think I'm missing something... Which method in OtrEngineHost is
supposed to init/start the SMP negotiation process?

I'm looking at the code right now and I'm seeing this method
net.java.otr4j.session.Session#initSmp(String question, String secret)
but I have no way of getting a Session object from the OtrEngineHost.

So how am I supposed to init the first step of the negotiation?

Regards,
Marin

On Wed, Oct 23, 2013 at 12:28 PM, Emil Ivov <emcho@jitsi.org > <mailto:emcho@jitsi.org>> wrote:

    Excellent! So, off to SMP then?

    (we should have had this chat over the dev list :slight_smile: ... let's continue
    there for future questions, ok?)

    On Wed, Oct 23, 2013 at 11:23 AM, Marin Dzhigarov > <marin@bluejimp.com <mailto:marin@bluejimp.com>> wrote:
    > Just an update,
    >
    > The integration of otr4j in Jitsi is done.
    >
    > Renaming all "org.spongycastle" imports to "org.bouncycastle"
    almost did the
    > trick.
    > There was a problem, however, that otr4j had failing tests with
    bouncycastle
    > 1.49 (the version that we use in Jitsi).
    >
    > Following this topic:
    > http://lists.jitsi.org/pipermail/dev/2013-April/004097.html I was
    able to
    > make it work.
    >
    > Regards,
    > Marin
    >
    >
    > On Wed, Oct 23, 2013 at 10:32 AM, George Politis > <gp@superpointer.com <mailto:gp@superpointer.com>> > > wrote:
    >>
    >> Well, it took me a while to remember it myself when we talked
    about it
    >> in Strasbourg :slight_smile:
    >>
    >> On 10/23/2013 09:22 AM, Emil Ivov wrote:
    >> > I think I might have misled you about the Android problem. As
    George
    >> > said, the changes were made due to size concerns and then my brain
    >> > somehow generated the Android story.
    >> >
    >> > --sent from my mobile
    >> >
    >> > On 23 Oct 2013 09:19, "Marin Dzhigarov" <marin@bluejimp.com > <mailto:marin@bluejimp.com> > >> > <mailto:marin@bluejimp.com <mailto:marin@bluejimp.com>>> wrote:
    >> >
    >> > Thanks for the quick reply George!
    >> >
    >> > But wasn't 'spongycastle', If I recall correctly, a version of
    >> > bouncycastle that is supposed to works on android devices?
    >> >
    >> > Did you created it?
    >> >
    >> >
    >> >
    >> > On Wed, Oct 23, 2013 at 10:04 AM, Emil Ivov > <emcho@jitsi.org <mailto:emcho@jitsi.org> > >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
    >> >
    >> > Hey Marin,
    >> >
    >> > I remember that one of the problens was that OTR4J has a
    >> > dependency on a modified version of bouncycastle (changed
    >> > package names IIRC). We cannot continue using it because it
    >> > conflicts Debian's policy. We need to use the vanilla
    version
    >> > (the one that they ship in their repo).
    >> >
    >> > Emil
    >> >
    >> > --sent from my mobile
    >> >
    >> > On 23 Oct 2013 08:57, "Marin Dzhigarov" > <marin@bluejimp.com <mailto:marin@bluejimp.com> > >> > <mailto:marin@bluejimp.com > <mailto:marin@bluejimp.com>>> wrote:
    >> >
    >> > Hello, George,
    >> >
    >> > It is true that the methods signatures are very
    descriptive.
    >> > I was able to figure them out quite easily without
    (or at
    >> > least very little) code browsing.
    >> >
    >> > I already integrated the newest version of otr4j in
    my local
    >> > Jitsi's repo so it's a matter of time to hit the
    smp part.
    >> >
    >> > If I have any questions I will seek your help.
    >> >
    >> > Regards,
    >> > Marin
    >> >
    >> >
    >> >
    >> > On Tue, Oct 22, 2013 at 10:07 PM, George Politis > >> > <gp@superpointer.com <mailto:gp@superpointer.com> > <mailto:gp@superpointer.com <mailto:gp@superpointer.com>>> wrote:
    >> >
    >> > Hello Emil, Marin,
    >> >
    >> > I'm sorry for the general answer, I couldn't
    guess that
    >> > Marin already
    >> > has a good basis in OTR so I thought it might
    be useful
    >> > to give a very
    >> > brief overview of the protocol. Anyway, I
    didn't want to
    >> > underestimate
    >> > Marin's understanding of the OTR protocol
    >> >
    >> > AFAIK Gibberbot is known to support SMP and it uses
    >> > otr4j, so I think it
    >> > is safe to say that otr4j fully supports SMP. I
    haven't
    >> > personally
    >> > reviewed the code.
    >> >
    >> > The new undocumented methods have a fairly
    descriptive
    >> > name for someone
    >> > that understands OTR and SMP. For example, when
    otr4j
    >> > "wants/needs" to
    >> > know the shared secret of a user (a step in the
    >> > protocol), it calls the
    >> > OtrEngineHost.askForSecret(session, secret)
    method. In
    >> > that case, jitsi
    >> > should display a dialog box to the user to type the
    >> > shared secret.
    >> >
    >> > Another example, when otr4j detects an error in
    the SMP
    >> > exchange
    >> > sequence, it calls the
    OtrEngineHost.smpError(session,
    >> > tlvType, cheated)
    >> > method. In that case jitsi should probably
    display an
    >> > error box.
    >> >
    >> > Lastly, when otr4j detects that the remote and has
    >> > aborted the SMP, it
    >> > calls the OtrEngineHost.smpAborted(session)
    method. In
    >> > that case, jitsi
    >> > could probably display a message box to notify
    the user
    >> > that the remote
    >> > end aborted the SMP.
    >> >
    >> > @Marin, please let me know if this answers your
    >> > question. You can of
    >> > course send me patches for review and validation.
    >> >
    >> > Cheers,
    >> > George
    >> >
    >> > On 10/22/2013 05:33 PM, Emil Ivov wrote:
    >> > > Thanks George,
    >> > >
    >> > > Actually I think Marin already has a good
    basis in
    >> > OTR. He was mostly
    >> > > interested in more otr4j related matters,
    like for
    >> > example, what is the
    >> > > level of support for SMP currently in there and
    >> > potentially validating
    >> > > some of his changes on the project before
    committing
    >> > them.
    >> > >
    >> > > Marin, I'll let you continue with more specific
    >> > questions.
    >> > >
    >> > > Emil
    >> > >
    >> > > On 19.10.13, 00:10, George Politis wrote:
    >> > >> Hey Marin! I'd be glad to help you through this.
    >> > >>
    >> > >> It's true that the otr4j version included in
    jitsi is
    >> > a little outdated.
    >> > >> The major difference between the version
    bundled with
    >> > Jitsi and the git
    >> > >> tip is SMP support which has been
    contributed by The
    >> > Guardian Project.
    >> > >>
    >> > >> To put things into perspective, let's start
    with this
    >> > : OTR provides
    >> > >> authentication, encryption, perfect forward
    secrecy
    >> > and malleable
    >> > >> encryption for instant messaging
    conversations. All
    >> > those terms have a
    >> > >> well defined and precise meaning. The Socialist
    >> > Millionaires Protocol
    >> > >> (SMP) deals with the authentication problem.
    >> > >>
    >> > >> Without SMP, Alice and Bob (two parties
    wishing to
    >> > communicate) have to
    >> > >> know each other�s public keys before the
    >> > Authenticated Key Exchange
    >> > >> (AKE) begins. If they do not, then Eve (the
    bad guy,
    >> > naturally) can
    >> > >> pretend to be Bob and use her own key pair for
    >> > signing, and Alice will
    >> > >> have no way to spot the deception. This
    makes MITM
    >> > attacks launched from
    >> > >> a central IM server particularly effective.
    Not good!
    >> > >>
    >> > >> To prevent this attack, each OTR user
    maintains a
    >> > store of their
    >> > >> buddies� public keys. If a buddy starts a new
    >> > conversation using a
    >> > >> familiar public key, then OTR finds the
    match in the
    >> > store and
    >> > >> authenticates automatically. If a match is
    not found
    >> > in the store, for
    >> > >> example during the first conversation with a new
    >> > buddy, the user is
    >> > >> prompted to verify that the key is correct.
    In this
    >> > case OTR displays
    >> > >> the fingerprint (SHA-1 hash) of the
    unfamiliar key,
    >> > and asks the user to
    >> > >> verify its authenticity out-of-band. In
    otr4j based
    >> > applications like
    >> > >> jitsi, a class implementing the OtrKeyManager
    >> > interface manages the key
    >> > >> store.
    >> > >>
    >> > >> The problem with this method is that it is
    difficult
    >> > to use for an
    >> > >> uninitiated user that does not know or care
    what a
    >> > public
    >> > >> key/fingerprint/etc is. Here's where SMP
    comes into
    >> > play : SMP allows
    >> > >> two parties with secret information x and y
    >> > respectively to check
    >> > >> whether (x==y) without revealing any additional
    >> > information about the
    >> > >> secrets!
    >> > >>
    >> > >> Practically this means that we can replace the
    >> > regular authentication
    >> > >> mechanism (the fingerprint verification
    popup) with
    >> > an "Authenticate
    >> > >> Buddy" dialog box where the user can type
    the secret
    >> > he shares with the
    >> > >> other party. Here the user does not need to
    >> > understand any cryptographic
    >> > >> ideas; they need only to understand the idea
    of a
    >> > secret or a password.
    >> > >>
    >> > >> I guess your job will be to update otr4j and
    expose
    >> > the SMP
    >> > >> functionality by modifying the "Authenticate
    Buddy"
    >> > dialog in jitsi in
    >> > >> order to expose the SMP functionality. To better
    >> > understand how OTR
    >> > >> works and how SMP improves things you could
    first
    >> > code a small/simple
    >> > >> Java program that emulates a private
    conversation.
    >> > Or, if you feel
    >> > >> comfortable with the Jitsi testing
    infrastructure,
    >> > you can work directly
    >> > >> in Jitsi and create some test cases there.
    >> > >>
    >> > >> I hope this helps a bit.
    >> > >>
    >> > >> Cheers,
    >> > >> George
    >> > >>
    >> > >> On 10/18/2013 02:17 PM, Marin Dzhigarov wrote:
    >> > >>> Hello, George,
    >> > >>>
    >> > >>> It's pleasure the meet you!
    >> > >>>
    >> > >>> I'll be glad if you could help me at
    improving the
    >> > OTR support for
    >> > >>> Jitsi.
    >> > >>>
    >> > >>> Since you are the author of the otr4j I
    might have
    >> > some questions for
    >> > >>> you in the next couple of weeks.
    >> > >>>
    >> > >>>
    >> > >>> I will start with integrating the newest
    version of
    >> > otr4j with our
    >> > >>> source. Our current version of the jar is
    located
    >> > here
    >> > >>>
    >> >
    <https://github.com/jitsi/libsrc/blob/master/otr4j.zip>
    >> > and as you can
    >> > >>> see - it's quite old. Also, the docu here
    >> > >>>
    <https://code.google.com/p/otr4j/wiki/QuickStart> is
    >> > not very helpful as
    >> > >>> it has not been updated recently.
    >> > >>> I'm browsing the github repo right now and I'm
    >> > seeing some changes and a
    >> > >>> lot of new methods in the OtrEngineHost
    interface
    >> > that are not
    >> > >>> documented in the code.
    >> > >>> So I was wondering if you could give me any
    >> > directions on what these new
    >> > >>> methods do and how/why me and my team should
    >> > implement them in Jitsi.
    >> > >>>
    >> > >>>
    >> > >>> Another thing is the SMP support. Could you
    please
    >> > give me a brief
    >> > >>> explanation on where are we right now regarding
    >> > otr4j SMP support and
    >> > >>> what should be done in the future?
    >> > >>>
    >> > >>> Well... I think this is all I need to know
    for now.
    >> > >>>
    >> > >>> I'm looking forward from working with you!
    >> > >>>
    >> > >>> Regards,
    >> > >>> Marin
    >> > >>>
    >> > >>
    >> > >
    >> >
    >> >
    >> >
    >
    >

    --
    Emil Ivov, Ph.D. 67000 Strasbourg,
    Project Lead France
    Jitsi
    emcho@jitsi.org <mailto:emcho@jitsi.org>
     PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
    https://jitsi.org FAX: +33.1.77.62.47.31
    <tel:%2B33.1.77.62.47.31>


#4

Hello George,

I have some final questions for you on the subject.

First, I don't know if you aware but there is a problem with the otr4j when
the user tries to change PCs. For example:

1. Bob and Alice exchange some messages over OTR.
2.Alice then changes PC and now her OTR session status is PLAINTEXT. Bob's
session status is still ENCRYPTED.
3. Bob sends Alice a message but the message is encrypted so Alice is
supposed to try to refresh the OTR session.
However, in otr4j 3. does not work as expected. You can see the code that
is supposed to do 3. here:
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362
.

I was able to provide a fix - instead of injecting a new QueryMessage I
simply call refreshSession().
I haven't investigated any further why injecting a new QueryMessage does
not do the trick but since refreshin the session is a solution I don't see
any reason not to do it.

I was hoping if you have something to say about all of this.

Second, I found a bug in
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225

According to OTR's
specification<https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an
"OTR Query Message" must consint of "?OTR" followed by an indications of
what version of OTR is supported. A quote from the specification is:
"These strings may be hidden from the user (for example, in an attribute of
an HTML tag), and/or may be accompanied by an explanitory message ("Alice
has requested an Off-the-Record private conversation."). If Bob is willing
to use OTR with Alice (with a protocol version that Alice has offered), he
should start the AKE."

What this means is that it's perfectly normal for Bob to send Alice the
following:
*<p>?OTRv23?*
*<span style="font-weight: bold;">m.dzhigarov1@jit.si/</span> has requested
an <a href="http://otr.cypherpunks.ca/">Off-the-Record private
conversation</a>. However, you do not have a plugin to support that.*
*See <a href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
for more information.</p>*

···

*
*
In fact... this is exactly what an Adium/Pidgin user sends when initiating
OTR sessions. If you look at the code
here<https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229>,
obviously, s.indexOf(SerializationConstants.HEAD) != 0) will return 3 in
this scenario.
The result is - this message is going to be processed as a simple
PlainTextMessage, instead of QueryMessage, and OTR session will not be
initialized.
This is why Adium/Pidgin users can not start OTR sessions with Jitsi users
(the other way around is possible).

I haven't thought on how to fix this but my guess is that it won't be very
hard.

What are your thoughts on this one? Do you prefer me to fix this or do you
wish to do it yourself?

Regards,
Marin

On Wed, Oct 23, 2013 at 9:14 PM, George Politis <666f6f@gmail.com> wrote:

Hey Marin,

The OtrEngineHost is used to expose the host application to otr4j and
the OtrEngine interface is used to expose otr4j functionality to the
host application. When the host needs to decrypt/encrypt a message,
initiate SMP, get the session status, etc., it should call the
appropriate method from the OtrEngine interface.

Now, say for example you wish to transform an outgoing message M for
contact C. I just expressed that in "jitsish" (jitsi's language). otr4j
doesn't speak jitsi's language, so you have to translate jitsish to
otr4jish.

Technically speaking, you need to find the sessionId associated with
contact C and then call the OtrEngine.transformSending(sessionId, msg)
method to transform the message using the sessionId you just found. As
you can imagine, the procedure is more or less similar when you wish to
transform an incoming message, initiate SMP (to be done), etc.

To avoid code duplication and improve maintainability jitsi has an
"entity" (an interface + its implementation) called ScOtrEngine which is
nothing more than an OtrEngine wrapper that "speaks jitsi's language".

In there you'll find methods such as transformSending(contact, msg).
Notice the difference in the method signature with the transformSending
method in the OtrEngine interface. You will also find many examples that
show how to use the OtrEngine interface (including getting the session
object for a given contact). There's where you should put your
initSmp(contact) method.

I hope this helps.

Cheers,
George

On 10/23/2013 02:20 PM, Marin Dzhigarov wrote:
> Hello, George,
>
> I think I'm missing something... Which method in OtrEngineHost is
> supposed to init/start the SMP negotiation process?
>
> I'm looking at the code right now and I'm seeing this method
> net.java.otr4j.session.Session#initSmp(String question, String secret)
> but I have no way of getting a Session object from the OtrEngineHost.
>
> So how am I supposed to init the first step of the negotiation?
>
> Regards,
> Marin
>
>
> On Wed, Oct 23, 2013 at 12:28 PM, Emil Ivov <emcho@jitsi.org > > <mailto:emcho@jitsi.org>> wrote:
>
> Excellent! So, off to SMP then?
>
> (we should have had this chat over the dev list :slight_smile: ... let's continue
> there for future questions, ok?)
>
> On Wed, Oct 23, 2013 at 11:23 AM, Marin Dzhigarov > > <marin@bluejimp.com <mailto:marin@bluejimp.com>> wrote:
> > Just an update,
> >
> > The integration of otr4j in Jitsi is done.
> >
> > Renaming all "org.spongycastle" imports to "org.bouncycastle"
> almost did the
> > trick.
> > There was a problem, however, that otr4j had failing tests with
> bouncycastle
> > 1.49 (the version that we use in Jitsi).
> >
> > Following this topic:
> > http://lists.jitsi.org/pipermail/dev/2013-April/004097.html I was
> able to
> > make it work.
> >
> > Regards,
> > Marin
> >
> >
> > On Wed, Oct 23, 2013 at 10:32 AM, George Politis > > <gp@superpointer.com <mailto:gp@superpointer.com>> > > > wrote:
> >>
> >> Well, it took me a while to remember it myself when we talked
> about it
> >> in Strasbourg :slight_smile:
> >>
> >> On 10/23/2013 09:22 AM, Emil Ivov wrote:
> >> > I think I might have misled you about the Android problem. As
> George
> >> > said, the changes were made due to size concerns and then my
brain
> >> > somehow generated the Android story.
> >> >
> >> > --sent from my mobile
> >> >
> >> > On 23 Oct 2013 09:19, "Marin Dzhigarov" <marin@bluejimp.com > > <mailto:marin@bluejimp.com> > > >> > <mailto:marin@bluejimp.com <mailto:marin@bluejimp.com>>> wrote:
> >> >
> >> > Thanks for the quick reply George!
> >> >
> >> > But wasn't 'spongycastle', If I recall correctly, a version
of
> >> > bouncycastle that is supposed to works on android devices?
> >> >
> >> > Did you created it?
> >> >
> >> >
> >> >
> >> > On Wed, Oct 23, 2013 at 10:04 AM, Emil Ivov > > <emcho@jitsi.org <mailto:emcho@jitsi.org> > > >> > <mailto:emcho@jitsi.org <mailto:emcho@jitsi.org>>> wrote:
> >> >
> >> > Hey Marin,
> >> >
> >> > I remember that one of the problens was that OTR4J has a
> >> > dependency on a modified version of bouncycastle
(changed
> >> > package names IIRC). We cannot continue using it
because it
> >> > conflicts Debian's policy. We need to use the vanilla
> version
> >> > (the one that they ship in their repo).
> >> >
> >> > Emil
> >> >
> >> > --sent from my mobile
> >> >
> >> > On 23 Oct 2013 08:57, "Marin Dzhigarov" > > <marin@bluejimp.com <mailto:marin@bluejimp.com> > > >> > <mailto:marin@bluejimp.com > > <mailto:marin@bluejimp.com>>> wrote:
> >> >
> >> > Hello, George,
> >> >
> >> > It is true that the methods signatures are very
> descriptive.
> >> > I was able to figure them out quite easily without
> (or at
> >> > least very little) code browsing.
> >> >
> >> > I already integrated the newest version of otr4j in
> my local
> >> > Jitsi's repo so it's a matter of time to hit the
> smp part.
> >> >
> >> > If I have any questions I will seek your help.
> >> >
> >> > Regards,
> >> > Marin
> >> >
> >> >
> >> >
> >> > On Tue, Oct 22, 2013 at 10:07 PM, George Politis > > >> > <gp@superpointer.com <mailto:gp@superpointer.com> > > <mailto:gp@superpointer.com <mailto:gp@superpointer.com>>> wrote:
> >> >
> >> > Hello Emil, Marin,
> >> >
> >> > I'm sorry for the general answer, I couldn't
> guess that
> >> > Marin already
> >> > has a good basis in OTR so I thought it might
> be useful
> >> > to give a very
> >> > brief overview of the protocol. Anyway, I
> didn't want to
> >> > underestimate
> >> > Marin's understanding of the OTR protocol
> >> >
> >> > AFAIK Gibberbot is known to support SMP and it
uses
> >> > otr4j, so I think it
> >> > is safe to say that otr4j fully supports SMP. I
> haven't
> >> > personally
> >> > reviewed the code.
> >> >
> >> > The new undocumented methods have a fairly
> descriptive
> >> > name for someone
> >> > that understands OTR and SMP. For example, when
> otr4j
> >> > "wants/needs" to
> >> > know the shared secret of a user (a step in the
> >> > protocol), it calls the
> >> > OtrEngineHost.askForSecret(session, secret)
> method. In
> >> > that case, jitsi
> >> > should display a dialog box to the user to type
the
> >> > shared secret.
> >> >
> >> > Another example, when otr4j detects an error in
> the SMP
> >> > exchange
> >> > sequence, it calls the
> OtrEngineHost.smpError(session,
> >> > tlvType, cheated)
> >> > method. In that case jitsi should probably
> display an
> >> > error box.
> >> >
> >> > Lastly, when otr4j detects that the remote and
has
> >> > aborted the SMP, it
> >> > calls the OtrEngineHost.smpAborted(session)
> method. In
> >> > that case, jitsi
> >> > could probably display a message box to notify
> the user
> >> > that the remote
> >> > end aborted the SMP.
> >> >
> >> > @Marin, please let me know if this answers your
> >> > question. You can of
> >> > course send me patches for review and
validation.
> >> >
> >> > Cheers,
> >> > George
> >> >
> >> > On 10/22/2013 05:33 PM, Emil Ivov wrote:
> >> > > Thanks George,
> >> > >
> >> > > Actually I think Marin already has a good
> basis in
> >> > OTR. He was mostly
> >> > > interested in more otr4j related matters,
> like for
> >> > example, what is the
> >> > > level of support for SMP currently in there
and
> >> > potentially validating
> >> > > some of his changes on the project before
> committing
> >> > them.
> >> > >
> >> > > Marin, I'll let you continue with more
specific
> >> > questions.
> >> > >
> >> > > Emil
> >> > >
> >> > > On 19.10.13, 00:10, George Politis wrote:
> >> > >> Hey Marin! I'd be glad to help you through
this.
> >> > >>
> >> > >> It's true that the otr4j version included in
> jitsi is
> >> > a little outdated.
> >> > >> The major difference between the version
> bundled with
> >> > Jitsi and the git
> >> > >> tip is SMP support which has been
> contributed by The
> >> > Guardian Project.
> >> > >>
> >> > >> To put things into perspective, let's start
> with this
> >> > : OTR provides
> >> > >> authentication, encryption, perfect forward
> secrecy
> >> > and malleable
> >> > >> encryption for instant messaging
> conversations. All
> >> > those terms have a
> >> > >> well defined and precise meaning. The
Socialist
> >> > Millionaires Protocol
> >> > >> (SMP) deals with the authentication problem.
> >> > >>
> >> > >> Without SMP, Alice and Bob (two parties
> wishing to
> >> > communicate) have to
> >> > >> know each other’s public keys before the
> >> > Authenticated Key Exchange
> >> > >> (AKE) begins. If they do not, then Eve (the
> bad guy,
> >> > naturally) can
> >> > >> pretend to be Bob and use her own key pair
for
> >> > signing, and Alice will
> >> > >> have no way to spot the deception. This
> makes MITM
> >> > attacks launched from
> >> > >> a central IM server particularly effective.
> Not good!
> >> > >>
> >> > >> To prevent this attack, each OTR user
> maintains a
> >> > store of their
> >> > >> buddies’ public keys. If a buddy starts a new
> >> > conversation using a
> >> > >> familiar public key, then OTR finds the
> match in the
> >> > store and
> >> > >> authenticates automatically. If a match is
> not found
> >> > in the store, for
> >> > >> example during the first conversation with a
new
> >> > buddy, the user is
> >> > >> prompted to verify that the key is correct.
> In this
> >> > case OTR displays
> >> > >> the fingerprint (SHA-1 hash) of the
> unfamiliar key,
> >> > and asks the user to
> >> > >> verify its authenticity out-of-band. In
> otr4j based
> >> > applications like
> >> > >> jitsi, a class implementing the OtrKeyManager
> >> > interface manages the key
> >> > >> store.
> >> > >>
> >> > >> The problem with this method is that it is
> difficult
> >> > to use for an
> >> > >> uninitiated user that does not know or care
> what a
> >> > public
> >> > >> key/fingerprint/etc is. Here's where SMP
> comes into
> >> > play : SMP allows
> >> > >> two parties with secret information x and y
> >> > respectively to check
> >> > >> whether (x==y) without revealing any
additional
> >> > information about the
> >> > >> secrets!
> >> > >>
> >> > >> Practically this means that we can replace
the
> >> > regular authentication
> >> > >> mechanism (the fingerprint verification
> popup) with
> >> > an "Authenticate
> >> > >> Buddy" dialog box where the user can type
> the secret
> >> > he shares with the
> >> > >> other party. Here the user does not need to
> >> > understand any cryptographic
> >> > >> ideas; they need only to understand the idea
> of a
> >> > secret or a password.
> >> > >>
> >> > >> I guess your job will be to update otr4j and
> expose
> >> > the SMP
> >> > >> functionality by modifying the "Authenticate
> Buddy"
> >> > dialog in jitsi in
> >> > >> order to expose the SMP functionality. To
better
> >> > understand how OTR
> >> > >> works and how SMP improves things you could
> first
> >> > code a small/simple
> >> > >> Java program that emulates a private
> conversation.
> >> > Or, if you feel
> >> > >> comfortable with the Jitsi testing
> infrastructure,
> >> > you can work directly
> >> > >> in Jitsi and create some test cases there.
> >> > >>
> >> > >> I hope this helps a bit.
> >> > >>
> >> > >> Cheers,
> >> > >> George
> >> > >>
> >> > >> On 10/18/2013 02:17 PM, Marin Dzhigarov > wrote:
> >> > >>> Hello, George,
> >> > >>>
> >> > >>> It's pleasure the meet you!
> >> > >>>
> >> > >>> I'll be glad if you could help me at
> improving the
> >> > OTR support for
> >> > >>> Jitsi.
> >> > >>>
> >> > >>> Since you are the author of the otr4j I
> might have
> >> > some questions for
> >> > >>> you in the next couple of weeks.
> >> > >>>
> >> > >>>
> >> > >>> I will start with integrating the newest
> version of
> >> > otr4j with our
> >> > >>> source. Our current version of the jar is
> located
> >> > here
> >> > >>>
> >> >
> <https://github.com/jitsi/libsrc/blob/master/otr4j.zip>
> >> > and as you can
> >> > >>> see - it's quite old. Also, the docu here
> >> > >>>
> <https://code.google.com/p/otr4j/wiki/QuickStart> is
> >> > not very helpful as
> >> > >>> it has not been updated recently.
> >> > >>> I'm browsing the github repo right now and
I'm
> >> > seeing some changes and a
> >> > >>> lot of new methods in the OtrEngineHost
> interface
> >> > that are not
> >> > >>> documented in the code.
> >> > >>> So I was wondering if you could give me any
> >> > directions on what these new
> >> > >>> methods do and how/why me and my team should
> >> > implement them in Jitsi.
> >> > >>>
> >> > >>>
> >> > >>> Another thing is the SMP support. Could you
> please
> >> > give me a brief
> >> > >>> explanation on where are we right now
regarding
> >> > otr4j SMP support and
> >> > >>> what should be done in the future?
> >> > >>>
> >> > >>> Well... I think this is all I need to know
> for now.
> >> > >>>
> >> > >>> I'm looking forward from working with you!
> >> > >>>
> >> > >>> Regards,
> >> > >>> Marin
> >> > >>>
> >> > >>
> >> > >
> >> >
> >> >
> >> >
> >
> >
>
>
>
> --
> Emil Ivov, Ph.D. 67000 Strasbourg,
> Project Lead France
> Jitsi
> emcho@jitsi.org <mailto:emcho@jitsi.org>
> PHONE: +33.1.77.62.43.30 <tel:%2B33.1.77.62.43.30>
> https://jitsi.org FAX: +33.1.77.62.47.31
> <tel:%2B33.1.77.62.47.31>
>
>


#5

Hello Marin,

First, I don't know if you aware but there is a problem with the otr4j
when the user tries to change PCs. For example:

1. Bob and Alice exchange some messages over OTR.
2.Alice then changes PC and now her OTR session status is PLAINTEXT.
Bob's session status is still ENCRYPTED.
3. Bob sends Alice a message but the message is encrypted so Alice is
supposed to try to refresh the OTR session.
However, in otr4j 3. does not work as expected. You can see the code
that is supposed to do 3.
here: https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362 .

I was able to provide a fix - instead of injecting a new QueryMessage I
simply call refreshSession().
I haven't investigated any further why injecting a new QueryMessage does
not do the trick but since refreshin the session is a solution I don't
see any reason not to do it.

I was hoping if you have something to say about all of this.

You're right, there's a problem here. The protocol specification says
that if we receive a data message and if the msgstate is
MSGSTATE_PLAINTEXT or MSGSTATE_FINISHED then we must inform the user
that an unreadable encrypted message was received (already the case),
and reply with an Error Message. What otr4j does is reply with a query
message, which is wrong. It would be wrong, too, to refresh the session,
in the sense that it is not what the protocol dictates.

Second, I found a bug
in https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225

According to OTR's specification
<https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
Message" must consint of "?OTR" followed by an indications of what
version of OTR is supported. A quote from the specification is:
"These strings may be hidden from the user (for example, in an attribute
of an HTML tag), and/or may be accompanied by an explanitory message
("Alice has requested an Off-the-Record private conversation."). If Bob
is willing to use OTR with Alice (with a protocol version that Alice has
offered), he should start the AKE."

What this means is that it's perfectly normal for Bob to send Alice the
following:
*<p>?OTRv23?*
*<span style="font-weight: bold;">m.dzhigarov1@jit.si/
<http://m.dzhigarov1@jit.si/></span> has requested an <a
href="http://otr.cypherpunks.ca/">Off-the-Record private
conversation</a>. However, you do not have a plugin to support that.*
*See <a href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
for more information.</p>*
*
*
In fact... this is exactly what an Adium/Pidgin user sends when
initiating OTR sessions. If you look at the code here
<https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229>,
obviously, s.indexOf(SerializationConstants.HEAD) != 0) will return 3 in
this scenario.
The result is - this message is going to be processed as a simple
PlainTextMessage, instead of QueryMessage, and OTR session will not be
initialized.
This is why Adium/Pidgin users can not start OTR sessions with Jitsi
users (the other way around is possible).

I haven't thought on how to fix this but my guess is that it won't be
very hard.

What are your thoughts on this one? Do you prefer me to fix this or do
you wish to do it yourself?

You're right again, I opened issue #5 on Github. I'll have a look tomorrow.

Regards,
George


#6

Hello,

The patch for the SMP is ready. I'm attaching it plus some screenshots.

George, can you please review the changes?

Regards,
Marin

smp.patch (190 KB)

···

On Thu, Oct 31, 2013 at 1:21 AM, George Politis <666f6f@gmail.com> wrote:

Hello Marin,

> First, I don't know if you aware but there is a problem with the otr4j
> when the user tries to change PCs. For example:
>
> 1. Bob and Alice exchange some messages over OTR.
> 2.Alice then changes PC and now her OTR session status is PLAINTEXT.
> Bob's session status is still ENCRYPTED.
> 3. Bob sends Alice a message but the message is encrypted so Alice is
> supposed to try to refresh the OTR session.
> However, in otr4j 3. does not work as expected. You can see the code
> that is supposed to do 3.
> here:
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362.
>
> I was able to provide a fix - instead of injecting a new QueryMessage I
> simply call refreshSession().
> I haven't investigated any further why injecting a new QueryMessage does
> not do the trick but since refreshin the session is a solution I don't
> see any reason not to do it.
>
> I was hoping if you have something to say about all of this.

You're right, there's a problem here. The protocol specification says
that if we receive a data message and if the msgstate is
MSGSTATE_PLAINTEXT or MSGSTATE_FINISHED then we must inform the user
that an unreadable encrypted message was received (already the case),
and reply with an Error Message. What otr4j does is reply with a query
message, which is wrong. It would be wrong, too, to refresh the session,
in the sense that it is not what the protocol dictates.

> Second, I found a bug
> in
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225
>
> According to OTR's specification
> <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
> Message" must consint of "?OTR" followed by an indications of what
> version of OTR is supported. A quote from the specification is:
> "These strings may be hidden from the user (for example, in an attribute
> of an HTML tag), and/or may be accompanied by an explanitory message
> ("Alice has requested an Off-the-Record private conversation."). If Bob
> is willing to use OTR with Alice (with a protocol version that Alice has
> offered), he should start the AKE."
>
> What this means is that it's perfectly normal for Bob to send Alice the
> following:
> *<p>?OTRv23?*
> *<span style="font-weight: bold;">m.dzhigarov1@jit.si/
> <http://m.dzhigarov1@jit.si/></span> has requested an <a
> href="http://otr.cypherpunks.ca/">Off-the-Record private
> conversation</a>. However, you do not have a plugin to support that.*
> *See <a href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
> for more information.</p>*
> *
> *
> In fact... this is exactly what an Adium/Pidgin user sends when
> initiating OTR sessions. If you look at the code here
> <
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229
>,
> obviously, s.indexOf(SerializationConstants.HEAD) != 0) will return 3 in
> this scenario.
> The result is - this message is going to be processed as a simple
> PlainTextMessage, instead of QueryMessage, and OTR session will not be
> initialized.
> This is why Adium/Pidgin users can not start OTR sessions with Jitsi
> users (the other way around is possible).
>
> I haven't thought on how to fix this but my guess is that it won't be
> very hard.
>
> What are your thoughts on this one? Do you prefer me to fix this or do
> you wish to do it yourself?

You're right again, I opened issue #5 on Github. I'll have a look tomorrow.

Regards,
George

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

Second, I found a bug
in https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225

According to OTR's specification
<https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
Message" must consint of "?OTR" followed by an indications of what
version of OTR is supported. A quote from the specification is:
"These strings may be hidden from the user (for example, in an attribute
of an HTML tag), and/or may be accompanied by an explanitory message
("Alice has requested an Off-the-Record private conversation."). If Bob
is willing to use OTR with Alice (with a protocol version that Alice has
offered), he should start the AKE."

What this means is that it's perfectly normal for Bob to send Alice the
following:
*<p>?OTRv23?*
*<span style="font-weight: bold;">m.dzhigarov1@jit.si/
<http://m.dzhigarov1@jit.si/></span> has requested an <a
href="http://otr.cypherpunks.ca/">Off-the-Record private
conversation</a>. However, you do not have a plugin to support that.*
*See <a href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
for more information.</p>*
*
*
In fact... this is exactly what an Adium/Pidgin user sends when
initiating OTR sessions. If you look at the code here
<https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229>,
obviously, s.indexOf(SerializationConstants.HEAD) != 0) will return 3 in
this scenario.
The result is - this message is going to be processed as a simple
PlainTextMessage, instead of QueryMessage, and OTR session will not be
initialized.
This is why Adium/Pidgin users can not start OTR sessions with Jitsi
users (the other way around is possible).

I haven't thought on how to fix this but my guess is that it won't be
very hard.

What are your thoughts on this one? Do you prefer me to fix this or do
you wish to do it yourself?

You're right again, I opened issue #5 on Github. I'll have a look tomorrow.

This problem should be fixed in the otr4j master branch.


#8

Looks very good! I am glad to know we are getting there! One thing
that strikes me: authentication success and failure seem to be
somewhat unreadable now. Could you please either try to make the
backgrounds a bit dimmer or use a different font colour? We'll ask
Joro to choose specific colours as soon as he's ready with his site
changes.

Emil

···

On Thu, Oct 31, 2013 at 11:58 AM, Marin Dzhigarov <marin@bluejimp.com> wrote:

Hello,

The patch for the SMP is ready. I'm attaching it plus some screenshots.

George, can you please review the changes?

Regards,
Marin

On Thu, Oct 31, 2013 at 1:21 AM, George Politis <666f6f@gmail.com> wrote:

Hello Marin,

> First, I don't know if you aware but there is a problem with the otr4j
> when the user tries to change PCs. For example:
>
> 1. Bob and Alice exchange some messages over OTR.
> 2.Alice then changes PC and now her OTR session status is PLAINTEXT.
> Bob's session status is still ENCRYPTED.
> 3. Bob sends Alice a message but the message is encrypted so Alice is
> supposed to try to refresh the OTR session.
> However, in otr4j 3. does not work as expected. You can see the code
> that is supposed to do 3.
> here:
> https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362
> .
>
> I was able to provide a fix - instead of injecting a new QueryMessage I
> simply call refreshSession().
> I haven't investigated any further why injecting a new QueryMessage does
> not do the trick but since refreshin the session is a solution I don't
> see any reason not to do it.
>
> I was hoping if you have something to say about all of this.

You're right, there's a problem here. The protocol specification says
that if we receive a data message and if the msgstate is
MSGSTATE_PLAINTEXT or MSGSTATE_FINISHED then we must inform the user
that an unreadable encrypted message was received (already the case),
and reply with an Error Message. What otr4j does is reply with a query
message, which is wrong. It would be wrong, too, to refresh the session,
in the sense that it is not what the protocol dictates.

> Second, I found a bug
> in
> https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225
>
> According to OTR's specification
> <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
> Message" must consint of "?OTR" followed by an indications of what
> version of OTR is supported. A quote from the specification is:
> "These strings may be hidden from the user (for example, in an attribute
> of an HTML tag), and/or may be accompanied by an explanitory message
> ("Alice has requested an Off-the-Record private conversation."). If Bob
> is willing to use OTR with Alice (with a protocol version that Alice has
> offered), he should start the AKE."
>
> What this means is that it's perfectly normal for Bob to send Alice the
> following:
> *<p>?OTRv23?*
> *<span style="font-weight: bold;">m.dzhigarov1@jit.si/
> <http://m.dzhigarov1@jit.si/></span> has requested an <a
> href="http://otr.cypherpunks.ca/">Off-the-Record private
> conversation</a>. However, you do not have a plugin to support that.*
> *See <a href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
> for more information.</p>*
> *
> *
> In fact... this is exactly what an Adium/Pidgin user sends when
> initiating OTR sessions. If you look at the code here
>
> <https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229>,
> obviously, s.indexOf(SerializationConstants.HEAD) != 0) will return 3 in
> this scenario.
> The result is - this message is going to be processed as a simple
> PlainTextMessage, instead of QueryMessage, and OTR session will not be
> initialized.
> This is why Adium/Pidgin users can not start OTR sessions with Jitsi
> users (the other way around is possible).
>
> I haven't thought on how to fix this but my guess is that it won't be
> very hard.
>
> What are your thoughts on this one? Do you prefer me to fix this or do
> you wish to do it yourself?

You're right again, I opened issue #5 on Github. I'll have a look
tomorrow.

Regards,
George

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#9

Is this better?

···

On Thu, Oct 31, 2013 at 1:21 PM, Emil Ivov <emcho@jitsi.org> wrote:

Looks very good! I am glad to know we are getting there! One thing
that strikes me: authentication success and failure seem to be
somewhat unreadable now. Could you please either try to make the
backgrounds a bit dimmer or use a different font colour? We'll ask
Joro to choose specific colours as soon as he's ready with his site
changes.

Emil

On Thu, Oct 31, 2013 at 11:58 AM, Marin Dzhigarov <marin@bluejimp.com> > wrote:
> Hello,
>
> The patch for the SMP is ready. I'm attaching it plus some screenshots.
>
> George, can you please review the changes?
>
> Regards,
> Marin
>
>
>
>
> On Thu, Oct 31, 2013 at 1:21 AM, George Politis <666f6f@gmail.com> > wrote:
>>
>> Hello Marin,
>>
>> > First, I don't know if you aware but there is a problem with the otr4j
>> > when the user tries to change PCs. For example:
>> >
>> > 1. Bob and Alice exchange some messages over OTR.
>> > 2.Alice then changes PC and now her OTR session status is PLAINTEXT.
>> > Bob's session status is still ENCRYPTED.
>> > 3. Bob sends Alice a message but the message is encrypted so Alice is
>> > supposed to try to refresh the OTR session.
>> > However, in otr4j 3. does not work as expected. You can see the code
>> > that is supposed to do 3.
>> > here:
>> >
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362
>> > .
>> >
>> > I was able to provide a fix - instead of injecting a new QueryMessage
I
>> > simply call refreshSession().
>> > I haven't investigated any further why injecting a new QueryMessage
does
>> > not do the trick but since refreshin the session is a solution I don't
>> > see any reason not to do it.
>> >
>> > I was hoping if you have something to say about all of this.
>>
>> You're right, there's a problem here. The protocol specification says
>> that if we receive a data message and if the msgstate is
>> MSGSTATE_PLAINTEXT or MSGSTATE_FINISHED then we must inform the user
>> that an unreadable encrypted message was received (already the case),
>> and reply with an Error Message. What otr4j does is reply with a query
>> message, which is wrong. It would be wrong, too, to refresh the session,
>> in the sense that it is not what the protocol dictates.
>>
>> > Second, I found a bug
>> > in
>> >
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225
>> >
>> > According to OTR's specification
>> > <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
>> > Message" must consint of "?OTR" followed by an indications of what
>> > version of OTR is supported. A quote from the specification is:
>> > "These strings may be hidden from the user (for example, in an
attribute
>> > of an HTML tag), and/or may be accompanied by an explanitory message
>> > ("Alice has requested an Off-the-Record private conversation."). If
Bob
>> > is willing to use OTR with Alice (with a protocol version that Alice
has
>> > offered), he should start the AKE."
>> >
>> > What this means is that it's perfectly normal for Bob to send Alice
the
>> > following:
>> > *<p>?OTRv23?*
>> > *<span style="font-weight: bold;">m.dzhigarov1@jit.si/
>> > <http://m.dzhigarov1@jit.si/></span> has requested an <a
>> > href="http://otr.cypherpunks.ca/">Off-the-Record private
>> > conversation</a>. However, you do not have a plugin to support that.*
>> > *See <a href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/
</a>
>> > for more information.</p>*
>> > *
>> > *
>> > In fact... this is exactly what an Adium/Pidgin user sends when
>> > initiating OTR sessions. If you look at the code here
>> >
>> > <
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229
>,
>> > obviously, s.indexOf(SerializationConstants.HEAD) != 0) will return 3
in
>> > this scenario.
>> > The result is - this message is going to be processed as a simple
>> > PlainTextMessage, instead of QueryMessage, and OTR session will not be
>> > initialized.
>> > This is why Adium/Pidgin users can not start OTR sessions with Jitsi
>> > users (the other way around is possible).
>> >
>> > I haven't thought on how to fix this but my guess is that it won't be
>> > very hard.
>> >
>> > What are your thoughts on this one? Do you prefer me to fix this or do
>> > you wish to do it yourself?
>>
>> You're right again, I opened issue #5 on Github. I'll have a look
>> tomorrow.
>>
>> Regards,
>> George
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#10

Hello Marin,

I had a quick look at the code and It looks correct to me. I'll give it
a more thorough look tomorrow and I'll run some tests too, to make sure
I didn't miss anything. Very nice GUI, too!

Cheers,
George

···

On 10/31/2013 11:58 AM, Marin Dzhigarov wrote:

Hello,

The patch for the SMP is ready. I'm attaching it plus some screenshots.

George, can you please review the changes?

Regards,
Marin

On Thu, Oct 31, 2013 at 1:21 AM, George Politis <666f6f@gmail.com > <mailto:666f6f@gmail.com>> wrote:

    Hello Marin,

    > First, I don't know if you aware but there is a problem with the otr4j
    > when the user tries to change PCs. For example:
    >
    > 1. Bob and Alice exchange some messages over OTR.
    > 2.Alice then changes PC and now her OTR session status is PLAINTEXT.
    > Bob's session status is still ENCRYPTED.
    > 3. Bob sends Alice a message but the message is encrypted so Alice is
    > supposed to try to refresh the OTR session.
    > However, in otr4j 3. does not work as expected. You can see the code
    > that is supposed to do 3.
    > here:
    https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362
    .
    >
    > I was able to provide a fix - instead of injecting a new
    QueryMessage I
    > simply call refreshSession().
    > I haven't investigated any further why injecting a new
    QueryMessage does
    > not do the trick but since refreshin the session is a solution I don't
    > see any reason not to do it.
    >
    > I was hoping if you have something to say about all of this.

    You're right, there's a problem here. The protocol specification says
    that if we receive a data message and if the msgstate is
    MSGSTATE_PLAINTEXT or MSGSTATE_FINISHED then we must inform the user
    that an unreadable encrypted message was received (already the case),
    and reply with an Error Message. What otr4j does is reply with a query
    message, which is wrong. It would be wrong, too, to refresh the session,
    in the sense that it is not what the protocol dictates.

    > Second, I found a bug
    > in
    https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225
    >
    > According to OTR's specification
    > <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
    > Message" must consint of "?OTR" followed by an indications of what
    > version of OTR is supported. A quote from the specification is:
    > "These strings may be hidden from the user (for example, in an
    attribute
    > of an HTML tag), and/or may be accompanied by an explanitory message
    > ("Alice has requested an Off-the-Record private conversation.").
    If Bob
    > is willing to use OTR with Alice (with a protocol version that
    Alice has
    > offered), he should start the AKE."
    >
    > What this means is that it's perfectly normal for Bob to send
    Alice the
    > following:
    > *<p>?OTRv23?*
    > *<span style="font-weight: bold;">m.dzhigarov1@jit.si/
    <http://m.dzhigarov1@jit.si/>
    > <http://m.dzhigarov1@jit.si/></span> has requested an <a
    > href="http://otr.cypherpunks.ca/">Off-the-Record private
    > conversation</a>. However, you do not have a plugin to support that.*
    > *See <a
    href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
    > for more information.</p>*
    > *
    > *
    > In fact... this is exactly what an Adium/Pidgin user sends when
    > initiating OTR sessions. If you look at the code here
    >
    <https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229>,
    > obviously, s.indexOf(SerializationConstants.HEAD) != 0) will
    return 3 in
    > this scenario.
    > The result is - this message is going to be processed as a simple
    > PlainTextMessage, instead of QueryMessage, and OTR session will not be
    > initialized.
    > This is why Adium/Pidgin users can not start OTR sessions with Jitsi
    > users (the other way around is possible).
    >
    > I haven't thought on how to fix this but my guess is that it won't be
    > very hard.
    >
    > What are your thoughts on this one? Do you prefer me to fix this or do
    > you wish to do it yourself?

    You're right again, I opened issue #5 on Github. I'll have a look
    tomorrow.

    Regards,
    George

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Lovely! Thanks

···

On Thu, Oct 31, 2013 at 12:47 PM, Marin Dzhigarov <marin@bluejimp.com> wrote:

Is this better?

On Thu, Oct 31, 2013 at 1:21 PM, Emil Ivov <emcho@jitsi.org> wrote:

Looks very good! I am glad to know we are getting there! One thing
that strikes me: authentication success and failure seem to be
somewhat unreadable now. Could you please either try to make the
backgrounds a bit dimmer or use a different font colour? We'll ask
Joro to choose specific colours as soon as he's ready with his site
changes.

Emil

On Thu, Oct 31, 2013 at 11:58 AM, Marin Dzhigarov <marin@bluejimp.com> >> wrote:
> Hello,
>
> The patch for the SMP is ready. I'm attaching it plus some screenshots.
>
> George, can you please review the changes?
>
> Regards,
> Marin
>
>
>
>
> On Thu, Oct 31, 2013 at 1:21 AM, George Politis <666f6f@gmail.com> >> > wrote:
>>
>> Hello Marin,
>>
>> > First, I don't know if you aware but there is a problem with the
>> > otr4j
>> > when the user tries to change PCs. For example:
>> >
>> > 1. Bob and Alice exchange some messages over OTR.
>> > 2.Alice then changes PC and now her OTR session status is PLAINTEXT.
>> > Bob's session status is still ENCRYPTED.
>> > 3. Bob sends Alice a message but the message is encrypted so Alice is
>> > supposed to try to refresh the OTR session.
>> > However, in otr4j 3. does not work as expected. You can see the code
>> > that is supposed to do 3.
>> > here:
>> >
>> > https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362
>> > .
>> >
>> > I was able to provide a fix - instead of injecting a new QueryMessage
>> > I
>> > simply call refreshSession().
>> > I haven't investigated any further why injecting a new QueryMessage
>> > does
>> > not do the trick but since refreshin the session is a solution I
>> > don't
>> > see any reason not to do it.
>> >
>> > I was hoping if you have something to say about all of this.
>>
>> You're right, there's a problem here. The protocol specification says
>> that if we receive a data message and if the msgstate is
>> MSGSTATE_PLAINTEXT or MSGSTATE_FINISHED then we must inform the user
>> that an unreadable encrypted message was received (already the case),
>> and reply with an Error Message. What otr4j does is reply with a query
>> message, which is wrong. It would be wrong, too, to refresh the
>> session,
>> in the sense that it is not what the protocol dictates.
>>
>> > Second, I found a bug
>> > in
>> >
>> > https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225
>> >
>> > According to OTR's specification
>> > <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
>> > Message" must consint of "?OTR" followed by an indications of what
>> > version of OTR is supported. A quote from the specification is:
>> > "These strings may be hidden from the user (for example, in an
>> > attribute
>> > of an HTML tag), and/or may be accompanied by an explanitory message
>> > ("Alice has requested an Off-the-Record private conversation."). If
>> > Bob
>> > is willing to use OTR with Alice (with a protocol version that Alice
>> > has
>> > offered), he should start the AKE."
>> >
>> > What this means is that it's perfectly normal for Bob to send Alice
>> > the
>> > following:
>> > *<p>?OTRv23?*
>> > *<span style="font-weight: bold;">m.dzhigarov1@jit.si/
>> > <http://m.dzhigarov1@jit.si/></span> has requested an <a
>> > href="http://otr.cypherpunks.ca/">Off-the-Record private
>> > conversation</a>. However, you do not have a plugin to support
>> > that.*
>> > *See <a
>> > href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
>> > for more information.</p>*
>> > *
>> > *
>> > In fact... this is exactly what an Adium/Pidgin user sends when
>> > initiating OTR sessions. If you look at the code here
>> >
>> >
>> > <https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229>,
>> > obviously, s.indexOf(SerializationConstants.HEAD) != 0) will return 3
>> > in
>> > this scenario.
>> > The result is - this message is going to be processed as a simple
>> > PlainTextMessage, instead of QueryMessage, and OTR session will not
>> > be
>> > initialized.
>> > This is why Adium/Pidgin users can not start OTR sessions with Jitsi
>> > users (the other way around is possible).
>> >
>> > I haven't thought on how to fix this but my guess is that it won't be
>> > very hard.
>> >
>> > What are your thoughts on this one? Do you prefer me to fix this or
>> > do
>> > you wish to do it yourself?
>>
>> You're right again, I opened issue #5 on Github. I'll have a look
>> tomorrow.
>>
>> Regards,
>> George
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
https://jitsi.org FAX: +33.1.77.62.47.31


#12

Hello,

Here is the newest patch. The main differences are the improved colors of
the progress bar and also the latest fixes that George made on the
otr4j.jar.

I'm very happy to announce that thanks to George the problem with changing
PCs is gone!

Also, Adium/Pidgin users can now initiate OTR conversations with Jitsi
users without problems.

George, I have just one final concern. How do you feel about
changing net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
net.java.otr4j.OtrEngineHost.getFallbackMessage() signatures to have
SessionID for a parameter? This would allow for more flexibility when
sending error messages to the remote party. For example Alice can send Bob
the following ERROR_MESSAGE:
"You sent Alice an unreadable encrypted message. Please end you private
conversation with Alice or refresh it."

I feel that right now it is not very clear who sent what when it comes to
error messages in the OTR.
Of'course this is just a minor thing and can be ignored. I just feel that
it would be less confusing for the users.

Anyway, please review my latest patch and if you have any concerns feel
free to message me.

Regards,
Marin

otr.patch (191 KB)

···

On Fri, Nov 1, 2013 at 2:33 AM, George Politis <666f6f@gmail.com> wrote:

Hello Marin,

I had a quick look at the code and It looks correct to me. I'll give it
a more thorough look tomorrow and I'll run some tests too, to make sure
I didn't miss anything. Very nice GUI, too!

Cheers,
George

On 10/31/2013 11:58 AM, Marin Dzhigarov wrote:
> Hello,
>
> The patch for the SMP is ready. I'm attaching it plus some screenshots.
>
> George, can you please review the changes?
>
> Regards,
> Marin
>
>
>
>
> On Thu, Oct 31, 2013 at 1:21 AM, George Politis <666f6f@gmail.com > > <mailto:666f6f@gmail.com>> wrote:
>
> Hello Marin,
>
> > First, I don't know if you aware but there is a problem with the
otr4j
> > when the user tries to change PCs. For example:
> >
> > 1. Bob and Alice exchange some messages over OTR.
> > 2.Alice then changes PC and now her OTR session status is
PLAINTEXT.
> > Bob's session status is still ENCRYPTED.
> > 3. Bob sends Alice a message but the message is encrypted so Alice
is
> > supposed to try to refresh the OTR session.
> > However, in otr4j 3. does not work as expected. You can see the
code
> > that is supposed to do 3.
> > here:
>
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/session/SessionImpl.java#L362
> .
> >
> > I was able to provide a fix - instead of injecting a new
> QueryMessage I
> > simply call refreshSession().
> > I haven't investigated any further why injecting a new
> QueryMessage does
> > not do the trick but since refreshin the session is a solution I
don't
> > see any reason not to do it.
> >
> > I was hoping if you have something to say about all of this.
>
> You're right, there's a problem here. The protocol specification says
> that if we receive a data message and if the msgstate is
> MSGSTATE_PLAINTEXT or MSGSTATE_FINISHED then we must inform the user
> that an unreadable encrypted message was received (already the case),
> and reply with an Error Message. What otr4j does is reply with a
query
> message, which is wrong. It would be wrong, too, to refresh the
session,
> in the sense that it is not what the protocol dictates.
>
> > Second, I found a bug
> > in
>
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L225
> >
> > According to OTR's specification
> > <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> an "OTR Query
> > Message" must consint of "?OTR" followed by an indications of what
> > version of OTR is supported. A quote from the specification is:
> > "These strings may be hidden from the user (for example, in an
> attribute
> > of an HTML tag), and/or may be accompanied by an explanitory
message
> > ("Alice has requested an Off-the-Record private conversation.").
> If Bob
> > is willing to use OTR with Alice (with a protocol version that
> Alice has
> > offered), he should start the AKE."
> >
> > What this means is that it's perfectly normal for Bob to send
> Alice the
> > following:
> > *<p>?OTRv23?*
> > *<span style="font-weight: bold;">m.dzhigarov1@jit.si/
> <http://m.dzhigarov1@jit.si/>
> > <http://m.dzhigarov1@jit.si/></span> has requested an <a
> > href="http://otr.cypherpunks.ca/">Off-the-Record private
> > conversation</a>. However, you do not have a plugin to support
that.*
> > *See <a
> href="http://otr.cypherpunks.ca/">http://otr.cypherpunks.ca/</a>
> > for more information.</p>*
> > *
> > *
> > In fact... this is exactly what an Adium/Pidgin user sends when
> > initiating OTR sessions. If you look at the code here
> >
> <
https://github.com/jitsi/otr4j/blob/master/src/main/java/net/java/otr4j/io/SerializationUtils.java#L229
>,
> > obviously, s.indexOf(SerializationConstants.HEAD) != 0) will
> return 3 in
> > this scenario.
> > The result is - this message is going to be processed as a simple
> > PlainTextMessage, instead of QueryMessage, and OTR session will
not be
> > initialized.
> > This is why Adium/Pidgin users can not start OTR sessions with
Jitsi
> > users (the other way around is possible).
> >
> > I haven't thought on how to fix this but my guess is that it won't
be
> > very hard.
> >
> > What are your thoughts on this one? Do you prefer me to fix this
or do
> > you wish to do it yourself?
>
> You're right again, I opened issue #5 on Github. I'll have a look
> tomorrow.
>
> Regards,
> George
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#13

Hello Marin,

George, I have just one final concern. How do you feel about
changing net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
net.java.otr4j.OtrEngineHost.getFallbackMessage() signatures to have
SessionID for a parameter? This would allow for more flexibility when
sending error messages to the remote party. For example Alice can send
Bob the following ERROR_MESSAGE:
"You sent Alice an unreadable encrypted message. Please end you private
conversation with Alice or refresh it."

I feel that right now it is not very clear who sent what when it comes
to error messages in the OTR.
Of'course this is just a minor thing and can be ignored. I just feel
that it would be less confusing for the users.

It sounds like a good idea. Please, feel free to modify otr4j accordingly.

Anyway, please review my latest patch and if you have any concerns feel
free to message me.

It works pretty good, you did a neat job. A minor issue I noticed is
this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
those two parties have established an **authenticated** session. If
Alice chooses to Reauthenticate Bob (selects the appropriate menu item
in Pidgin), but then she changes her mind and presses the cancel button,
then an "Authentication failed!" message will popup for Bob (running
Jitsi).

Technically speaking, the authentication didn't fail, it was aborted and
the session remains in it's previous state (authenticated in the above
example). So I don't think we display that particular message to the
user. Pidgin, in fact, does nothing in that case.

Another thing is that we're missing an authentication option. A question
is optional when initiating SMP. That's why in Pidgin there are 3 options :

- Question and answer
- Shared secret (the one missing from Jitsi)
- Manual fingerprint verification

I hope this makes sense.

Cheers,
George


#14

It sounds like a good idea. Please, feel free to modify otr4j accordingly.

Thanks, I will!

A minor issue I noticed is

this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
those two parties have established an **authenticated** session. If
Alice chooses to Reauthenticate Bob (selects the appropriate menu item
in Pidgin), but then she changes her mind and presses the cancel button,
then an "Authentication failed!" message will popup for Bob (running
Jitsi).
Technically speaking, the authentication didn't fail, it was aborted and
the session remains in it's previous state (authenticated in the above
example). So I don't think we display that particular message to the
user. Pidgin, in fact, does nothing in that case.

Well... I think it's Pidgin's fault for sending "abort smp" message to us
when the cancel button is clicked over an authenticated session. I think
Jitsi's UI is acting accordingly.
What do the others think?

Another thing is that we're missing an authentication option. A question

is optional when initiating SMP. That's why in Pidgin there are 3 options :
- Question and answer
- Shared secret (the one missing from Jitsi)
- Manual fingerprint verification

I don't see what's the point of the "Shared secret" option. I know Pidgin
has it and I find it useless. If the user does not want to write a question
to authenticate then he may simply leave the question field empty. In fact,
in Pidgin if Alice choose the "Shared secret" option then Bob will see the
same pop-up dialog like in "Question and answer" but with empty question
field.

Regards,
Marin

···

On Sat, Nov 2, 2013 at 3:07 AM, George Politis <666f6f@gmail.com> wrote:

Hello Marin,

> George, I have just one final concern. How do you feel about
> changing net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
> net.java.otr4j.OtrEngineHost.getFallbackMessage() signatures to have
> SessionID for a parameter? This would allow for more flexibility when
> sending error messages to the remote party. For example Alice can send
> Bob the following ERROR_MESSAGE:
> "You sent Alice an unreadable encrypted message. Please end you private
> conversation with Alice or refresh it."
>
> I feel that right now it is not very clear who sent what when it comes
> to error messages in the OTR.
> Of'course this is just a minor thing and can be ignored. I just feel
> that it would be less confusing for the users.

It sounds like a good idea. Please, feel free to modify otr4j accordingly.

> Anyway, please review my latest patch and if you have any concerns feel
> free to message me.

It works pretty good, you did a neat job. A minor issue I noticed is
this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
those two parties have established an **authenticated** session. If
Alice chooses to Reauthenticate Bob (selects the appropriate menu item
in Pidgin), but then she changes her mind and presses the cancel button,
then an "Authentication failed!" message will popup for Bob (running
Jitsi).

Technically speaking, the authentication didn't fail, it was aborted and
the session remains in it's previous state (authenticated in the above
example). So I don't think we display that particular message to the
user. Pidgin, in fact, does nothing in that case.

Another thing is that we're missing an authentication option. A question
is optional when initiating SMP. That's why in Pidgin there are 3 options :

- Question and answer
- Shared secret (the one missing from Jitsi)
- Manual fingerprint verification

I hope this makes sense.

Cheers,
George

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#15

Hello,

A minor issue I noticed is

this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
those two parties have established an **authenticated** session. If
Alice chooses to Reauthenticate Bob (selects the appropriate menu item
in Pidgin), but then she changes her mind and presses the cancel button,
then an "Authentication failed!" message will popup for Bob (running
Jitsi).
Technically speaking, the authentication didn't fail, it was aborted and
the session remains in it's previous state (authenticated in the above
example). So I don't think we display that particular message to the
user. Pidgin, in fact, does nothing in that case.
Well... I think it's Pidgin's fault for sending "abort smp" message to us
when the cancel button is clicked over an authenticated session. I think
Jitsi's UI is acting accordingly.

George, I gave it a second though and I think you were right. Even though I
still think it is Pidgin's fault for sending "abort smp", it may be best
for us to act accordingly and not to show the 'auth failed' dialog when we
already are on an authenticated session.

Thanks again for the gread review!

Regards,
Marin

···

On Mon, Nov 4, 2013 at 10:39 AM, Marin Dzhigarov <marin@bluejimp.com> wrote:

It sounds like a good idea. Please, feel free to modify otr4j accordingly.

Thanks, I will!

A minor issue I noticed is

this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
those two parties have established an **authenticated** session. If
Alice chooses to Reauthenticate Bob (selects the appropriate menu item
in Pidgin), but then she changes her mind and presses the cancel button,
then an "Authentication failed!" message will popup for Bob (running
Jitsi).
Technically speaking, the authentication didn't fail, it was aborted and
the session remains in it's previous state (authenticated in the above
example). So I don't think we display that particular message to the
user. Pidgin, in fact, does nothing in that case.

Well... I think it's Pidgin's fault for sending "abort smp" message to us
when the cancel button is clicked over an authenticated session. I think
Jitsi's UI is acting accordingly.
What do the others think?

Another thing is that we're missing an authentication option. A question

is optional when initiating SMP. That's why in Pidgin there are 3 options
:
- Question and answer
- Shared secret (the one missing from Jitsi)
- Manual fingerprint verification

I don't see what's the point of the "Shared secret" option. I know Pidgin
has it and I find it useless. If the user does not want to write a question
to authenticate then he may simply leave the question field empty. In fact,
in Pidgin if Alice choose the "Shared secret" option then Bob will see the
same pop-up dialog like in "Question and answer" but with empty question
field.

Regards,
Marin

On Sat, Nov 2, 2013 at 3:07 AM, George Politis <666f6f@gmail.com> wrote:

Hello Marin,

> George, I have just one final concern. How do you feel about
> changing net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
> net.java.otr4j.OtrEngineHost.getFallbackMessage() signatures to have
> SessionID for a parameter? This would allow for more flexibility when
> sending error messages to the remote party. For example Alice can send
> Bob the following ERROR_MESSAGE:
> "You sent Alice an unreadable encrypted message. Please end you private
> conversation with Alice or refresh it."
>
> I feel that right now it is not very clear who sent what when it comes
> to error messages in the OTR.
> Of'course this is just a minor thing and can be ignored. I just feel
> that it would be less confusing for the users.

It sounds like a good idea. Please, feel free to modify otr4j accordingly.

> Anyway, please review my latest patch and if you have any concerns feel
> free to message me.

It works pretty good, you did a neat job. A minor issue I noticed is
this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
those two parties have established an **authenticated** session. If
Alice chooses to Reauthenticate Bob (selects the appropriate menu item
in Pidgin), but then she changes her mind and presses the cancel button,
then an "Authentication failed!" message will popup for Bob (running
Jitsi).

Technically speaking, the authentication didn't fail, it was aborted and
the session remains in it's previous state (authenticated in the above
example). So I don't think we display that particular message to the
user. Pidgin, in fact, does nothing in that case.

Another thing is that we're missing an authentication option. A question
is optional when initiating SMP. That's why in Pidgin there are 3 options
:

- Question and answer
- Shared secret (the one missing from Jitsi)
- Manual fingerprint verification

I hope this makes sense.

Cheers,
George

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#16

Hello Marin,

I understand what you say and that you'd like to do some things
differently :slight_smile: but in this case you can't, because we have to follow the
spec as closely as possible. For example, it is explicitly mentioned (in
the spec) that the remote client may send an SMP abort message, if the
user cancels SMP prematurely; so Pidgin can't be wrong to send an SMP
abort message, if the user presses the cancel button.

Same goes for the "shared secret" authentication option (the one missing
from Jitsi). Yeah, maybe it is redundant for the protocol to work
correctly but if it's in the spec, we must implement it. Upon further
thought, SMP was specifically designed to be a user friendly mechanism
for the user to authenticate his/her contacts. So, we are specifically
concerned about the user experience here. Given that as a fact, all
implementations should provide the same consistent set of features.

That said, those are some minor issues, as I mentioned in my previous
email. I really mean that! I'm sure you'd agree with me that the real
beauty of the OTR protocol is in the math behind it :slight_smile: So we shouldn't
let ourselves get distracted by some minor details.

Cheers,
George

···

On 11/04/2013 12:17 PM, Marin Dzhigarov wrote:

Hello,

    A minor issue I noticed is

        this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
        those two parties have established an **authenticated** session. If
        Alice chooses to Reauthenticate Bob (selects the appropriate
        menu item
        in Pidgin), but then she changes her mind and presses the cancel
        button,
        then an "Authentication failed!" message will popup for Bob (running
        Jitsi).
        Technically speaking, the authentication didn't fail, it was
        aborted and
        the session remains in it's previous state (authenticated in the
        above
        example). So I don't think we display that particular message to the
        user. Pidgin, in fact, does nothing in that case.
        Well... I think it's Pidgin's fault for sending "abort smp"
        message to us when the cancel button is clicked over an
        authenticated session. I think Jitsi's UI is acting accordingly.

George, I gave it a second though and I think you were right. Even
though I still think it is Pidgin's fault for sending "abort smp", it
may be best for us to act accordingly and not to show the 'auth failed'
dialog when we already are on an authenticated session.

Thanks again for the gread review!

Regards,
Marin

On Mon, Nov 4, 2013 at 10:39 AM, Marin Dzhigarov <marin@bluejimp.com > <mailto:marin@bluejimp.com>> wrote:

        It sounds like a good idea. Please, feel free to modify otr4j
        accordingly.

    Thanks, I will!

        A minor issue I noticed is
        this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
        those two parties have established an **authenticated** session. If
        Alice chooses to Reauthenticate Bob (selects the appropriate
        menu item
        in Pidgin), but then she changes her mind and presses the cancel
        button,
        then an "Authentication failed!" message will popup for Bob (running
        Jitsi).
        Technically speaking, the authentication didn't fail, it was
        aborted and
        the session remains in it's previous state (authenticated in the
        above
        example). So I don't think we display that particular message to the
        user. Pidgin, in fact, does nothing in that case.

    Well... I think it's Pidgin's fault for sending "abort smp" message
    to us when the cancel button is clicked over an authenticated
    session. I think Jitsi's UI is acting accordingly.
    What do the others think?

        Another thing is that we're missing an authentication option. A
        question
        is optional when initiating SMP. That's why in Pidgin there are
        3 options :
        - Question and answer
        - Shared secret (the one missing from Jitsi)
        - Manual fingerprint verification

    I don't see what's the point of the "Shared secret" option. I know
    Pidgin has it and I find it useless. If the user does not want to
    write a question to authenticate then he may simply leave the
    question field empty. In fact, in Pidgin if Alice choose the "Shared
    secret" option then Bob will see the same pop-up dialog like in
    "Question and answer" but with empty question field.

    Regards,
    Marin

    On Sat, Nov 2, 2013 at 3:07 AM, George Politis <666f6f@gmail.com > <mailto:666f6f@gmail.com>> wrote:

        Hello Marin,

        > George, I have just one final concern. How do you feel about
        > changing
        net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
        > net.java.otr4j.OtrEngineHost.getFallbackMessage() signatures
        to have
        > SessionID for a parameter? This would allow for more
        flexibility when
        > sending error messages to the remote party. For example Alice
        can send
        > Bob the following ERROR_MESSAGE:
        > "You sent Alice an unreadable encrypted message. Please end
        you private
        > conversation with Alice or refresh it."
        >
        > I feel that right now it is not very clear who sent what when
        it comes
        > to error messages in the OTR.
        > Of'course this is just a minor thing and can be ignored. I
        just feel
        > that it would be less confusing for the users.

        It sounds like a good idea. Please, feel free to modify otr4j
        accordingly.

        > Anyway, please review my latest patch and if you have any
        concerns feel
        > free to message me.

        It works pretty good, you did a neat job. A minor issue I noticed is
        this : Suppose Alice is using Pidgin and Bob is using Jitsi and that
        those two parties have established an **authenticated** session. If
        Alice chooses to Reauthenticate Bob (selects the appropriate
        menu item
        in Pidgin), but then she changes her mind and presses the cancel
        button,
        then an "Authentication failed!" message will popup for Bob (running
        Jitsi).

        Technically speaking, the authentication didn't fail, it was
        aborted and
        the session remains in it's previous state (authenticated in the
        above
        example). So I don't think we display that particular message to the
        user. Pidgin, in fact, does nothing in that case.

        Another thing is that we're missing an authentication option. A
        question
        is optional when initiating SMP. That's why in Pidgin there are
        3 options :

        - Question and answer
        - Shared secret (the one missing from Jitsi)
        - Manual fingerprint verification

        I hope this makes sense.

        Cheers,
        George

        _______________________________________________
        dev mailing list
        dev@jitsi.org <mailto:dev@jitsi.org>
        Unsubscribe instructions and other list options:
        http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#17

Hello all,

I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
otr4j.patch<https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing>is
for otr4j's.

As discussed, I added the "shared secret" authentication to the
authentication panel (screenshot attached).

George, I also added otr4j.session.Session.isSmpInProgress() method to the
otr4j.jar that checks whether smp negotiation is currently in progress. Can
you please review the changes I've made so far in the
otr4j.patch<https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing>
and
if everything is ok then may be we can commit them?

Thanks!

Regards,
Marin

jitsiOTR.patch (193 KB)

···

On Tue, Nov 5, 2013 at 11:04 AM, Marin Dzhigarov <marin@bluejimp.com> wrote:

Hello all,

I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
otr4j.patch is for otr4j's.

As discussed, I added the "shared secret" authentication to the
authentication panel (screenshot attached).

George, I also added otr4j.session.Session.isSmpInProgress() method to the
otr4j.jar that checks whether smp negotiation is currently in progress. Can
you please review the changes I've made so far to the otr4j.jar and if
everything is ok then we can commit them?

Thanks!

Regards,
Marin

On Mon, Nov 4, 2013 at 8:23 PM, George Politis <666f6f@gmail.com> wrote:

Hello Marin,

I understand what you say and that you'd like to do some things
differently :slight_smile: but in this case you can't, because we have to follow the
spec as closely as possible. For example, it is explicitly mentioned (in
the spec) that the remote client may send an SMP abort message, if the
user cancels SMP prematurely; so Pidgin can't be wrong to send an SMP
abort message, if the user presses the cancel button.

Same goes for the "shared secret" authentication option (the one missing
from Jitsi). Yeah, maybe it is redundant for the protocol to work
correctly but if it's in the spec, we must implement it. Upon further
thought, SMP was specifically designed to be a user friendly mechanism
for the user to authenticate his/her contacts. So, we are specifically
concerned about the user experience here. Given that as a fact, all
implementations should provide the same consistent set of features.

That said, those are some minor issues, as I mentioned in my previous
email. I really mean that! I'm sure you'd agree with me that the real
beauty of the OTR protocol is in the math behind it :slight_smile: So we shouldn't
let ourselves get distracted by some minor details.

Cheers,
George

On 11/04/2013 12:17 PM, Marin Dzhigarov wrote:
> Hello,
>
> A minor issue I noticed is
>
> this : Suppose Alice is using Pidgin and Bob is using Jitsi and
that
> those two parties have established an **authenticated**
session. If
> Alice chooses to Reauthenticate Bob (selects the appropriate
> menu item
> in Pidgin), but then she changes her mind and presses the cancel
> button,
> then an "Authentication failed!" message will popup for Bob
(running
> Jitsi).
> Technically speaking, the authentication didn't fail, it was
> aborted and
> the session remains in it's previous state (authenticated in the
> above
> example). So I don't think we display that particular message
to the
> user. Pidgin, in fact, does nothing in that case.
> Well... I think it's Pidgin's fault for sending "abort smp"
> message to us when the cancel button is clicked over an
> authenticated session. I think Jitsi's UI is acting accordingly.
>
>
> George, I gave it a second though and I think you were right. Even
> though I still think it is Pidgin's fault for sending "abort smp", it
> may be best for us to act accordingly and not to show the 'auth failed'
> dialog when we already are on an authenticated session.
>
> Thanks again for the gread review!
>
> Regards,
> Marin
>
>
> On Mon, Nov 4, 2013 at 10:39 AM, Marin Dzhigarov <marin@bluejimp.com >> > <mailto:marin@bluejimp.com>> wrote:
>
> It sounds like a good idea. Please, feel free to modify otr4j
> accordingly.
>
> Thanks, I will!
>
>
> A minor issue I noticed is
> this : Suppose Alice is using Pidgin and Bob is using Jitsi and
that
> those two parties have established an **authenticated**
session. If
> Alice chooses to Reauthenticate Bob (selects the appropriate
> menu item
> in Pidgin), but then she changes her mind and presses the cancel
> button,
> then an "Authentication failed!" message will popup for Bob
(running
> Jitsi).
> Technically speaking, the authentication didn't fail, it was
> aborted and
> the session remains in it's previous state (authenticated in the
> above
> example). So I don't think we display that particular message
to the
> user. Pidgin, in fact, does nothing in that case.
>
> Well... I think it's Pidgin's fault for sending "abort smp" message
> to us when the cancel button is clicked over an authenticated
> session. I think Jitsi's UI is acting accordingly.
> What do the others think?
>
> Another thing is that we're missing an authentication option. A
> question
> is optional when initiating SMP. That's why in Pidgin there are
> 3 options :
> - Question and answer
> - Shared secret (the one missing from Jitsi)
> - Manual fingerprint verification
>
>
> I don't see what's the point of the "Shared secret" option. I know
> Pidgin has it and I find it useless. If the user does not want to
> write a question to authenticate then he may simply leave the
> question field empty. In fact, in Pidgin if Alice choose the "Shared
> secret" option then Bob will see the same pop-up dialog like in
> "Question and answer" but with empty question field.
>
> Regards,
> Marin
>
>
> On Sat, Nov 2, 2013 at 3:07 AM, George Politis <666f6f@gmail.com >> > <mailto:666f6f@gmail.com>> wrote:
>
> Hello Marin,
>
> > George, I have just one final concern. How do you feel about
> > changing
> net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
> > net.java.otr4j.OtrEngineHost.getFallbackMessage() signatures
> to have
> > SessionID for a parameter? This would allow for more
> flexibility when
> > sending error messages to the remote party. For example Alice
> can send
> > Bob the following ERROR_MESSAGE:
> > "You sent Alice an unreadable encrypted message. Please end
> you private
> > conversation with Alice or refresh it."
> >
> > I feel that right now it is not very clear who sent what when
> it comes
> > to error messages in the OTR.
> > Of'course this is just a minor thing and can be ignored. I
> just feel
> > that it would be less confusing for the users.
>
> It sounds like a good idea. Please, feel free to modify otr4j
> accordingly.
>
> > Anyway, please review my latest patch and if you have any
> concerns feel
> > free to message me.
>
> It works pretty good, you did a neat job. A minor issue I
noticed is
> this : Suppose Alice is using Pidgin and Bob is using Jitsi and
that
> those two parties have established an **authenticated**
session. If
> Alice chooses to Reauthenticate Bob (selects the appropriate
> menu item
> in Pidgin), but then she changes her mind and presses the cancel
> button,
> then an "Authentication failed!" message will popup for Bob
(running
> Jitsi).
>
> Technically speaking, the authentication didn't fail, it was
> aborted and
> the session remains in it's previous state (authenticated in the
> above
> example). So I don't think we display that particular message
to the
> user. Pidgin, in fact, does nothing in that case.
>
> Another thing is that we're missing an authentication option. A
> question
> is optional when initiating SMP. That's why in Pidgin there are
> 3 options :
>
> - Question and answer
> - Shared secret (the one missing from Jitsi)
> - Manual fingerprint verification
>
> I hope this makes sense.
>
> Cheers,
> George
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#18

Hey Marin, thanks for the updated patch! It looks good now. Can you
please open a pull request on Github so that I can merge your changes
into the Jitsi master branch?

Thanks,
George

···

On 11/05/2013 11:24 AM, Marin Dzhigarov wrote:

Hello all,

I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
otr4j.patch
<https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing>
is for otr4j's.

As discussed, I added the "shared secret" authentication to the
authentication panel (screenshot attached).

George, I also added otr4j.session.Session.isSmpInProgress() method to
the otr4j.jar that checks whether smp negotiation is currently in
progress. Can you please review the changes I've made so far in
the otr4j.patch
<https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing> and
if everything is ok then may be we can commit them?

Thanks!

Regards,
Marin

On Tue, Nov 5, 2013 at 11:04 AM, Marin Dzhigarov <marin@bluejimp.com > <mailto:marin@bluejimp.com>> wrote:

    Hello all,

    I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
    otr4j.patch is for otr4j's.

    As discussed, I added the "shared secret" authentication to the
    authentication panel (screenshot attached).

    George, I also added otr4j.session.Session.isSmpInProgress() method
    to the otr4j.jar that checks whether smp negotiation is currently in
    progress. Can you please review the changes I've made so far to the
    otr4j.jar and if everything is ok then we can commit them?

    Thanks!

    Regards,
    Marin

    On Mon, Nov 4, 2013 at 8:23 PM, George Politis <666f6f@gmail.com > <mailto:666f6f@gmail.com>> wrote:

        Hello Marin,

        I understand what you say and that you'd like to do some things
        differently :slight_smile: but in this case you can't, because we have to
        follow the
        spec as closely as possible. For example, it is explicitly
        mentioned (in
        the spec) that the remote client may send an SMP abort message,
        if the
        user cancels SMP prematurely; so Pidgin can't be wrong to send
        an SMP
        abort message, if the user presses the cancel button.

        Same goes for the "shared secret" authentication option (the one
        missing
        from Jitsi). Yeah, maybe it is redundant for the protocol to work
        correctly but if it's in the spec, we must implement it. Upon
        further
        thought, SMP was specifically designed to be a user friendly
        mechanism
        for the user to authenticate his/her contacts. So, we are
        specifically
        concerned about the user experience here. Given that as a fact, all
        implementations should provide the same consistent set of features.

        That said, those are some minor issues, as I mentioned in my
        previous
        email. I really mean that! I'm sure you'd agree with me that the
        real
        beauty of the OTR protocol is in the math behind it :slight_smile: So we
        shouldn't
        let ourselves get distracted by some minor details.

        Cheers,
        George

        On 11/04/2013 12:17 PM, Marin Dzhigarov wrote:
        > Hello,
        >
        > A minor issue I noticed is
        >
        > this : Suppose Alice is using Pidgin and Bob is using
        Jitsi and that
        > those two parties have established an
        **authenticated** session. If
        > Alice chooses to Reauthenticate Bob (selects the
        appropriate
        > menu item
        > in Pidgin), but then she changes her mind and presses
        the cancel
        > button,
        > then an "Authentication failed!" message will popup
        for Bob (running
        > Jitsi).
        > Technically speaking, the authentication didn't fail,
        it was
        > aborted and
        > the session remains in it's previous state
        (authenticated in the
        > above
        > example). So I don't think we display that particular
        message to the
        > user. Pidgin, in fact, does nothing in that case.
        > Well... I think it's Pidgin's fault for sending "abort
        smp"
        > message to us when the cancel button is clicked over an
        > authenticated session. I think Jitsi's UI is acting
        accordingly.
        >
        >
        > George, I gave it a second though and I think you were right. Even
        > though I still think it is Pidgin's fault for sending "abort
        smp", it
        > may be best for us to act accordingly and not to show the
        'auth failed'
        > dialog when we already are on an authenticated session.
        >
        > Thanks again for the gread review!
        >
        > Regards,
        > Marin
        >
        >
        > On Mon, Nov 4, 2013 at 10:39 AM, Marin Dzhigarov > <marin@bluejimp.com <mailto:marin@bluejimp.com> > > <mailto:marin@bluejimp.com <mailto:marin@bluejimp.com>>> wrote:
        >
        > It sounds like a good idea. Please, feel free to
        modify otr4j
        > accordingly.
        >
        > Thanks, I will!
        >
        >
        > A minor issue I noticed is
        > this : Suppose Alice is using Pidgin and Bob is using
        Jitsi and that
        > those two parties have established an
        **authenticated** session. If
        > Alice chooses to Reauthenticate Bob (selects the
        appropriate
        > menu item
        > in Pidgin), but then she changes her mind and presses
        the cancel
        > button,
        > then an "Authentication failed!" message will popup
        for Bob (running
        > Jitsi).
        > Technically speaking, the authentication didn't fail,
        it was
        > aborted and
        > the session remains in it's previous state
        (authenticated in the
        > above
        > example). So I don't think we display that particular
        message to the
        > user. Pidgin, in fact, does nothing in that case.
        >
        > Well... I think it's Pidgin's fault for sending "abort
        smp" message
        > to us when the cancel button is clicked over an authenticated
        > session. I think Jitsi's UI is acting accordingly.
        > What do the others think?
        >
        > Another thing is that we're missing an authentication
        option. A
        > question
        > is optional when initiating SMP. That's why in Pidgin
        there are
        > 3 options :
        > - Question and answer
        > - Shared secret (the one missing from Jitsi)
        > - Manual fingerprint verification
        >
        >
        > I don't see what's the point of the "Shared secret"
        option. I know
        > Pidgin has it and I find it useless. If the user does not
        want to
        > write a question to authenticate then he may simply leave the
        > question field empty. In fact, in Pidgin if Alice choose
        the "Shared
        > secret" option then Bob will see the same pop-up dialog
        like in
        > "Question and answer" but with empty question field.
        >
        > Regards,
        > Marin
        >
        >
        > On Sat, Nov 2, 2013 at 3:07 AM, George Politis > <666f6f@gmail.com <mailto:666f6f@gmail.com> > > <mailto:666f6f@gmail.com <mailto:666f6f@gmail.com>>> wrote:
        >
        > Hello Marin,
        >
        > > George, I have just one final concern. How do you
        feel about
        > > changing
        >
        net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
        > > net.java.otr4j.OtrEngineHost.getFallbackMessage()
        signatures
        > to have
        > > SessionID for a parameter? This would allow for more
        > flexibility when
        > > sending error messages to the remote party. For
        example Alice
        > can send
        > > Bob the following ERROR_MESSAGE:
        > > "You sent Alice an unreadable encrypted message.
        Please end
        > you private
        > > conversation with Alice or refresh it."
        > >
        > > I feel that right now it is not very clear who sent
        what when
        > it comes
        > > to error messages in the OTR.
        > > Of'course this is just a minor thing and can be
        ignored. I
        > just feel
        > > that it would be less confusing for the users.
        >
        > It sounds like a good idea. Please, feel free to
        modify otr4j
        > accordingly.
        >
        > > Anyway, please review my latest patch and if you
        have any
        > concerns feel
        > > free to message me.
        >
        > It works pretty good, you did a neat job. A minor
        issue I noticed is
        > this : Suppose Alice is using Pidgin and Bob is using
        Jitsi and that
        > those two parties have established an
        **authenticated** session. If
        > Alice chooses to Reauthenticate Bob (selects the
        appropriate
        > menu item
        > in Pidgin), but then she changes her mind and presses
        the cancel
        > button,
        > then an "Authentication failed!" message will popup
        for Bob (running
        > Jitsi).
        >
        > Technically speaking, the authentication didn't fail,
        it was
        > aborted and
        > the session remains in it's previous state
        (authenticated in the
        > above
        > example). So I don't think we display that particular
        message to the
        > user. Pidgin, in fact, does nothing in that case.
        >
        > Another thing is that we're missing an authentication
        option. A
        > question
        > is optional when initiating SMP. That's why in Pidgin
        there are
        > 3 options :
        >
        > - Question and answer
        > - Shared secret (the one missing from Jitsi)
        > - Manual fingerprint verification
        >
        > I hope this makes sense.
        >
        > Cheers,
        > George
        >
        > _______________________________________________
        > dev mailing list
        > dev@jitsi.org <mailto:dev@jitsi.org>
        <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
        > Unsubscribe instructions and other list options:
        > http://lists.jitsi.org/mailman/listinfo/dev
        >
        >
        >
        >
        >
        > _______________________________________________
        > dev mailing list
        > dev@jitsi.org <mailto:dev@jitsi.org>
        > Unsubscribe instructions and other list options:
        > http://lists.jitsi.org/mailman/listinfo/dev
        >

        _______________________________________________
        dev mailing list
        dev@jitsi.org <mailto:dev@jitsi.org>
        Unsubscribe instructions and other list options:
        http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#19

Hey Marin,

Thanks for the new patch, it looks great. Here are a few more
suggestions, mostly housekeeping:

- Javadoc : @link http:.. is not a valid syntax for the @link
annotation. @link should be followed by a link to a symbol
(class/interface/etc); not a url. Use this instead :
@see <a href="http://www.google.com">Google</a>.

- Move the SmpAuthenticateBuddyDialog in its own code file. You may also
create a "...plugin.otr.authdialog" package and move all the relevant
classes there, if you want to.

- Reduce unnecessary changes to FingerprintAuthenticationPanel.java. The
diff is way too much noisy : superfluous getters/setters (see cbAction)
and unnecessary code rearrangements generate bogus diff lines that make
it difficult to follow your changes.

I think the patch should be ready for integration after that. Thanks!

Cheers,
George

···

On 11/05/2013 11:24 AM, Marin Dzhigarov wrote:

Hello all,

I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
otr4j.patch
<https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing>
is for otr4j's.

As discussed, I added the "shared secret" authentication to the
authentication panel (screenshot attached).

George, I also added otr4j.session.Session.isSmpInProgress() method to
the otr4j.jar that checks whether smp negotiation is currently in
progress. Can you please review the changes I've made so far in
the otr4j.patch
<https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing> and
if everything is ok then may be we can commit them?

Thanks!

Regards,
Marin

On Tue, Nov 5, 2013 at 11:04 AM, Marin Dzhigarov <marin@bluejimp.com > <mailto:marin@bluejimp.com>> wrote:

    Hello all,

    I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
    otr4j.patch is for otr4j's.

    As discussed, I added the "shared secret" authentication to the
    authentication panel (screenshot attached).

    George, I also added otr4j.session.Session.isSmpInProgress() method
    to the otr4j.jar that checks whether smp negotiation is currently in
    progress. Can you please review the changes I've made so far to the
    otr4j.jar and if everything is ok then we can commit them?

    Thanks!

    Regards,
    Marin

    On Mon, Nov 4, 2013 at 8:23 PM, George Politis <666f6f@gmail.com > <mailto:666f6f@gmail.com>> wrote:

        Hello Marin,

        I understand what you say and that you'd like to do some things
        differently :slight_smile: but in this case you can't, because we have to
        follow the
        spec as closely as possible. For example, it is explicitly
        mentioned (in
        the spec) that the remote client may send an SMP abort message,
        if the
        user cancels SMP prematurely; so Pidgin can't be wrong to send
        an SMP
        abort message, if the user presses the cancel button.

        Same goes for the "shared secret" authentication option (the one
        missing
        from Jitsi). Yeah, maybe it is redundant for the protocol to work
        correctly but if it's in the spec, we must implement it. Upon
        further
        thought, SMP was specifically designed to be a user friendly
        mechanism
        for the user to authenticate his/her contacts. So, we are
        specifically
        concerned about the user experience here. Given that as a fact, all
        implementations should provide the same consistent set of features.

        That said, those are some minor issues, as I mentioned in my
        previous
        email. I really mean that! I'm sure you'd agree with me that the
        real
        beauty of the OTR protocol is in the math behind it :slight_smile: So we
        shouldn't
        let ourselves get distracted by some minor details.

        Cheers,
        George

        On 11/04/2013 12:17 PM, Marin Dzhigarov wrote:
        > Hello,
        >
        > A minor issue I noticed is
        >
        > this : Suppose Alice is using Pidgin and Bob is using
        Jitsi and that
        > those two parties have established an
        **authenticated** session. If
        > Alice chooses to Reauthenticate Bob (selects the
        appropriate
        > menu item
        > in Pidgin), but then she changes her mind and presses
        the cancel
        > button,
        > then an "Authentication failed!" message will popup
        for Bob (running
        > Jitsi).
        > Technically speaking, the authentication didn't fail,
        it was
        > aborted and
        > the session remains in it's previous state
        (authenticated in the
        > above
        > example). So I don't think we display that particular
        message to the
        > user. Pidgin, in fact, does nothing in that case.
        > Well... I think it's Pidgin's fault for sending "abort
        smp"
        > message to us when the cancel button is clicked over an
        > authenticated session. I think Jitsi's UI is acting
        accordingly.
        >
        >
        > George, I gave it a second though and I think you were right. Even
        > though I still think it is Pidgin's fault for sending "abort
        smp", it
        > may be best for us to act accordingly and not to show the
        'auth failed'
        > dialog when we already are on an authenticated session.
        >
        > Thanks again for the gread review!
        >
        > Regards,
        > Marin
        >
        >
        > On Mon, Nov 4, 2013 at 10:39 AM, Marin Dzhigarov > <marin@bluejimp.com <mailto:marin@bluejimp.com> > > <mailto:marin@bluejimp.com <mailto:marin@bluejimp.com>>> wrote:
        >
        > It sounds like a good idea. Please, feel free to
        modify otr4j
        > accordingly.
        >
        > Thanks, I will!
        >
        >
        > A minor issue I noticed is
        > this : Suppose Alice is using Pidgin and Bob is using
        Jitsi and that
        > those two parties have established an
        **authenticated** session. If
        > Alice chooses to Reauthenticate Bob (selects the
        appropriate
        > menu item
        > in Pidgin), but then she changes her mind and presses
        the cancel
        > button,
        > then an "Authentication failed!" message will popup
        for Bob (running
        > Jitsi).
        > Technically speaking, the authentication didn't fail,
        it was
        > aborted and
        > the session remains in it's previous state
        (authenticated in the
        > above
        > example). So I don't think we display that particular
        message to the
        > user. Pidgin, in fact, does nothing in that case.
        >
        > Well... I think it's Pidgin's fault for sending "abort
        smp" message
        > to us when the cancel button is clicked over an authenticated
        > session. I think Jitsi's UI is acting accordingly.
        > What do the others think?
        >
        > Another thing is that we're missing an authentication
        option. A
        > question
        > is optional when initiating SMP. That's why in Pidgin
        there are
        > 3 options :
        > - Question and answer
        > - Shared secret (the one missing from Jitsi)
        > - Manual fingerprint verification
        >
        >
        > I don't see what's the point of the "Shared secret"
        option. I know
        > Pidgin has it and I find it useless. If the user does not
        want to
        > write a question to authenticate then he may simply leave the
        > question field empty. In fact, in Pidgin if Alice choose
        the "Shared
        > secret" option then Bob will see the same pop-up dialog
        like in
        > "Question and answer" but with empty question field.
        >
        > Regards,
        > Marin
        >
        >
        > On Sat, Nov 2, 2013 at 3:07 AM, George Politis > <666f6f@gmail.com <mailto:666f6f@gmail.com> > > <mailto:666f6f@gmail.com <mailto:666f6f@gmail.com>>> wrote:
        >
        > Hello Marin,
        >
        > > George, I have just one final concern. How do you
        feel about
        > > changing
        >
        net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
        > > net.java.otr4j.OtrEngineHost.getFallbackMessage()
        signatures
        > to have
        > > SessionID for a parameter? This would allow for more
        > flexibility when
        > > sending error messages to the remote party. For
        example Alice
        > can send
        > > Bob the following ERROR_MESSAGE:
        > > "You sent Alice an unreadable encrypted message.
        Please end
        > you private
        > > conversation with Alice or refresh it."
        > >
        > > I feel that right now it is not very clear who sent
        what when
        > it comes
        > > to error messages in the OTR.
        > > Of'course this is just a minor thing and can be
        ignored. I
        > just feel
        > > that it would be less confusing for the users.
        >
        > It sounds like a good idea. Please, feel free to
        modify otr4j
        > accordingly.
        >
        > > Anyway, please review my latest patch and if you
        have any
        > concerns feel
        > > free to message me.
        >
        > It works pretty good, you did a neat job. A minor
        issue I noticed is
        > this : Suppose Alice is using Pidgin and Bob is using
        Jitsi and that
        > those two parties have established an
        **authenticated** session. If
        > Alice chooses to Reauthenticate Bob (selects the
        appropriate
        > menu item
        > in Pidgin), but then she changes her mind and presses
        the cancel
        > button,
        > then an "Authentication failed!" message will popup
        for Bob (running
        > Jitsi).
        >
        > Technically speaking, the authentication didn't fail,
        it was
        > aborted and
        > the session remains in it's previous state
        (authenticated in the
        > above
        > example). So I don't think we display that particular
        message to the
        > user. Pidgin, in fact, does nothing in that case.
        >
        > Another thing is that we're missing an authentication
        option. A
        > question
        > is optional when initiating SMP. That's why in Pidgin
        there are
        > 3 options :
        >
        > - Question and answer
        > - Shared secret (the one missing from Jitsi)
        > - Manual fingerprint verification
        >
        > I hope this makes sense.
        >
        > Cheers,
        > George
        >
        > _______________________________________________
        > dev mailing list
        > dev@jitsi.org <mailto:dev@jitsi.org>
        <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
        > Unsubscribe instructions and other list options:
        > http://lists.jitsi.org/mailman/listinfo/dev
        >
        >
        >
        >
        >
        > _______________________________________________
        > dev mailing list
        > dev@jitsi.org <mailto:dev@jitsi.org>
        > Unsubscribe instructions and other list options:
        > http://lists.jitsi.org/mailman/listinfo/dev
        >

        _______________________________________________
        dev mailing list
        dev@jitsi.org <mailto:dev@jitsi.org>
        Unsubscribe instructions and other list options:
        http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#20

Hello George,

I commited fixes for everything mentioned.

Also, I plan to commit the padlock icon changes on a different branch so
I'll be making an additional pull request in the next few days.

Regards,
Marin

···

On Sat, Nov 9, 2013 at 3:11 AM, George Politis <666f6f@gmail.com> wrote:

Hey Marin,

Thanks for the new patch, it looks great. Here are a few more
suggestions, mostly housekeeping:

- Javadoc : @link http:.. is not a valid syntax for the @link
annotation. @link should be followed by a link to a symbol
(class/interface/etc); not a url. Use this instead :
@see <a href="http://www.google.com">Google</a>.

- Move the SmpAuthenticateBuddyDialog in its own code file. You may also
create a "...plugin.otr.authdialog" package and move all the relevant
classes there, if you want to.

- Reduce unnecessary changes to FingerprintAuthenticationPanel.java. The
diff is way too much noisy : superfluous getters/setters (see cbAction)
and unnecessary code rearrangements generate bogus diff lines that make
it difficult to follow your changes.

I think the patch should be ready for integration after that. Thanks!

Cheers,
George

On 11/05/2013 11:24 AM, Marin Dzhigarov wrote:
> Hello all,
>
> I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
> otr4j.patch
> <
https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing
>
> is for otr4j's.
>
> As discussed, I added the "shared secret" authentication to the
> authentication panel (screenshot attached).
>
> George, I also added otr4j.session.Session.isSmpInProgress() method to
> the otr4j.jar that checks whether smp negotiation is currently in
> progress. Can you please review the changes I've made so far in
> the otr4j.patch
> <
https://drive.google.com/file/d/0B8qrjQTbDPd3WHdid0FtOXRSX1k/edit?usp=sharing>
and
> if everything is ok then may be we can commit them?
>
> Thanks!
>
> Regards,
> Marin
>
>
> On Tue, Nov 5, 2013 at 11:04 AM, Marin Dzhigarov <marin@bluejimp.com > > <mailto:marin@bluejimp.com>> wrote:
>
> Hello all,
>
> I'm uploading two patches - jitsiOTR.patch is for Jitsi's repo and
> otr4j.patch is for otr4j's.
>
> As discussed, I added the "shared secret" authentication to the
> authentication panel (screenshot attached).
>
> George, I also added otr4j.session.Session.isSmpInProgress() method
> to the otr4j.jar that checks whether smp negotiation is currently in
> progress. Can you please review the changes I've made so far to the
> otr4j.jar and if everything is ok then we can commit them?
>
> Thanks!
>
> Regards,
> Marin
>
>
> On Mon, Nov 4, 2013 at 8:23 PM, George Politis <666f6f@gmail.com > > <mailto:666f6f@gmail.com>> wrote:
>
> Hello Marin,
>
> I understand what you say and that you'd like to do some things
> differently :slight_smile: but in this case you can't, because we have to
> follow the
> spec as closely as possible. For example, it is explicitly
> mentioned (in
> the spec) that the remote client may send an SMP abort message,
> if the
> user cancels SMP prematurely; so Pidgin can't be wrong to send
> an SMP
> abort message, if the user presses the cancel button.
>
> Same goes for the "shared secret" authentication option (the one
> missing
> from Jitsi). Yeah, maybe it is redundant for the protocol to work
> correctly but if it's in the spec, we must implement it. Upon
> further
> thought, SMP was specifically designed to be a user friendly
> mechanism
> for the user to authenticate his/her contacts. So, we are
> specifically
> concerned about the user experience here. Given that as a fact,
all
> implementations should provide the same consistent set of
features.
>
> That said, those are some minor issues, as I mentioned in my
> previous
> email. I really mean that! I'm sure you'd agree with me that the
> real
> beauty of the OTR protocol is in the math behind it :slight_smile: So we
> shouldn't
> let ourselves get distracted by some minor details.
>
> Cheers,
> George
>
> On 11/04/2013 12:17 PM, Marin Dzhigarov wrote:
> > Hello,
> >
> > A minor issue I noticed is
> >
> > this : Suppose Alice is using Pidgin and Bob is using
> Jitsi and that
> > those two parties have established an
> **authenticated** session. If
> > Alice chooses to Reauthenticate Bob (selects the
> appropriate
> > menu item
> > in Pidgin), but then she changes her mind and presses
> the cancel
> > button,
> > then an "Authentication failed!" message will popup
> for Bob (running
> > Jitsi).
> > Technically speaking, the authentication didn't fail,
> it was
> > aborted and
> > the session remains in it's previous state
> (authenticated in the
> > above
> > example). So I don't think we display that particular
> message to the
> > user. Pidgin, in fact, does nothing in that case.
> > Well... I think it's Pidgin's fault for sending "abort
> smp"
> > message to us when the cancel button is clicked over an
> > authenticated session. I think Jitsi's UI is acting
> accordingly.
> >
> >
> > George, I gave it a second though and I think you were right.
Even
> > though I still think it is Pidgin's fault for sending "abort
> smp", it
> > may be best for us to act accordingly and not to show the
> 'auth failed'
> > dialog when we already are on an authenticated session.
> >
> > Thanks again for the gread review!
> >
> > Regards,
> > Marin
> >
> >
> > On Mon, Nov 4, 2013 at 10:39 AM, Marin Dzhigarov > > <marin@bluejimp.com <mailto:marin@bluejimp.com> > > > <mailto:marin@bluejimp.com <mailto:marin@bluejimp.com>>> > wrote:
> >
> > It sounds like a good idea. Please, feel free to
> modify otr4j
> > accordingly.
> >
> > Thanks, I will!
> >
> >
> > A minor issue I noticed is
> > this : Suppose Alice is using Pidgin and Bob is using
> Jitsi and that
> > those two parties have established an
> **authenticated** session. If
> > Alice chooses to Reauthenticate Bob (selects the
> appropriate
> > menu item
> > in Pidgin), but then she changes her mind and presses
> the cancel
> > button,
> > then an "Authentication failed!" message will popup
> for Bob (running
> > Jitsi).
> > Technically speaking, the authentication didn't fail,
> it was
> > aborted and
> > the session remains in it's previous state
> (authenticated in the
> > above
> > example). So I don't think we display that particular
> message to the
> > user. Pidgin, in fact, does nothing in that case.
> >
> > Well... I think it's Pidgin's fault for sending "abort
> smp" message
> > to us when the cancel button is clicked over an
authenticated
> > session. I think Jitsi's UI is acting accordingly.
> > What do the others think?
> >
> > Another thing is that we're missing an authentication
> option. A
> > question
> > is optional when initiating SMP. That's why in Pidgin
> there are
> > 3 options :
> > - Question and answer
> > - Shared secret (the one missing from Jitsi)
> > - Manual fingerprint verification
> >
> >
> > I don't see what's the point of the "Shared secret"
> option. I know
> > Pidgin has it and I find it useless. If the user does not
> want to
> > write a question to authenticate then he may simply leave
the
> > question field empty. In fact, in Pidgin if Alice choose
> the "Shared
> > secret" option then Bob will see the same pop-up dialog
> like in
> > "Question and answer" but with empty question field.
> >
> > Regards,
> > Marin
> >
> >
> > On Sat, Nov 2, 2013 at 3:07 AM, George Politis > > <666f6f@gmail.com <mailto:666f6f@gmail.com> > > > <mailto:666f6f@gmail.com <mailto:666f6f@gmail.com>>> > wrote:
> >
> > Hello Marin,
> >
> > > George, I have just one final concern. How do you
> feel about
> > > changing
> >
> net.java.otr4j.OtrEngineHost.getReplyForUnreadableMessage() and
> > > net.java.otr4j.OtrEngineHost.getFallbackMessage()
> signatures
> > to have
> > > SessionID for a parameter? This would allow for more
> > flexibility when
> > > sending error messages to the remote party. For
> example Alice
> > can send
> > > Bob the following ERROR_MESSAGE:
> > > "You sent Alice an unreadable encrypted message.
> Please end
> > you private
> > > conversation with Alice or refresh it."
> > >
> > > I feel that right now it is not very clear who sent
> what when
> > it comes
> > > to error messages in the OTR.
> > > Of'course this is just a minor thing and can be
> ignored. I
> > just feel
> > > that it would be less confusing for the users.
> >
> > It sounds like a good idea. Please, feel free to
> modify otr4j
> > accordingly.
> >
> > > Anyway, please review my latest patch and if you
> have any
> > concerns feel
> > > free to message me.
> >
> > It works pretty good, you did a neat job. A minor
> issue I noticed is
> > this : Suppose Alice is using Pidgin and Bob is using
> Jitsi and that
> > those two parties have established an
> **authenticated** session. If
> > Alice chooses to Reauthenticate Bob (selects the
> appropriate
> > menu item
> > in Pidgin), but then she changes her mind and presses
> the cancel
> > button,
> > then an "Authentication failed!" message will popup
> for Bob (running
> > Jitsi).
> >
> > Technically speaking, the authentication didn't fail,
> it was
> > aborted and
> > the session remains in it's previous state
> (authenticated in the
> > above
> > example). So I don't think we display that particular
> message to the
> > user. Pidgin, in fact, does nothing in that case.
> >
> > Another thing is that we're missing an authentication
> option. A
> > question
> > is optional when initiating SMP. That's why in Pidgin
> there are
> > 3 options :
> >
> > - Question and answer
> > - Shared secret (the one missing from Jitsi)
> > - Manual fingerprint verification
> >
> > I hope this makes sense.
> >
> > Cheers,
> > George
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org <mailto:dev@jitsi.org>
> <mailto:dev@jitsi.org <mailto:dev@jitsi.org>>
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
> >
> >
> >
> >
> >
> > _______________________________________________
> > dev mailing list
> > dev@jitsi.org <mailto:dev@jitsi.org>
> > Unsubscribe instructions and other list options:
> > http://lists.jitsi.org/mailman/listinfo/dev
> >
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org <mailto:dev@jitsi.org>
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>
>
>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev
>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev