OFF-THE-RECORD SECURE CHAT ROOM

Jiang Bian, Remzi Seker, Umit Topaloglu and Coskun Bayrak

Department of Computer Science, University of Arkansas at Little Rock

2801 S. University Avenue, Little Rock, Arkansas, U.S.A.

Keywords:

Off-the-Record, Chat room, Instant Messaging, Security, Group Difﬁe-Hellman.

Abstract:

Group Off-the-Record (GOTR) (Bian et al., 2007) was proposed to address the privacy protection concerns

in online chat room systems. It extended the original two-party OTR protocol to support more users while

preserving the same security properties. A literature survey of different Difﬁe-Hellman (D-H) conference key

implementations will be given to justify that in an application like a chat room, the virtual server approach

is truly the most efﬁcient way to establish a private communication environment among a group of people.

However, GOTR’s virtual server approach raises a trustworthiness concern of the chosen chair member. Since

the chair member has full control over all encryption keys, there is no constraint to prevent him / her from

altering the messages while relaying them. In this paper, we present a study of the GOTR protocol and

a solution to the virtual server’s trustworthiness problem via employing an additional MD5 integrity check

mechanism. Having such an algorithm, makes the GOTR protocol more secure, in that, it gives the other chat

members an opportunity to be aware of any potential changes made by the chair member.

1 INTRODUCTION

Chat room technologies started to surface in the

1970s. Initially, they was used in Unix systems to

help all the users who have logged on the same ma-

chine to communicate with each other. Then, it

quickly evolved into a network based system and be-

came much more popular with the growth of the mod-

ern Internet. The contemporary online chat room pro-

vides a real-time, text message based communication

mechanism over instant messaging (IM). It is fast,

ﬂexible, expandable and is virtually cost free to users.

Users tend to prefer chat rooms to other conventional

communication tools like the telephone systems and

electrical emails, since it is less intrusive but more in-

teractive.

However, privacy concerns hinder the expansion

of the use of chat rooms as well as Instant Messag-

ing. Although, many studies have been conducted to

provide a secure IM system, however, few of them

achieve perfect secrecy, which is in high demand by

the public.

2004, Borisov (Borisov et al., 2004) et. al. pro-

posed a secure off-the-record IM system, OTR, which

has addressed most of the existing security issues. It

achieved perfect forward secrecy via short-lived en-

cryption keys, which ensures that the revealing of a

ephemeral key would not compromise the entire chat

session. Moreover, the OTR protocol accommodates

a degree of plausible deniability, so that a user could

later discredit what he / she has said.

GOTR designed by Bian et. al. (Bian et al., 2007),

is an extension of the two-pary OTR protocol, which

makes it possible for multiple users to talk securely

and off-the-record in an online chat room environ-

ment. The GOTR protocol introduced a idea of choos-

ing a chair member to act as a virtual server and to be

responsible for relaying all messages securely. The

communications between the virtual server and every

other user are guarded by the original OTR protocol.

In this way, a secure communication chain is created.

However, the trustworthiness of the chosen vir-

tual server remains a ﬂaw. Since the virtual server

supervises all the communications in the chat room,

it is fairly easy for him / her to make changes while

repackaging messages. In order to prevent the mes-

sages from being altered by the virtual server, we

suggest to employ an MD5 integrity check mecha-

nism. Having a such mechanism will give other users

an opportunity to verify that the messages truly have

not been corrupted (i.e. the message could have been

changed by the virtual server, or due to a network fail-

Bian J., Seker R., Topaloglu U. and Bayrak C. (2008).

OFF-THE-RECORD SECURE CHAT ROOM.

In Proceedings of the Fourth International Conference on Web Information Systems and Technologies, pages 54-61

DOI: 10.5220/0001530500540061

 SciTePress

ure.) during its transmission.

This paper consists of ﬁve sections. In Section 2,

we present the key features of the original OTR pro-

tocol. In Section 3, we conduct a literature survey to

show the general idea of conference key distribution

systems, and compare their efﬁciency and complex-

ity to justify the advantages of using the virtual server

approach. A case study of the GOTR protocol will be

presented in Section 4.2 along with the idea of em-

ploying an MD5 integrity check to prevent the trust-

worthiness failure of the chair member. Moreover, a

automated mechanism will be suggested to deal with

the membership alternation problem caused by net-

work failures. Conclusions will be given in Section 5,

followed by future work in Section 6.

2 OFF-THE-RECORD INSTANT

MESSAGING

Many studies have been conducted to secure IM

systems (Gaim-e, 2002) (Pidgin-Encryption, 2007)

(

Secway, 2006). Most of them simply add extra

authentication and encryption layers above the public

IM protocols to ensure the authenticity and conﬁden-

tiality. However, perfect forward secrecy and denia-

bility are often omitted by these secure IM solutions.

Nikita Borisov et. al. introduced the Off-the-Record

Messaging (OTR) system (Borisov et al., 2004) at the

Workshop on Privacy in the Electronic Society, 2004.

The OTR protocol is a comprehensive security solu-

tion for public IM systems and it implements strong

cryptographic protection. Furthermore, two key fea-

tures of the OTR protocol are off-the-record commu-

nication and perfect forward secrecy protection.

2.1 The OTR Protocol

In an off-the-record chat room, a sender has the abil-

ity to deny what he/she has said in a previous chat ses-

sion. The conversations are not bound to any partici-

pant’s identity. However, the messages in an ongoing

conversation are still properly authenticated through

using Digital Signatures and Message Authentication

Codes (MAC).

There are four key security properties integrated

in the OTR protocol. These properties are brieﬂy de-

scribed next.

Perfect Forward Secrecy. This has been archived

through the use of short-lived encryp-

tion/decryption key. After the completion of

transmitting one message, a new shared secret

will be generated and used to encrypt/decrypt the

next message. And the current key will be simply

discarded by both sender and receiver. As a

result, the revealing of current shared key will not

compromise the secrecy of previous messages.

Even if an attacker manages to capture the current

encryption/decryption key, it will soon be invalid

for the next message.

Digital Signature. The authentication issue is ad-

dressed via a digital signature system. Each user’s

digital signature in OTR acts as long-lived keys.

The keys are solely for authentication purposes

and are not used to encrypt the real messages.

MAC Code and Plausible Deniability. The MAC

(Stinson, 2002) code is introduced to retain the

deniability of an off-the-record conversation.

Unlike digital signatures, MACs are generated

and veriﬁed via the same secret key. Therefore, a

MAC value does not provide the non-repudiation

property offered by a digital signature.

Malleable Encryption and Forge-ability. In gen-

eral, malleability is an undesirable property in

encryption algorithms. However, for the OTR

protocol, it is an enhancement feature that enables

anyone to transform an encrypted message (m)

into another valid cipher text (m

′

) without the

knowledge of the plaintext. Such Homomorphic

Encryption scheme (Canetti et al., 1996) provides

an intensive degree of forge-ability.

2.2 Security Weakness in the OTR

Protocol

Mario Di Raimondo, et al. (Raimondo et al., 2005)

pointed out three major security ﬂaws or vulnerabili-

ties in the OTR protocol.

First of all, OTR inherits a possible ”identity mis-

binding” attack from the D-H protocol. Suppose that

a malicious user, Eve, stands between two end-users,

Alice and Bob, and she has the ability to intercept

all the communications between them. If she attacks

properly (Difﬁe and Hellman, 1976), Eve could man-

age to make Alice think that she is talking to Bob,

but actually she is speaking to Eve. For a real life

example, Eve can use this authentication ﬂaw to mis-

lead a customer, Alice, and a bank, Bob. One simple

solution is to include identity information in the digi-

tal signature, but it will surely dismiss the deniability

property.

Moreover, the revealing of an ephemeral private

key could cause an impersonation attack. An attacker

could use this piece of information to produce a valid

session key as long as the long-term keys are not re-

invoked. This attack could be defended by doing full

OFF-THE-RECORD SECURE CHAT ROOM

key refreshment periodically, which ensures that the

revealing of an ephemeral private key of one conver-

sation session will not affect the next fully refreshed

one.

Furthermore, the improper mechanism of reveal-

ing MAC keys weakens the secrecy of encryption

keys. Since the MAC keys are generated as a one-way

hash over the encryption key, the attacker can use this

knowledge to mount a ”dictionary attack”, although it

is probably computationally too expensive.

Consequently, Mario Di Raimondo, et al. sug-

gested three alternate Authentication Key Exchange

(AKE) algorithms, SIGMA, SKEME (Krawczyk,

1996) (i.e. which is an early voice of a protocol de-

signed to provide deniability to IPsec’s IKE proto-

col.) and HMQV, and discussed both the advantage

and disadvantage of using these three protocols.

This discussion resulted in a second version of the

OTR protocol (Borisov et al., 2004), where:

1. ﬁxed the identity-binding ﬂaw (the impersonate

attack vulnerability) simply by adding an addi-

tional identiﬁcation message at the beginning of

the conversation session.

2. No longer revealing the users’ public keys to pas-

sive eavesdroppers and this helps in privacy pre-

serving for the internal application’s OTR mes-

sages

And, additionally, they provide a support of fragmen-

tation OTR messages, since a lot of Instant Messaging

protocols have limitation on the size of each message.

Despite the security advantages it offers, the OTR

project has a missing key feature, a support of chat

room conversations.

3 GROUP DIFFIE-HELLMAN

AND THE CONFERENCE KEY

SYSTEM

In order to create a secure communication environ-

ment over insecure channels (public Internet infras-

tructure), it essentially falls into a problem that how

to distribute the encryption/decryption keys securely.

The OTR protocol uses the most familiar Difﬁe-

Hellman (D-H) (Difﬁe and Hellman, 1976) key agree-

ment for this purpose. The D-H protocol allows two

users to establish a shared secret over an unprotected

channel. It is believed that the most efﬁcient way

to break the D-H protocol is to solve the underlined

mathematic problem, the discrete logarithm problem.

However, there is no computationally feasible ap-

proach has been found.

When a group of people demand to talk privately

over an unsecure environment, a conference key dis-

tribution system (CKDS) is required. Many papers

(Ingemarsson et al., 1982) (Burmester and Desmedt,

1994) (Bellare and Rogaway, 1995) (Steiner et al.,

1996) (Bresson et al., 2001) (Bresson et al., 2007)

have been presented to solve such a conference key

distribution problem. And our goal is to ﬁnd an ef-

ﬁcient group D-H conference key system that is suit-

able to be used in securing chat room systems, while

preserving off-the-recordand perfect forward secrecy.

Basically, as a group D-H system, it has to col-

lect contributions from each communication mem-

ber (g

), compute the conference key (centralized or

independently), and distribute the common secret to

each member securely.

Ingemarsson et. al. proposed a conference key

system where n members needs to be arranged in a

logical ring (Ingemarsson et al., 1982). During one

key establishing round, one user U

raises the inter-

mediate key value received previously from U

i−1

, and

passes the result to the next participant, U

i+1

. In

(n− 1) rounds, all members will compute the same

K = g

+...+r

n−1

mod p

Burmester and Desmedt (Burmester and Desmedt,

1994) proposed a cyclic based conference key dis-

tribution system and claimed that their protocol was

much more efﬁcient. This protocol runs 2n + 1

rounds, and eventually, all users will agree on a con-

ference key

K ≡ g

+...+r

mod p

Michael et. al. (Steiner et al., 1996) introduced

a ”natural” extension to the two-party D-H protocol.

Its key features are summarized as follows: 1). n+ 1

rounds of message exchanging; 2). constant message

sizes; 3). small number of exponentiations required.

Also, they have provided a solution to the problem of

member addition and deletion, which ensures that the

alteration of group membership will not compromise

the group’s secrets.

However, in a chat room system, every message

will be multicast to each user automatically by the

underlined chat room protocol. So, it is hardly pos-

sible to create such a logical ring without heavy over-

heads. Even if a user only meant to send a intermedi-

ate key to U

, the chat room system will automatically

send a copy to every other user as well. This is a

waste of effort, and since this value has no meaning

to the rest of the group, each user will simply discard

it. Moreover, in all three aforementioned CKDSs, a

user U

needs to raise a previously received interme-

diate key to the power of its own private key, r

, and

WEBIST 2008 - International Conference on Web Information Systems and Technologies

pass it to the next member or broadcast to everyone

else. Exponentiation is computationally expensive in

a computer system. Even in Michael et. al.’s system,

which has the minimal number of exponentiations of

all three protocols, still requires 5n − 6 exponentia-

tions. Moreover, recall that in order to achieve the

perfect forward secrecy, a short-lived key scheme is

used in the OTR protocol. If we simply applied one

of these CKDSs, it would create a tremendous amount

of overhead. It would require the exchange of at least

2n − 1 messages and take n + 1 rounds to compute a

common secret, when only encrypting one small text

message. Obviously, as the number of chat member

increases, the bandwidth used to establish the shared

channel will be hundreds of times bigger than the real

message payloads.

4 GROUP OFF-THE-RECORD IM

PROTOCOL

Group Off-The-Record (Bian et al., 2007) is an ex-

tension of the original bipartite OTR protocol. In the

GOTR protocol, the member who initiates the GOTR

chat room will be chosen to act as a virtual server.

Then, the virtual server starts a two-party OTR key

exchange to establish a private, off-the-record chan-

nel with each other member pair-wise. Since two chat

members do not share a common secret directly, the

virtual server is responsible for routing all messages

from one user to another. When the virtual server re-

ceives a message, he / she will need to index through

his / her key table to ﬁnd the proper decryption key,

decrypt the message and re-encrypt it with the key he

/ she shares with the designated receiver. All com-

munications between a user and the virtual server are

guarded by the two-party OTR protocol. In such a de-

sign, a secure communication chain, from one user to

another, has been created.

The GOTR’s virtual server approach, avoids the

trap of dealing with the complexity of generating a

conference key among many users, and instead uses

a router based concept: a trusted member is chosen

as a router to relay all messages, and is responsible

for managing all the encryption/decryption keys. As

we can see, the GOTR protocol still creates overheads

such as sending encrypted messages to a user who

would not be able to read it, however, it reduces the to-

tal number of exponentiations used in computing the

shared keys. According to the D-H protocol, for each

new key, all the users except the virtual server needs

to do the exponentiation twice (i.e. once to compute

its public key, g

, the other one is used to compute the

shared key between he / she and the virtual server.),

while only the virtual server needs to do 2(n− 1) ex-

ponentiations. However,the total number is still much

less than any existing conference key distribution sys-

tems discussed above.

4.1 A Case Study of the GOTR Protocol

Let us suppose there are three users, Alice, Bob and

Carol, who want to have an off-the-record chat room

conference in a secure manner. This scenario can be

seen in Figure 1:

Figure 1: GOTR communication scheme.

Alice and Bob as well as Alice and Carol would

establish the two-party OTR communication channel

(i.e. in other words, Alice and Bob share a common

secret SS

Alice&Bob

(SS

Alice&Carol

for Alice and Carol)

and follow the OTR protocol for further conversa-

tions. Therefore, the channel between them is se-

cure and off the record.). Since Bob and Carol do

not have shared key, they cannot talk to each other di-

rectly. They have to go through the virtual server, Al-

ice. Bob ﬁrst sends Alice the message encrypted with

key SS

Alice&Bob

; Alice deciphers it using SS

Alice&Bob

and repacks it with key SS

Alice&Carol

; then she relays

the new message to Carol. Now Carol has no problem

reading this message. Alice, in this conﬁguration, acts

like an interpreter.

In the proposed system, there remains a security

vulnerability that needs to be addressed: there is al-

ways a chance that a virtual server can be attacked.

Since the virtual server is privileged to fully control

all the encryption keys, it would be relatively easy

for an attacker to change the content of a message

and broadcast to other chat room members. There-

fore, we suggest creating a mechanism for the users

to verify the integrity of the messages received by the

virtual server. The other ﬂaw, which exists in the pre-

vious GOTR product, is that in the case of a virtual

server encountering a network failure, all the subse-

quent conversations in this chat room will be unread-

able since the rest of the users are not sharing any

common secrets (i.e. shared encryption keys). There-

OFF-THE-RECORD SECURE CHAT ROOM

fore, in this paper, we purpose an improvedversion of

the GOTR protocol, which solves these two problems

and provides some other enhancements to the GOTR

Pidgin plug-in.

Moreover, a network failure of the virtual server

raises another issue. Since the users do not have a

shared key other than with the virtual server, if the vir-

tual server drops off, the communication chain cannot

be established. In this paper, we propose a solution to

the virtual server’s honesty problem using MD5 hash

functions and provide a mechanism to deal with the

problem of virtual server network failure.

4.2 GOTR Enhancement: MD5

Integrity Check and Network

Failure Handling

4.2.1 MD5 Integrity Check

Even though the GOTR communication scheme

seems to be a good solution for the security needs de-

scribed before, it still has a security ﬂaw. Since there

exists a centralized controller (the Virtual Server), a

failed or hacked controller will cause the GOTR sys-

tem to fail. Therefore, the degree of our security

mode is coupled with the trustworthiness or the se-

curity level of the virtual server. The previous version

of GOTR does not provide an integrity check for the

messages relayed over the virtual server. Ideally there

should be a mechanism to warn Carol that a message

has been modiﬁed during its transmission.

Consider the previous GOTR example, in which

Alice, Bob, and Carol were having a GOTR chat

room conference. Alice has been dedicated as the

virtual server. The two way communications be-

tween Alice—Bob and Alice—Carol are guarded by

the original OTR protocol. But OTR does not pro-

vide an assurance that Alice, the virtual server, did not

change the content of any message during the repack-

ing process.

Redundancy check mechanisms are well-known

and often used in network applications for the pur-

poses of error detection and correction. Redundancy

checks, although slightly increases the size of each

message, can provide an integrity check for the whole

message. If only error detection is required, the

checksum algorithm is obviously the most widely

used and simplest method. It works by adding up

basic components of data, typically the asserted bits,

and sending the result along with the original mes-

sage. Anyone who receives this message plus its

checksum can later perform the same operation and

compare the resulting value with the checksum. The

receiver can conclude that the message has not been

corrupted during its transmission. Some other redun-

dancy check methods include parity checks, check

digits, and cyclic redundancy check (CRC), etc. For

instance, a CRC function often takes a stream of vari-

able length data as input and produces a ﬁxed size

code as output. Compared to checksum, CRC pro-

vides more precise error detection while maintain-

ing a plausible execution time. Basically, any kind

of (cryptographic) hash function can be used to pro-

duce a message digest, which can be used to verify the

message’s integrity (W.W.Peterson and D.T.Brown,

1961).

In the proposed protocol, since Bob (Carol) en-

crypts messages with keys that are only known by him

(her) and Alice, it is not possible for Carol (Bob) to

decrypt these messages. Therefore, we need the help

from the virtual server, Alice. Following our GOTR

protocol, Alice decrypts the message originated from

Bob and re-encrypts it with the key (SS

Alice&Carol

)

shared between her and Carol. Under such a sys-

tem, there is no way we can prevent Alice from al-

tering the messages. However, we can provide a ver-

iﬁcation mechanism, which will give Carol a chance

to check the integrity of messages. In order to as-

sure the integrity of the message, Bob will produce a

hash value H

of the message and send it to Carol in a

straight line. After receiving both the hash value from

Bob and the repacked message from Alice, Carol can

check whether the message has been altered or not.

She simply just needs to reproduce the hash value

upon the received message and compare the result

with the one from Bob.

The aforementioned integrity check method has

been implemented in the GOTR protocol. In this ex-

perimental work, a 128-bit MD5 algorithm (Rivest,

1992) has been employed, and it is possible to use

any existing one-way hash function. By using a hash

algorithm that has a higher collision rate, it may al-

low a malicious user to be able to alter the content

of a message, but still produce the same message di-

gest. MD5 takes an arbitrary number of characters as

input but produces a ﬁxed length output. This prop-

erty assures a minimal amount of overhead to each

message. Moreover, MD5 functions are widely avail-

able as libraries in almost all the major programming

languages such as C, C++, Java, PHP, etc. The OTR

library uses libgcrypt (Koch, 2005) to provide the ba-

sic cryptographic functionalities and it also has MD5

algorithm support. Therefore, no extra programming

effort will be required to provide MD5 services.

The tests and mathematical proofs have shown

that the probability of retrieving the plaintext from its

hash value is negligible (Bishop, 2002). Hence, it is

not an infringement of security requirements to trans-

WEBIST 2008 - International Conference on Web Information Systems and Technologies

mit the hash values for messages through unsecured

channels.

Since the proposed protocol uses existing internet

infrastructure and requires time to encrypt the mes-

sage, there will be latency. It is not possible to es-

timate the message and hash arrival order. Different

arrival times of the hash and message might cause a

false positive. In order to resolve the issue, a message

identiﬁcation (

?ID?

) is attached to each message. In

the GOTR protocol, the unique ID is the UNIX (or

POSIX) time when the message was created. UNIX

time is the number of seconds elapsed since midnight

UTC of January 1, 1970, not counting the leap sec-

onds. Collisions rarely occur if we extend the times-

tamp to include microseconds.

From the application point of view, every time

Bob wants to communicate, he will send out the en-

crypted message along with a message digest (i.e.

hash value generated by the MD5 algorithm) and the

unique identiﬁer (i.e. timestamp). In chat room proto-

cols, messages will be broadcast to everyone. Hence,

Alice has no way to prevent Carol from receiving the

message digest directly from Bob. Later, Carol could

use this information to verify this message’s integrity,

when she receives the re-encrypted copy from Alice.

In detail, she needs to perform the following steps: 1)

decrypt the message from Alice and save the unique

ID (UID); 2) calculate the MD5 value over the plain-

text message; 3) look up the MD5 value associated

with this UID from all the MD5s she gathered from

Bob; 4) compare these two MD5s and make the con-

clusion. If they are the same, Alice has not changed

the message originated by Bob; otherwise, Alice has

corrupted it. This approach will cause more over-

head network trafﬁc. However, an automated way of

checking the integrity of messages would have more

beneﬁts than drawbacks.

Figure 2: Enhanced GOTR protocol diagram with MD5 in-

tegrity check.

As shown in Figure 2, the communication chan-

nels between the virtual server and the other chat

room members are secure and off-the-record. How-

ever, the messages exchanged between Bob and

Carol, are not encrypted and vulnerable to attack.

Although we cannot transfer conﬁdential messages

through this unprotected channel, we can still use it

for transferring message digests. When Bob wants

to talk to Carol in the GOTR chat room, he would

send the encrypted contents through the private chan-

nel (i.e. which passes through the virtual server) along

with a unique identiﬁer:

Message 1: Bob → Alice, Carol:

?RECV?Alice@hotmail.com?ENDRECV?

+ ?SEND?Bob@hotmail.com?ENDSEND?

+ ?UID?unix_timestamp?ENDUID?

+ <Enc Msg with SSAlice&Bob>

Carol will discard this message since it is not read-

able for her. Meanwhile, Bob computes the message’s

MD5 digest and sends it to Carol in a straight line

along with the UID too for veriﬁcation.

Message 2: Bob → Carol, Alice:

?RECV?MD5_value?ENDRECV?

+ ?UID?unix_timestamp?ENDUID?

Alice, the virtual server, will repack Bob’s mes-

sage with a proper key and pass it on.

Message 3: Alice → Carol, Bob:

?RECV?Carol@hotmail.com?ENDRECV?

+ ?SEND?Bob@hotmail.com?ENDSEND?

+ ?UID?unix_timestamp?ENDUID?

+ <Enc Msg with SSAlice&Carol>

Eventually, Carol gets both the relayed message

from Alice and the message digest from Bob, and

then pairs them according to the UID. She computes

the MD5 value on the message from Alice and com-

pares it with the one she received from Bob. These

two values are supposed to be the same because they

are calculated upon the same message with the same

predeﬁned hash function. They will not match, only if

Alice has changed the message or the network pack-

age has been corrupted. No matter the reason, Carol

should not trust this message. She can instead, open a

new OTR channel and verify this message with Bob.

Now that the problem of assuring the message’s in-

tegrity is addressed, the solution for handling the vir-

tual server’s drop-off will be discussed next.

4.2.2 Network Failure Handler

When a user is using an IM service, assume that the

MSN server and the user encounter a network prob-

lem, the MSN service will be cut off and close all the

active sessions it has established with the user. When

a user reconnects to the MSN server at a later time,

the previous chat sessions will not be restored. There

are two possible scenarios regarding network failure

OFF-THE-RECORD SECURE CHAT ROOM

during a GOTR chat room session:

1. One or more chat room members other than the

virtual server lose their connections. In this case,

the remaining users can still talk securely and off-

the-record. However, when those disconnected

users recover and rejoin the chat room, the subse-

quent conversationswould not be secure anymore.

Continuing with our previous example, suppose

Carol had a system error and restarted her com-

puter. After she rejoins the GOTR chat room, the

connection between Alice and Bob are still secure

but the one between Alice and Carol has no more

protection. As a part of the exception handling

system, a GOTR system should recreate the pri-

vate channel between Alice and Carol automati-

cally in order to watch over the entire chat room.

In our GOTR Pidgin plug-in, upon receiving the

event message that Carol has rejoined the chat

room, Alice, as the virtual server, will start over

the entire GOTR chat room session. Even though

this is not necessary for Bob, a periodic key re-

freshment will make the GOTR session more se-

cure.

2. In case of the virtual server drops from the GOTR

session (e.g. the virtual server loses its network

connection), all private channels established for

that session will be lost. The other chat room

members will be talking in an unprotected envi-

ronment. In this case, the GOTR system would

randomly pick a user from the existing members

and make him/her the new virtual server. Then

the GOTR chat session will be restarted. The con-

versation tunnels between the new virtual server

and the rest of chat users will be private again.

By doing so, a new secure and off-the-record chat

session will be created. If the prior virtual server

reconnects and rejoins the chat room, the GOTR

system will treat him/her as a new joining member

and react the same way as in the ﬁrst scenario

4.3 Performance Evaluation of GOTR

Protocol

One question would be how many users a GOTR chat

room could hold. Although there is no practical limit

on the number of users who might join a GOTR ses-

sion, more users will cause more overhead and net-

work trafﬁc, which eventually will cause noticeable

delays. In addition, since the GOTR protocol uses a

virtual server to route all messages, increasing num-

ber of users will increase the burden on the virtual

server. Hence, with increased number of users, prob-

lems may arise not only because of the limitation of

the network bandwidth but also the computational re-

sources of the virtual server. We have not performed

any formal performance test such as comparing tran-

sit time of each message, counting how many extra

packets are caused by the GOTR protocol etc. We

have tested our Pidgin GOTR plug-in with up to ten

users in a single chat room and there was no notice-

able delay. The number of users in a GOTR chat room

session is limited by the number of users allowed in an

MSN chat room session. However, having extra net-

work bandwidth and computational power will pro-

vide faster off-the-record chat room service.

5 CONCLUSIONS

An off-the-record secure chat room is a much-needed

product for the public and the business community.

Although the GOTR protocol has improved the orig-

inal two-party OTR protocol, it was far from perfect.

Therefore, through our continued work that is pre-

sented in this paper, the virtual servers trustworthi-

ness problem was addressed by employing a MD5

integrity check mechanism. This scheme provides

the remaining chat members the ability to identify

any message alterations if ever made by the virtual

server. Although, the MD5 integrity checking mech-

anism would increase the overhead of each message,

with the initial tests, the network delays are not no-

ticeable. Furthermore, a few enhancements have been

suggested to deal with network failures. No matter

who is disconnected from a GOTR chat room, a full

key refreshing process is required to secure the whole

communication chain. Moreover, as discussed, pe-

riodically refreshing the private channels of the entire

chat room session makes the GOTR protocol more se-

cure.

6 FUTURE WORK

The protection of chat history ﬁles would be a nice

feature to include. Currently, there is no way to pre-

vent a user from saving the chat histories. Efﬁcient

ways of attaching list of permissions to each chat his-

tory ﬁle would be beneﬁcial. The mechanism could

be implemented such that every member in a GOTR

chat room would have a synchronized chat history ﬁle

with a uniﬁed access control list attached. Also, the

identity-pertaining information associated with each

message saved in the chat history should be sanitized,

so it will not compromise the off-the-record property

of the GOTR protocol.

WEBIST 2008 - International Conference on Web Information Systems and Technologies

ACKNOWLEDGEMENTS

This work was funded, in part, by grants from the Na-

tional Science Foundation #0619069 and #0701890

and Department of Defense #H98230-07-C-0403.

REFERENCES

Bellare, M. and Rogaway, P. (1995). Provably secure ses-

sion key distribution: the three party case. In STOC

’95: Proceedings of the twenty-seventh annual ACM

symposium on Theory of computing, pages 57–66,

New York, NY, USA. ACM.

Bian, J., Seker, R., and Topaloglu, U. (2007). Off-the-record

instant messaging for group conversation. In 2007

IEEE International Conf. on Information Reuse and

Integration, Las Vegas, NV, USA.

Bishop, M. (2002). Computer Security: Art and Science.

Addison Wesley Professional.

Borisov, N., Goldberg, I., and Brewer, E. (2004). Off-

the-record communication, or, why not to use pgp.

In WPES ’04: Proceedings of the 2004 ACM work-

shop on Privacy in the electronic society, pages 77–

84, New York, NY, USA. ACM Press.

Bresson, E., Chevassut, O., and Pointcheval, D. (2007).

Provably secure authenticated group difﬁe-hellman

key exchange. ACM Trans. Inf. Syst. Secur., 10(3):10.

Bresson, E., Chevassut, O., Pointcheval, D., and Quisquater,

J.-J. (2001). Provably authenticated group difﬁe-

hellman key exchange. In CCS ’01: Proceedings of

the 8th ACM conference on Computer and Commu-

nications Security, pages 255–264, New York, NY,

USA. ACM.

Burmester, M. and Desmedt, Y. (1994). A secure and ef-

ﬁcient conference key distribution system (extended

abstract). In EUROCRYPT, pages 275–286.

Canetti, R., Dwork, C., Naor, M., and Ostrovsky, R. (1996).

Deniable encryption. Cryptology ePrint Archive, Re-

port 1996/002. http://eprint.iacr.org/.

Difﬁe, W. and Hellman, M. E. (1976). New directions in

cryptography. IEEE Transactions on Information The-

ory, IT-22(6):644–654.

Gaim-e (2002). Gaim-e, encryption plug-in for gaim.

http://gaim-e.sourceforge.net/.

Ingemarsson, I., Tang, D. T., and Wong, C. (1982). A con-

ference key distribution system. IEEE Transactions

on Information Theory, 28(5).

Koch, W. (2005). Libgcrypt - cryptographic library.

http://directory.fsf.org/security/libgcrypt.html.

Krawczyk, H. (1996). Skeme: a versatile secure key ex-

change mechanism for internet. sndss, 00:114.

Pidgin-Encryption (2007). Pidgin-encryption. http://pidgin-

encryption.sourceforge.net/.

Raimondo, M. D., Gennaro, R., and Krawczyk, H. (2005).

Secure off-the-record messaging. In WPES ’05: Pro-

ceedings of the 2005 ACM workshop on Privacy in the

electronic society, pages 81–89, New York, NY, USA.

ACM Press.

Rivest, R. (1992). The md5 message-digest algorithm.

Technical Report RFC 1321, MIT Laboratory for

Computer Science and RSA Data Security, Inc.

Secway (2006). Simppro: Instant messengers, instant se-

curity. http://www.secway.fr/us/products/simppro/.

Steiner, M., Tsudik, G., and Waidner, M. (1996). Difﬁe-

hellman key distribution extended to group commu-

nication. In CCS ’96: Proceedings of the 3rd ACM

conference on Computer and communications secu-

rity, pages 31–37, New York, NY, USA. ACM Press.

Stinson, D. R. (2002). Cryptography Theory and Practice,

Second Edition. CRC Press, Inc.

W.W.Peterson and D.T.Brown (1961). Cyclic codes for er-

ror detection. In Proceedings of the IRE.

OFF-THE-RECORD SECURE CHAT ROOM