Agora A Minimal Distributed Proto col for

Electronic Commerce

Eran Gabb er and Abraham Silb erschatz

Bell Lab oratories

Mountain Ave

Murray Hill NJ

feran avigresearchbel llabscom

not aord to communicate with the bank for ev Abstract

ery transaction High transactions volume implies

Agora is a Web proto col for electronic commerce

distributed proto cols since anycentralized resource

whichisintended to supp ort highvolume of trans

will b ecome a b ottleneck

actions each with low incurred cost Agora has the

In our terminology banks are nancial insti

following novel prop erties

tutes that manage customer and merchant accounts

Banks provide transaction pro cessing capabilities

Minimal The incurred cost of Agora transac

similar to current credit card companies Merchants

tions is close to free Web browsing where cost

are vendors that would like to sell go o ds electron

is determined by the numb er of messages

ically Customers are users p eople rob ots etc

that would like to purchase go o ds electronicallyIn

Distributed Agora is fully distributed Mer

our scheme we assume that banks are trusted en

chants can authenticate customers without ac

tities while customers and merchants are assumed

cess to a central authority Customers with

to b e nontrusted entities In case of a dispute a

valid accounts can purchase from anymerchant

fourth typ e of entity arbiters are used to settle the

without any preparations such as prior regis

dispute b etween customers and merchants Arbiters

tration at the merchant or at a broker

are assumed to b e trusted

Online arbitration An online arbiter can set

The World Wide Web requires a new class of

tle certain customermerchant disputes

proto cols Web commerce proto cols that are op

timized for purchase of page like merchandise eg

Fraud control Agora can limit the degree of

Web pages and information that can b e represented

fraud to a predetermined low level

as Web pages A Web commerce proto col should

b e comparable to free Web browsing in terms of

Agora is authenticated secure and can not b e repu

message overhead in order to achievelow incurred

diated It can use regular insecure communication

transaction cost

channels

We assume that the numb er of messages rather

than message length determines the o verhead and

Intro duction

cost of a proto col In other words the optimiza

tion criteria should b e numb er of messages and not

The wide spread use of electronic commerce on the

message length provided that message length re

World Wide Web will require mechanisms for deal

mains within some reasonable b ounds For example

ing with high volume of lowpriced transactions By

in TCP or UDP proto cols the overhead of a short

lowpriced transactions we mean transactions of low

message is similar to a longer message that ts into

monetary value which is close to or lower than the

the same numberofIPpackets

cost incurred in communicating with a bank Thus

Agora is a fully distributed commerce proto col

lowpriced transactions implies that merchants can

that requires a total of four messages to complete

a transaction including transfer of go o ds without

Agora is an ancient Greek marketplace It is also the

name of the Israeli coin of the lowest denomination any access to a central authority When Agora is

namely purchasing a scrip from a broker These employed as a Web commerce proto col its messages

preparations can involve as many as messages An can b e piggybacked on existing HTTP messages

other complication is handling of change Normally without any additional messages Hence Agora is

the value of the scrip is higher than the price of the minimal since it generates the same numb er of mes

go o ds Thus the merchant returns the change to the sage as free Web browsing

user in the form of another scrip Since this scrip is

Agora is a credit based proto col that is a trans

honored only by issuing merchant the customer is

action involves transfer of an account identier and

forced to redeem it by the broker

not the actual funds Merchants use accountidenti

NetBill is a robust electronic commerce pro

ers in order to get the funds from the bank

to col that provides atomicity customer pays for

Fully distributed credit based proto cols are sus

delivered merchandise only and anonymityvia

ceptible to certain typ es of fraud since the bank is

pseudonyms However NetBill requires messages

not contacted during the execution of every trans

to complete a transaction of whichtwo are tofrom

action For example customers may exceed their

the bank Thus NetBill is not applicable for low

credit limit and since the bank is not involved in

priced transactions that are less exp ensiv e then the

every transaction the transaction will b e approved

cost of contacting the bank

As another example if a thief gets hold of the iden

The Secure Electronic Transaction SET proto col

tication string and the private key of a legitimate

of Visa and MasterCard is a credit based proto

customer the thief can go on an unrestricted elec

col like Agora However SET requires communica

tronic shopping spree Toovercome this inherent

tion with the bank for every transaction That is

aw we present in Section the enhanced Agora

SET is not distributed and its incurred cost pro

proto col that uses a probabilistic algorithm to limit

hibits lowpriced transactions

the amount of fraud to a predetermined low level

The overhead of the enhanced Agora proto col is sim

Digital cash proto cols such as DigiCash pro

ilar to the basic Agora proto col

vide total anonymityHowever these proto cols were

not designed for Web commerce and lackproperar

We implemented a prototyp e of Agora using stan

bitration eg customer sent digital cash and didnt

dard Web to ols a Netscap e browser and an NCSA

receive the merchandise

server The customer side was implemented bya

Java applet and the merchantsidewas implemented The chrghttp proto col isarecentWeb com

by a set of CGI scripts and a small database merce proto col for lowpriced transactions It

was implemented with standard Web to ols Mosaic

The reminder of the pap er is organized as fol

browser and CERN server However it ignores

lows Section describ es work on related electronic

the complexity of real world digital cash and credit

commerce proto cols Section discusses the basic

transactions Instead chrghttp assumes that mer

Agora proto col while Section discusses its prop er

chants will bill customers at regular intervals Cus

ties Section describ es the enhanced Agora proto

tomers must register with merchants b efore anypur

wn low level col which can limit fraud to a kno

chase

Section discusses the online arbitration proto

Since Agora uses digital signatures to authenti

col which can settle certain customermerchant dis

putes In Section we discuss several limitations of cate messages its do es not require a secure commu

the Agora proto col Section discusses scalability is nication channel such as Netscap es Secure So ckets

sues The pap er concludes with a description of the Layer SSL

implementation The App endix describ es the em

Agora implements an application layer securityon

b edding of the Agora proto col in HTTP Messages

top of HTTP In this asp ect it is similar to Secure

HTTP SHTTP

Related Work

Basic Proto col

Millicent is a distributed lowoverhead digital

The Agora proto col as describ ed in the intro duc

cash proto col Its prop erties are similar to Agora

tion involves four entities banks merchants cus

Millicentintro duces a scrip which is a digital money

tomers and arbiters Agora supp orts multiple

that is honored by a single vendor Millicentisde

banks Each bank has a unique identier Bida

signed to supp ort high volume of lowpriced transac

p

s

private secret key K andapublickey K

tions Millicents overhead is similar to Agora when

b

b

used for Web commerce However Millicent requires Customers and merchants must have an account

preparation b efore a purchase from a new vendor with some bank b efore any sale or purchase can b e

name description format

p

Cid Customer ID Bid k expir ation date k Cacct k K

c

SC id Signed customer ID Cid k S H Cid

b

p

date k M name k M acct k K Mid MerchantID Bid k expir ation

m

SM id Signed merchantID Mid k S H Mid

b

Table Customer and Merchant Identication

Accounts initiated Customer account name is denoted by

C acct and merchant account name is denoted by

All customers and merchants must have an account

M acctMerchants are also identied by a unique

with a bank The bank uses a bil ling perioddur

public name Mname which can b e their IP ad

ing which customer and merchant IDs are valid

dress or their domain name Customers and mer

The bank generates new IDs for customers and mer

s s

chants haveprivate keys K and K resp ectively

c m

chants every billing p erio d The IDs expire bythe

p p

and public keys K and K respectively Cus

c m

end of the current billing p erio d or bytheendofthe

tomers and merchants identify themselves bypre

next p erio d a grace p erio d In this w ay the bank

senting signed IDs whichwere obtained from the

can force customers to pay their bills on time

bank SC id is a customers signed ID and SM id is

The proto col assumes that all participants change

a merchants signed ID

their private and public keys every billing p erio d in

Arbiters are trusted entities not necessarily the

order to prevent brute force attacks The bank de

bank that are resp onsible for settling certain dis

livers its new public key to customers and merchants

een customers and merchants Arbiters putes b etw

together with their new IDs

have the authority to repudiate committed transac

Table depicts the generation of customer

tions Each arbiter has a unique identier Aida

and merchant IDs The notation x k y k

s p

private key K and a public key K

a a

z will b e used to denote the concatenation of

The Agora proto col uses digital signatures to sign

x y and z For example a Cid mightbe

messages In the following discussion we will assume

visaabcdefdeadbeef

that we use a public key cryptography algorithm

where is a eld separator bank ID is visaex

such as RSA for computing digital signatures How

piration date is accountnameis

ever Agora can use any public key digital signature

and customers public key is abcdefdeadbeef

scheme with the appropriate changes of signature

and verication op erations

Transactions

The signature of message msg byentity x is de

noted by S msg The signature is computed by An Agora transaction consists of four messages with

x

S msg E H msg where k is the signers pri the control ow as depicted in Figure

x k

s

vate key K E is an encryption function and H is a

x

secure oneway hash function such as MD or SHA

M Customer asks for a price quotation from

the merchant

Signature S msg isveried when H msg is

x

equal to D S msg where D is a decryption func

k x

M Merchant replies with

p

tion and k is the signers public key K

x

We will use the following notation for message

M SM id k seq k pr ice k

signing

S H Mid k seq k pr ice

m

Where seq is a unique transaction ID and pr ice

S msg Signing a message with arbiters

a

is the requested price of the go o ds Seq must

s

private key K

a

b e unique for the merchant only not among

S msg Signing a message with banks

b

merchants

s

private key K

b

S msg Signing a message with customers

c

M Customer veries SM idchecks Mid ex

s

private key K

c

piration date compares M name with the ex

S msg Signing a message with merchants p

m

p ected merchant name extracts K from Mid

m

s

private key K

m

and veries the seq and pr ice Customer replies M0: request quotation

M1 customer merchant M2

M3: goods

Figure An Agora Transaction

Message M is a normal GET request for a menu with

page

M SC id k seq k pr ice k

S H Cid k Mid k seq k pr ice

c

The merchant generates M messages for all

paypayview pages referenced by the menu

M messages are emb edded in the menuin

M Merchantveries SC idchecks Cid expi

p

suchaway that they are not displayed bythe

ration date extracts K from Cidveries sig

c

browser See an example in the App endix

nature of seq and pr ice and compares seq and

pr ice with M If M passes all tests then mer

chant commits the transaction and supplies the

When the customer decides to purchase a page

go o ds to the customer Merchant should not

he generates M from the appropriate M mes

charge the customer for a reload of go o ds that

sage The subsequent GET request for the pay

were already paid for

p erview page includes M as a parameter

Merchants submit transactions to the bank for

The server resp onds with the contents of the

billing by the end of the billing p erio d The pair

payp erview page

M and M constitute a pro of of the transaction

Note that we start a transaction and generate a M

message for eachpayp erview page mentioned in

Prop erties

the menu If the customer do esnt select a page

The basic Agora proto col outlined in Section is

the corresp onding M messages will never b e gener

minimal distributed authenticated and secure We

e ated A p erio dic garbage collection should remov

elab orate on each of these prop erties b elow

old outstanding transactions

Agora is indeed a minimal proto col since it can

b e completely emb edded in HTTP messages Agora

Minimal

do es not generate any additional message compared

A minimalWeb commerce proto col should generate

with free Web browsing However some messages

the same numberofmessagesasfreeWeb brows

are longer esp ecially menu pages that contain mul

ing Figure depicts the HTTP messages needed

tiple M messages

to access a page in the free browsing case We will

denote pages that require payment for viewing by

payperview pages Menu pages are pages that refer

Distribution

to payp erview pages when payment is enforced by

the proto col

Agora is fully distributed since b oth customers and

merchants can verify the identity of others lo cally Agora proto col can b e piggybacked on the regular

p

the banks public key There is no need using K HTTP messages generated during free browsing as

b

for access to the bank and no preparation is needed depicted in Figure The emb edding of Agora mes

b efore the transaction Merchants need to contact sages in HTTP is explained b elow A more detailed

the bank once in the billing p erio d to transfer accu explanation of the emb edding can b e found in the

mulated transactions App endix 0: GET menu*

1: menu* customer merchant 2: GET page

3: page

* a menu page contains links to other pages

Figure HTTP messages for free browsing

M0: GET menu

M1 (in menu) customer merchant M2 (in GET)

M3: goods

Figure Piggybacking on HTTP messages

Authentication number seq Double charging will b e detected

immediately by the bank

Both M and M are signed by merchantand

customer resp ectively Customers and merchants

Alteration

p p

should verify signatures using K and K which

Merchants can not alter the amountcharged for

m c

are a part of of Mid and Cid resp ectively Once

the go o ds since the customer signed M which

M has b een veried it can not b e repudiated by

contains the original price

customer

ManintheMiddle

Customers and merchants can not create b ogus

The maninthemiddle M can intercept and

accounts since all IDs are signed by the banks pri

mo dify all messages b etween customer and mer

vate key

chant M replaces M withanew M that

contains a higher price quotation his SM id

Security

and signs with his own key Once the customer

agrees to purchase M submits M to the bank

Agora is secure against an adversary who can inter

pays the merchant for the original price and for

cept destroy mo dify and replay messages Wenow

wards the go o ds to the customer M pockets

briey outline various attacks by adversary and how

the dierence b etween the inated price and the

to counter them

original price

Maninthemiddle attack is imp ossible since

Replay

the customer can verify that M contains the

An old M message can not b e used for any

exp ected M name in the SM id part

other transaction byany merchant since M

contains a unique transaction ID and the mer

chants ID Replaying M generates a new M

Anonymity

messages never matchnew However old M

Agora can b e made semianon ymous by using ac

M s

count aliases and not real account names in Cid

DoubleCharging The bank should allow customers to generate new

Merchants can not doublecharge customers aliases for their accountinevery billing p erio d Cus

since each transaction has a unique sequence tomer should b e allowed to use several aliases The M0 M1 customer merchant M2 M3 broadcast: M4 M5 (occasionally) revoked IDs

bank

Figure EAgora

aliases should b e unique in the sense that no two Both typ es of fraud are due to the distributed veri

customers will b e allowed to use the same alias in cation of customer IDs without access to the bank

the same billing p erio d Each alias should b e asso

Creditcard companies currently allowa lowlevel

ciated with a distinct set of public and private keys

of fraud Customer liability is limited by amount L

The bank will keep a translation table from aliases if the customer has notied the bank within time T

to real account names

of the theft

The enhanced Agora proto col denoted byE

Since each customer mayhave several aliases

there is no single unique key that can b e used for Agora also allows a lowlevel of fraud The pro

combining information ab out him to col uses the following parameters L denotes the

customer liability limit T denotes the notication

Aliases provide some level of anonymity How

p erio d R denotes the maximal purchase rate p er

ever full anonymitycannotbeachieved with cur

p erio d T p is a probability p and M de

rent HTTP proto col since it reveals much informa

notes a price threshold Section explains the use

tion to the server

of p and M

We do not consider a low rate of fraudulent pur

Untrusted Communication Chan

chases as a ma jor problem since the customer have

nels

ample time to detect it and notify the bank Also

the extent of damage is limited A low rate is dened

The proto col can use untrusted and unencrypted

by purchases not exceeding threshold R p er p erio d

communication channels since eavesdropping is not

T

a security threat see ab ove and any alteration of

messages will b e detected byverication of digital

New Messages signatures

The EAgora proto col addresses the fraud problems

by the following additions to the basic Agora Mer

Enhanced Proto col for Lim

chants o ccasionally communicate with the bank and

iting Fraud

the bank may broadcast a list of revoked Cids to

merchants The messages and control owofE

There are twomajortyp es of fraud that the basic

Agora proto col are depicted in Figure

Agora proto col is susceptible to fraud by customers

ts are required to maintain a currentlist Merchan

and fraudulent use of stolen IDs More sp ecic

of revoked Cids and refuse to accept any transaction

b elonging to a revoked CidACid is removed from

Customers may exceed their credit limit by mis

the list after its normal expiration date

take or on purp ose

Amerchantcontacts the bank after verication of

M if either one of the following two conditions is

Thieves may go on an electronic shopping spree

true

s

with stolen SC ids and K s Since the rate

c

of electronic purchases is very high fraudulen The sum of current and previous purchases by t

the same customer exceeds a threshold M purchases may create a considerable loss

Discussion A uniformly distributed random value r in the

range is p

A thief is a p erson who manages to illegally get hold

In all other cases a merchantdoes not contact the

of some other customers ID and private key A thief

bank during the transaction as is done in basic

who go on a shopping spree will b e stopp ed as so on

Agora

as he sp ends L or less A shopping spree is dened as

If any of the ab ovetwo conditions is true the

frequent purchases in a short p erio d of time If the

merchant sends message M to the bank

thief is purchasing exp ensive items value more than

M each item will b e immediately deducted from

M Mid k Cid k pr ice k S Mid k Cid k pr ice

m

the customers account The thief will b e stopp ed

after sp ending R during p erio d T If the thief is pur

pr ice is the sum of current and previous pur where

chasing from a single merchant even cheap items he

chases by the same customer whichwere not already

will also b e detected as so on as he sp ends more than

sent to the bank

R If the thief is buying less than M from mul

After receiving message M the bank up dates the

tiple merchants his purchases will b e rep orted to

customer balance If the customers purchase rate

the bank with probability p He will b e stopp ed as

exceeds rate R p er p erio d T or the customer ex

h so on as his rep orted purchase rate exceeds R whic

ceeded his credit limit the bank do es not approve

means that M purchases were rep orted to the bank

the transaction and also revokes Cid Otherwise

This is equivalent to total purchases of L

the bank accepts the transaction

A customer who exceeds his credit limit will b e

When pro cessing of message M is completed the

handled in a similar way Since account balance is

bank replies to the merchant with M

up dated every p erio d T bybatch pro cessing the

bank can immediately detect over the limit pur

M Cid k code k S Cid k code

b

chases of exp ensive items more than M If the cus

where code denotes whether the bank accepted or

tomer purchase cheap items from many merchants

rejected the transaction

he will b e detected with probability p byamerchant

which means that he will make purchases on the

p

average b efore b eing detected The maximal value

Batch Pro cessing

M

of over the limit purchases is L

p

Merchants should communicate with the bank once

in every period T and transfer batches of transac

tions Usually this communication will b e p erformed

OnLine Arbitration

at op eak hours In this way customer balance in

the bank is never out of date by more than T To

Certain disputes may o ccur in the scheme wehave

reduce overhead the bank may piggyback a list of

outlined ab ove For example a customer maysend

revoked Cidsonany message to the merchant

message M but receive partial go o ds or dierent

go o ds than ordered The customer mayeven not

Selection of Parameters

receive the go o ds at all In this case the customer

would like to get the go o ds or get a refund since

p are derived from L and The parameters M R and

he already agreed to pay A trusted arbiter can set

T as follows

tle the ab ove disputes The arbiter can not settle

more complicated disputes such as false advertising

M p L

M

by merchants These disputes should b e settled by

R

T

humans Figure depicts the arbitration proto col

The value of p is chosen so that it reduce the

and its control ow

overhead of sending M andM p should not b e

The arbitration proto col makes the following mo d

to o small in order to keep M reasonable large M

ication to EAgora proto col

should represent a transaction value that is cost ef

fectivetocommunicate to the bank Also R should

The merchant includes a secure hash value of

b e an acceptable purchase rate

the goods in M

As an example of a reasonable choice of parame

ters L is T is hours p is M is The customer sends M tothemerchant and

and R is p er hours Since the proto col is in exp ects the go o ds If the customer do esnt re

tended for lowpriced transactions such as cent ceive the go o ds at all or if the checksum of the

these limits are acceptable received go o ds is dierent than what app eared M1 customer merchant M2 A4 or A4’ A2 A3 A1

arbiter bank A5

(if arbitration fails)

Figure Arbitration Proto col

s

in M then the customer contacts the arbiter Another problem is stealing SC id and K from

c

by sending message A where A M k M the customer This problem exists in all other pro

to cols to o

The arbiter asks the merchant for the go o ds by

sending message A The arbiter signs the re

quest so the merchant can validate it This

Scalability

prevents eavesdropp ers from asking for go o ds

that someb o dy else paid for

Any practical electronic commerce proto col must

handle a large numb er of merchants customers and

If the merchant replies with the correct go o ds

transactions We assume that the total number of



in message A then the arbiter forwards it to

active accounts is and of all accounts are re



the customer in message A

voked every billing p erio d accounts Most re

vo cations are due to lost or misplaced accountiden

In all other cases merchant do esnt reply or

tiers

replies with incorrect go o ds the the arbiter re

The main implementation complexity of the E

pudiates the transaction The arbiter sends a

Agora proto col is that all merchants must maintain

repudiation message A to the bank with a copy

a current listofrevoked Cids and refuse to accept

to the customer A

any transaction b elonging to a revoked Cid The

bank can eciently broadcast a list of revoked Cids

using some Internet broadcast proto col Merchants



Caveats can easily store a list of revoked Cids in their

lo cal disk since this list should not consume more

The Agora arbitration proto col assumes that the

than MB p er billing p erio d The list is cleaned

go o ds are static that is their hash value do not

by the end of the billing p erio d

change from the time M issent to the customer

Checking a Cid against the list of revoked Cids

until the go o ds are actually delivered Another prob

can b e p erformed by an application of a Blo om

lem is that the arbitration proto col can not detect

lter A Blo om lter consists of m bitsofmem

delivery delays of timesensitive information suchas

ory initialized to zero and k hash transformations on

sto ck quotes This means that the arbitration can

Cid All hash transformation pro duce an integer in

not deal with dynamic or timesensitive information

the range m Eachrevoked Cid is stored in

Agora security is based on the security of the

the lo cal disk and the k hash transformations are

banks signature A security breach at the bank will applied on it The corresp onding bits of the lter

allowanintruder to sign fraudulent IDs and conrm are set to

the resulting transactions Since all other proto cols

TocheckaCid against the revoked list the k

assume that the bank can b e trusted we will also

hash transformations are computed If anyofthe

do so

corresp onding bits are not set this Cid has not b een

Agora generates new SC id for all customers ev ery revoked If all corresp onding bits in the lter are

billing p erio d Wehave to use some highly secure set wehavetocheck the lo cal revoked list to ensure

p

proto col to transfer SC id and K that this Cid has b een indeed revoked since there b

Conclusions is a p ossibilityofa lter error Filter errors o ccur

when the k bits have b een set by a collision with

Agora is a simple creditbased lowoverhead proto

other Cids

col for electronic commerce The proto col is ideally

The following table depicts the probability of lter

suited for highvolume lowpriced transactions such

errors for representative m and k In all cases we



as payp erview access to Web pages The proto col

assume that the lter contains revoked Cids For

can b e piggybacked on currentHTTPmessages

computation of lter error probability see

m k problter error

References



bits MB



bits MB

David Chaum Achieving Electronic Privacy



bits MB

Scientic American pages August

Benjamin Cox J D Tygar and Marvin Sirbu

Since the entire Blo om lter can b e stored in main

NetBill Security and Transaction Proto col In

memorywecancheckagiven Cid against the lo cal

First USENIX Workshop on Electronic Com

revoked list in a constant time IO op erations are

merceNewYork New York July

required only for revoked IDs and infrequent lter

errors

Alan O Freier Philip Karlton and Paul C

Ko cher The SSL Proto col Version Internet

draft draftfreiersslve rsiontxt

Implementation

March Found at

httphomenetscapecomengssl

We implemented the Agora proto col using standard

Web to ols a Netscap e Navigator browser and

Mark S Manasse The Millicent Proto cols for

a NCSA server The customer side is imple

Electronic Commerce In First USENIX Work

mented bya Java applet and the merchant side is

shop on Electronic CommerceNewYork New

implemented by a set of CGI scripts and a small

York July

data base There was no need to mo dify either the

M V Ramakrishna Practical Performance of

browser or server software We also implemented a

Blo om Filters and Parallel FreeText Searching

bank of limited capabilities that can only generate

Communications of the ACM

signed IDs The currentversion of the bank do es

Octob er

not resp ond to M messages neither it can revoke

IDs We did not implement an arbiter yet

E Rescorla and A Schiman The Secure

The implementation is straightforward except

Hyp erText Transfer Proto col Internet draft

for the Java applet which had a securityproblem

draftietfwtsshttptxt July

and a p erformance problem

httpwwweitcomcreationsshttp

A secure Javaenvironment prevents applets from

accessing lo cal les if the applet is loaded from the

Lei Tang and Steven Low Chrghttp A To ol

network That is an applet can not keep lo cal state

for Micropayments on the World Wide Web In

on the customer machine However for our scheme

Proceedings of the th USENIX Security Sympo

we need to keep some lo cal state such as balance and

sium San Jose California July

a transaction log in the lo cal machine Weevaded

Visa and MasterCard Secure Electronic Trans

this problem b y writing a stateless applet that con

s

action SET Sp ecication Bo ok Technical

tained hard co ded SC id and K

c

Sp ec

Other known security problems with Netscap e

ications Found at httpwwwvisacom

Navigator mayallowanintruder to eavesdrop and

cgibinveesfsetsettechhtml

then switch pages of the browser co de or any pro

February

gram that the browser executes The solution of this

problem is outside the scop e of the Agora proto col

We implemented public key encryption entirely in

Java without native co de which is ab out times

slower than native C implementation The p erfor

mance will improve with JIT Just In Time com

piler technology

App endix

Emb edding Agora Proto col in HTTP Messages

Message M is a normal GET request for a menu page

The merchant generates an applet activation for each reference to a paypayview page in the menu

Instead of generating one M message for each reference in the page the merchant generates a single

M message whichcontains a concatenation of all transaction IDs and prices of the corresp onding M

messages M is constructed as follows compare with Section

M SM id k seq k pr ice k k seq k pr ice k

n n

S H Mid k seq k pr ice k k seq k pr ice

m n n

Replacing multiple M s with a single M reduces the numb er of digital signatures without compro

mising the security of Agora

For example a menu page contains the following references

A picture of

g priceMount Everesta a hrefprotectedEverestmp

A picture of

a hrefprotectedufompg price

a UFO over the White Housea

The resulting page contains the following applet activations

A picture of

applet codebuyerclass widthxxx heightxxx name

param namem valueM

param namenritems value

param textMount Everest

applet

A picture of

applet codebuyerclass widthxxx heightxxx name

param texta UFO over the White House

applet

The applet name is its sequence numb er in the page The lengthy M message is given only to the rst

applet which sends it to all other applets Each applet extracts its own transaction ID and price from

M

The resulting menu page is longer than the original page since it contains several applet activations

and one M message instead of direct links to pages However the resulting page is still contained in

a single message

When the customer decides to purchase a page he generates M from the appropriate parts of M

message The subsequent GET request for the payp erview page includes M as a parameter For

example

GET httpserveraddresscgibingatekeeperM

The server resp onds with the contents of the payp erview page