From nathan at guardianproject.info  Fri Mar  4 14:18:36 2011
From: nathan at guardianproject.info (Nathan of Guardian)
Date: Fri, 04 Mar 2011 14:18:36 -0500
Subject: [OTR-dev] Fwd: [guardian-alpha] Gibberbot 0.0.3 RC 3 (201100304b)
Message-ID: <4D713B0C.8090009@guardianproject.info>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hey everyone,

The Guardian Project is looking both for end-user feedback, as well, as
technical review of our OTR implementation for Gibberbot, an open-source
XMPP messaging app for Android which aims to be as secure as possible by
default.

We are using the OTR4J project on Android:
http://code.google.com/p/otr4j/

You can find the custom bits of our implementation here:
https://github.com/guardianproject/Gibberbot/tree/master/src/info/guardianproject/otr

We've got some fun twists on things including support for QRCode
scanning as way to quickly verify keys in person (screenshots here:
https://guardianproject.info/apps/gibber/)

Currently, the keys and verified fingerprints are stored on the file
system via a Java Properties class. With Android, each app has its own
internal storage space protected by user permissions, and this gives us
some amount of security there. However, we are moving the entire app to
sit on top of a symmetric key encrypted SQLite database shortly.

Best,
 Nathan


- -------- Original Message --------
Subject: [guardian-alpha] Gibberbot 0.0.3 RC 3 (201100304b)
Date: Fri, 04 Mar 2011 13:50:33 -0500
From: Nathan of Guardian <nathan at guardianproject.info>
Organization: The Guardian Project
To: guardian-dev <guardian-dev at lists.mayfirst.org>,
guardian-alpha at lists.mayfirst.org


We've got a new release candidate worthy build ready for you to test!

You can find it in the Android Market or download it directly here:
https://github.com/guardianproject/Gibberbot/Gibberbot-0.0.3-RC3-20110304b.apk/qr_code

To provide feedback or report issues, you have three options:
1) Reply to this email (easy)

2) Fill out this form (a little more involved):
https://guardianproject.info/contact/feedback/

3) Enter issues into Github (the best, but a little more complex):
https://github.com/guardianproject/Gibberbot/issues


****
Here's a short list of what has been fixed:

- - Wizard UI should now work better on landscape mode and smaller
screens.... no more hidden buttons!

- - Included an updated build of the ASmack XMPP library that powers the
chat protocol bit of our app. This has the latest patches from the core
Smack library.

- - Improved TLS certification verification process and properly tied into
Settings menu; added support for Android BKS keystore and cacerts

- - Added support for controlling whether SRV DNS record lookup is done or
not (it is better NOT too for privacy reasons, especially when running
over Tor)

- - Began the localization process into all supported Android SDK
languages (starting automated, will bring humans in later to edit)

- - Turned off inappropriate autocomplete/suggest where possible

- - Cleaned up graphics and text copy
_______________________________________________
Guardian-alpha mailing list

Post: Guardian-alpha at lists.mayfirst.org
List info: https://lists.mayfirst.org/mailman/listinfo/guardian-alpha

To Unsubscribe
        Send email to:  Guardian-alpha-unsubscribe at lists.mayfirst.org
        Or visit: %(user_optionsurl)s

You are subscribed as: %(user_address)s
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iF4EAREIAAYFAk1xOwsACgkQ0qzSA7N0y9J3OgD+IHFmmpKJEcOEidjm+oisf+/c
oP5yl1RDjpkRIR+m/eMA/2zF2Fkj0DVhxh/qcHZkQ/Bg0uyCjWNoDke68D2ZZrlS
=IpI+
-----END PGP SIGNATURE-----

From dev.c0debabe at gmail.com  Wed Mar 16 11:37:37 2011
From: dev.c0debabe at gmail.com (=?ISO-8859-1?Q?Stefan_Sch=F6nleitner?=)
Date: Wed, 16 Mar 2011 16:37:37 +0100
Subject: [OTR-dev] purpose of hash commitment in OTR authenticated key
	exchange
Message-ID: <AANLkTimYCjGHWMKEA76gv_k9MSy6_xhSjTztwXzXJ4-F@mail.gmail.com>

Hi,

I was wondering what the exact purpose of the Diffie-Hellman hash commitment
in the OTR authenticated key exchange is.
The paper "Improved User Authentication in Off-The-Record Messaging" says
that the "initial commitment is used to ensure that
neither party can base their choice of g^x on the other party?s value of
g^y".

If there would be no hash commitment, the DH key exchange responder could
specifically choose g^y based on the choice of g^x which would allow him to
influence the resulting shared secret key s.
What's so bad about this ?

The only problem that i see is if Alice and Bob would for example verify
that there was no man in the middle attacker by comparing only the first few
bytes of the key fingerprint over a secure out-of-band channel.
Assuming that Alice establishes a DH key exchange with Bob in the presence
of a MITM attacher Eve, Alice would send g^x1 to Eve in the believe that she
sends it to Bob.
Now Eve initiates a DH key exchange with Bob by sending her own g^x2 whereas
Bob responds with g^y1.
The result is that the attacker Eve and Bob have agreed on a shared secret
s2 = g^x2^y1 = g^y1^x2 that has a certain fingerprint (e.g. F2 = sha1(s2)).
As for the authentication only the first few bytes of the fingerprint are
actually compared, in the key exchange with Alice the attacker Eve can
compute a special value g^y2 so that the established shared secret key with
Alice is s1 = g^x1^y2 = g^y2^x1, but with the big difference that the first
bytes of the fingerprint (e.g. F1 = sha1(s1)) are equal to F2.
If Alice and Bob verify the first bytes of the fingerprint with each other
over a secure channel, these bytes will be the same although there way an
attacker Eve in the middle.

However, if they would have compared the whole fingerprint with each other,
then it would have been computationally infeasible for Eve to compute a
special value g^y2 that leads to the same fingerprint.

Is this scenario the reason why OTR uses a hash commitment, or is there
another reason ?

cheers,
stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20110316/b53850a7/attachment.html>

From ian at cypherpunks.ca  Wed Mar 16 17:29:58 2011
From: ian at cypherpunks.ca (Ian Goldberg)
Date: Wed, 16 Mar 2011 17:29:58 -0400
Subject: [OTR-dev] purpose of hash commitment in OTR authenticated key
 exchange
In-Reply-To: <AANLkTimYCjGHWMKEA76gv_k9MSy6_xhSjTztwXzXJ4-F@mail.gmail.com>
References: <AANLkTimYCjGHWMKEA76gv_k9MSy6_xhSjTztwXzXJ4-F@mail.gmail.com>
Message-ID: <20110316212958.GY2058@yoink.cs.uwaterloo.ca>

On Wed, Mar 16, 2011 at 04:37:37PM +0100, Stefan Sch?nleitner wrote:
> Hi,
> 
> I was wondering what the exact purpose of the Diffie-Hellman hash commitment
> in the OTR authenticated key exchange is.
> The paper "Improved User Authentication in Off-The-Record Messaging" says
> that the "initial commitment is used to ensure that
> neither party can base their choice of g^x on the other party?s value of
> g^y".
> 
> If there would be no hash commitment, the DH key exchange responder could
> specifically choose g^y based on the choice of g^x which would allow him to
> influence the resulting shared secret key s.
> What's so bad about this ?
> 
> The only problem that i see is if Alice and Bob would for example verify
> that there was no man in the middle attacker by comparing only the first few
> bytes of the key fingerprint over a secure out-of-band channel.
> Assuming that Alice establishes a DH key exchange with Bob in the presence
> of a MITM attacher Eve, Alice would send g^x1 to Eve in the believe that she
> sends it to Bob.
> Now Eve initiates a DH key exchange with Bob by sending her own g^x2 whereas
> Bob responds with g^y1.
> The result is that the attacker Eve and Bob have agreed on a shared secret
> s2 = g^x2^y1 = g^y1^x2 that has a certain fingerprint (e.g. F2 = sha1(s2)).
> As for the authentication only the first few bytes of the fingerprint are
> actually compared, in the key exchange with Alice the attacker Eve can
> compute a special value g^y2 so that the established shared secret key with
> Alice is s1 = g^x1^y2 = g^y2^x1, but with the big difference that the first
> bytes of the fingerprint (e.g. F1 = sha1(s1)) are equal to F2.
> If Alice and Bob verify the first bytes of the fingerprint with each other
> over a secure channel, these bytes will be the same although there way an
> attacker Eve in the middle.
> 
> However, if they would have compared the whole fingerprint with each other,
> then it would have been computationally infeasible for Eve to compute a
> special value g^y2 that leads to the same fingerprint.
> 
> Is this scenario the reason why OTR uses a hash commitment, or is there
> another reason ?

You've got it exactly right.  Indeed, at one point in the history of
OTR, checking the "secure session id" (which was exactly a truncated
hash of a few things including the session key) out of band was
something users could explicitly do.

But in general, it's good crypto hygiene to prevent one party in a key
exchange from being able to control the particular value of the key that
comes out.

   - Ian

From dev.c0debabe at gmail.com  Thu Mar 17 05:58:09 2011
From: dev.c0debabe at gmail.com (=?ISO-8859-1?Q?Stefan_Sch=F6nleitner?=)
Date: Thu, 17 Mar 2011 10:58:09 +0100
Subject: [OTR-dev] purpose of hash commitment in OTR authenticated key
	exchange
In-Reply-To: <20110316212958.GY2058@yoink.cs.uwaterloo.ca>
References: <AANLkTimYCjGHWMKEA76gv_k9MSy6_xhSjTztwXzXJ4-F@mail.gmail.com>
	<20110316212958.GY2058@yoink.cs.uwaterloo.ca>
Message-ID: <AANLkTikJw5Q9jP6H+RQTrKmyu0bDZ7zt_HVG2tuF1Yk1@mail.gmail.com>

Hi,

On Wed, Mar 16, 2011 at 10:29 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:

>
> You've got it exactly right.  Indeed, at one point in the history of
> OTR, checking the "secure session id" (which was exactly a truncated
> hash of a few things including the session key) out of band was
> something users could explicitly do.
>
> But in general, it's good crypto hygiene to prevent one party in a key
> exchange from being able to control the particular value of the key that
> comes out.
>
>   - Ian
>


thank you for your fast response, it's good to know that I didn't miss
something in respect to the hash commitment.

Another question I have concerns the actual SIGMA authentication procedure:
1. Initially Alice derives the MAC keys a1, a2, b1, b2 and AES keys a3, b3
from the shared "master" secret s.

2. She then uses the key a1 to compute the MAC MA over the DH public keys
and her long-term public keys (we ignore the keyid engineering requirement
here).

3. In the next step she signs MA with her long-term sign key and the message
XA is constructed.

4. The message XA is encrypted and authenticated by computing a MAC tag over
the encrypted message with key a2.

While I understand the purpose of the key a2 (which is to authenticate
Alice's messages that are sent over an insecure channel), I'm not exactly
sure what the purpose of a1 is.
Wouldn't the exchange be the same if Alice used an unkeyed hash function
like SHA256 to sign the DH public keys and her long-term public key (i.e.
she would sign SHA256(g^x,g^y,v_A)) ?
Sure, the whole idea of SIGMA is to SIGn and MAc, but apart from that I do
not see the reason why in this case a MAC instead of a reguar unkeyed hash
function is used.
IMHO in this case it doesn't bring any additional security, right ?

cheers,
stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/otr-dev/attachments/20110317/92c9515a/attachment.htm>