FC04 - Financial Cryptography 2004

9-12 February 2004, Key West, Florida, USA

(about these notes)




                        Jack Selby – Lessons from Paypal

                        Ron RivestPeppercoin Micropayments

            Loyalty & Micropayment Systems

Zulfikar Ramzan & Craig Gentry - Microcredits for  Verifiable Foreign Service Provider Metering

Matthias Enzmann, Marc Fischlin, Markus Schneider -  Privacy-Friendly Loyalty System Based on Discrete Logarithms over Elliptic Curves

            User Authentication

                        Stuart Stubblebine – Addressing online dictionary attacks

                        Lawrence O’Gorman, Smit Begga, John Bently – Call Center customer verify. w/ querydirected passwords



                        Jaques Stern - Cryptography and the French Banking Cards: Past, Present & Future

                        Simon Pugh - Security & Risk Management for Transactions for Paypass


                        Aggelos Kiayas - Vector Ballot E-voting Approach

                        Jens Groth - Efficient Maximal Privacy in Boardroom Voting and Anonymous Broadcast

            Building Usable Security Systems

                        Andrew Patrick - Usability & Acceptability of biometric security systems

                        Jean Camp – Risk Perception Failures in Computer Security

                        Bill Yurcik – Visualization Tools for Security Administrators

                        Ka-Ping Yee – Principles of Secure Interaction Design

            IFCA Meeting 2004

            Rump Session



                        Jon Peha – Bringing Payment Technology to the Unbanked (Cyphermint)

            Auctions & Lotteries

                        Koutarou Suzuki - Secure Generalized Vickrey Auction without 3rd party servers

                        Moti Yung w/ Elisavet Konstatnou et al - Electronic National Lotteries: Design & implementation

                        Helger Lipmaa w/ Edith Elkind - Interleaving Cryptography and mechanism design: Online Auctions

                        Giuseppe Ateniese and Breno de Medeiros – Identity-based chameleon hash and applications


            Game Theoretic & Cryptographic Tools

                        Vanessa Teague - How two selfish players can select correlated random actions

                        Pino Persiano - Efficient and Usable Multishow Non-transferable Anonymous Credential System

            Mix Networks and Anonymous Communications

(About these notes)     



Opening Remarks

Hilde: Announcements: Cocktail reception beachside 5-7 Wed, Tuesday General meeting 8-9, after which rump session

Ari:   Tradition of having FC on tropical island.  We tried to get the US Secretary of Treasury, but he’s busy.  Maybe next year he’ll be unemployed. (applause) Changes to ecash didn’t happen as fast as we thought.  Major US change was an enlargement of Jackson’s head on the $20.  Theme: why hasn’t the shift happened?  Thanks to organizers, board, submissions, attendees. (A delayed thanks for program committee, and a call for participation for rump session)



Jack Selby - Lessons from Paypal

He’s not a cryptographer or technologist, but was employee #9 at paypal.  Raised financing ($20 million/month burn) had to deal with regulators.  Now with Clarion, a hedge fund/VC office.   

Priority #1 for any scheme: meet demand from both buyers and sellers. 

Payment scheme is a chicken & egg problem:

Consumers have to trust it, merchants have to accept it. 

Paypal came about when VC was plentiful—had the ability to get product out there. 

(Gave people $20 to sign up). 

Market was dense, online, unexploited, sophisticated: online auctions.

Merchants had high cost of CC purchase

            High fixed costs (diminishing MC) for small-medium sized merchants

            Innefficiency inherent in CC space

                        Q: why not pc cc processing SW?

A: still have huge fraud costs

Priority #2: reachable, scalable markets

            Great partitioning slide of mkt graph: size of receipt by risk/immiediacy of transaction

                        Friend-friend : pay w/ cash

                        Long term relationships (landlords, doctors): checks

                        Person-person(less trust): western union

                        Large merchants: credit card

                        Paypal:  small businesses & auctions

                                    High risk merchants: adult, gaming –

Tapping an inelastic demand curve

            Initially, gave it away for free

            June 2000: started charging for it, and kept increasing price

                        à no drop off in usage à inelastic demand

            [Inelastic demand curve means that consumers will continue to buy even if prices rise]

Execute and focus on a business model

            Caveat: “We didn’t really have one at the beginning”

            profitable business model meant: had get consumers away from funding acct w/ cc

                        Driving costs down

            Businesses pay (must pay?) to use the system

                        Drive revenue up

Evolve technology to meet needs

            Technology was only 4th priority

            Random deposit: send two random deposits to authenticate <email, acct #>

                        Outsourced authentication to customer service of the banks

(much to their displeasure)

                        Skewed the random value to avg $.30 to save $

            Fraud inside and outside

                        1.23% fraud in 2000

                        had to implement inhouse fraud protection

                                    lots of inhouse data, mine it!


            Working with banks & consortia was a nightmare

            Any business model that is dependent on banks is dead in the water

            BUT: competing with banks is great!

                        V/MC could have shut them down easily

                        They just weren’t in an innovative frame of mind

Why have other schemes floundered?

            1. Poor platform choice: (paybox – several SMS payment messages)

            2. Non-need for consumers & merchants

                        Amex Blue Card: premised on online purchase exclusive

                        Beenz/Flooz: no money to overcome chicken & egg

            3. Poor marketing

                        eVisa, Secure MC: marketing by fear online

                                    like selling a house in a bad neighborhood by claiming is has good bars

Promising payment schemes

            Gov’t IDs – smart cards

            Online “online” debit

                        Need to protect banks from fraud

                        Have to work with banks

Online markets with scalable, inelastic demand

            Music, gaming

            Q: gaming market size? A: dunno

            Q: how are people paying now?  A: based outside US, can’t come back

            Q: why not go after western union?  A: they’re trying to ignore destination

Conclusion: don’t let technology tail wag the dog of the business model

Q: How much did you spend on customer promotion?

            A: Raised $200 million, probably $40 million went in

Stuart: people are buying stupid security snake oil for FUD, even though it doesn’t make sense

            A: selling a sort of insurange

C: for banks, “fraud is a client” –moti yung

Q: regulatory concerns

            A: 1) just a money transfer and 2) a reliable money transfer (state by state) 3) PATRIOT

Q: gaming regulations

            A: Only spitzer seemed interested in enforcing wire transfer

Q: How did forming relationship w/ ebay work out?

A: Worked with Marty Hellman to get product to beam funding over Pilots

                        Marketed with “Scotty” – “Beam me up”

            Built in functionality for “what if he doesn’t have his Palm”? – use email

            Realized that the email piece was better

            Ebay had a Billpoint technology, but allowed paypal to muscle in

                        cash registers at auctions”

                        Could have driven them out by being mean, but worked out a deal        


Ron Rivest - Peppercoin micropayments

Peppercorn is the smallest amount for contract payment in English law


            Small enough that transaction costs matter ($.01-$10), avg $.50

            Lydians invented coins ca. 640 BC

                        Before then, small purchases difficult w/ gold bars, etc

            Analog today with CC

Generic payment framework

            Cust Alice, Merchant bob, with their own PSPs (banks?)

            1. alice gets authorization

            2. alice pays bob

            3. bob deposits

            4. Bob’s PSP settles with Alice’s

            5. Alice pays her PSP

How we’ll make small payments

            Web downloads

Apple is proving market exists, but isn’t making $ b/c of transaction costs

            Mobile phones – maps, ringtones


            None – inefficient

                        Chaum (benefit: it’s anonymous)

            Merchant level – depends on consumer demand, only works sometimes

                        Itunes: Wait to see if customer will make more purchases

                        Barrier of total single consumer spending


Centralized micropayment server as an added mech

            Additional complexity

            Kind of paypal mech

                        Doesn’t scale as well

            Universal (peppercoin) – driven by savings for merchant

                        Merchant prefers $0 for 19 payments and $10 for one to 20 $.50 payments

                                    Given transaction costs

                        Merchant samples revenue stream: law of large numbers

                        BUT: consumer MUST only pay for what spent

                                    Each payment has an assertion for cumulative payment to merchant

                                    Gets billed for total amount spent at all merchants

                        Also works for offline accounts

                        Q: how does alice keep state information properly

                                    A: check inconsistencies, w

Will later be able to protect consumer info from tampering

(Mention of DRM sets of rumblings from the mob)

Q: What tech is pushing what?

            A: any fraud will be manageable

Q: Can I double spend?

            A: payments are ‘electronic checks,’ can’t be transferred, but do want to have a receipt

Q: Chargebacks?

            A: need to push it back on the merchant in an automated way (customer service, esp)

Q: can alice game the system?

            A: needs a very slow information rate if consumers only see bills once a month

Q: do we need additional information mechs to do all the error checking you’re thinking? 

A: no.

Not a new currency, but extending existing payment mechs to micropayments

            Lots of activity below radar of existing, occasionally kicks up to even out

Dimensions of problem


            PSP online

            Interactive or non-interactive (anti-spam payment)

                        Q: spammer generates 10 million messages, ‘pays’ but then defaults à no payee recource

                        C: model depends on a limited # of merchants, won’t work for spam

                                    A: can misuse a credential [so can be defrauded as before]

                                                BUT: can detect some fraud automatically

Previous work

            Lottery tickets: interactive protocol of collisions of hash: merchant “wins” payment

                        Non-interactive: use deterministic digital sig for collision

Computational cost: getting cheaper

            Online/offline precomputation

Variable-sized payment: need to convert probabilities based on size of transaction

Is revenue variance an issue?

            Cost savings make up for statistical variance

Fraud models for peppercoin

            PSP only has partial information

            Merchant and consumer can collude

Q: Transaction cost is because market will bear, not actual cost: it’s a marketing issue

            A: Debit cards make

Loyalty & Micropayment Systems


Zulfikar Ramzan & Craig Gentry - Microcredits for  Verifiable Foreign Service Provider Metering

Foreign service phone providers can lie about how much roaming minutes were used

Simple approach: hash chain is signed, given to cell phone

            Foreign service provider (FPS) checks the hash, adds new value

            Home service provider verifies chain

BUT: hash chains are linear, can get long

Design goals:    FPS and HSP shouldn’t overcharge user (proof)

                        No undercharging consumer either

            FSPàuser shouldn’t do too much work O(1)

            Minimize communication between user à FSP O(1)

Proof size is log t

Related work:

            Hash chains for micropayments, paytree

            Micropayments for wireless

Quasimodo tree

            Leaves are assigned random values, hashed up to a root (like a merkle tree)

                        BUT: can get values in the tree with some set of nodes

                        FSP stores some node values over time, making each add’l query fast

            Smaller tree, credit size, verification time than merkle trees

            BUT: cache stored by FSP

                        Not that bad: 3 hours capacity for 5000 users: 100 M

            BUT: larger packets sent

It’s a microcredit system b/c users pay “tokens”

If good assumptionsà can prove no overbilling or underbilling


            Polling to reduce computation, but increase risk of fraud

            Group signatures


Matthias Enzmann, Marc Fischlin, Markus Schneider -  Privacy-Friendly Loyalty System Based on Discrete Logarithms over Elliptic Curves

Loyalty program: means to achieve customer retention

            Guarantee future earnings (lock in)

            Better resource planning

            Customer Retention even harder online: customer fluctuation high, easy to shop around

            Reward “loyal behavior”: strong preference, repeated xanctions

                        Buy X, get 1 free

                        FF miles

Privacy issues

            Require customer identity, managed by vendor

Reqs for electronic privacy loyalty systems


                        Must not be possible to link issue processes of loyalty points

                        Purchase must not be linkable


                        Customer can’t make loyalty points, can’t double spend them


                        If customers can pool benefits, merchant doesn’t get as big benefit

                        Different from collusion: multiple buyers sharing same ID

Counter scheme

            No central repository: each cust has a counter

                        Better than tokens b/c of only one object

            Have to hide value à use elliptic systems



                        Choose a curve, and a secret key


            Issue ith loyalty point

                        Send blind counter to merchant who signs it

                        Updated counter returned to customer

                        Customer verifies w/ properties of elliptic curve

            Redeem rewards - unlinkable

Security against pooling

            Incremental Diffie-Hellman (iDH) problem defined

                        Random oracle model

            Need b to the 2 to the n

                        No alg known that allows this problem in parallel

                        Power b is unknown

            à not possible to pool

Vendors can detect previous use

Q: What about the pointer that I got the 95th point after I spent a full hundred?

            A: The history of the token becomes invalid when spent: can’t spend same S twice

Q: If customer loses serial number, is it recoverable?

            A: no.  Vendor doesn’t have anything recoverable

Q: Business model?

            A: Privacy more important than consumer data?


User Authentication

Stuart Stubblebine – Addressing online dictionary attacks

Pinkas & Sander’s login protocol

            Human in the loop, reverse turing tests,

Problem with passwords

            Insecure when generated by people

            Unusable w/ good security

            Vulnerable to automatic dictionary attacks

                        Account lock-out à support costs, DOS

Naïve attempts

            Get Reverse Turing Test (RTT) for each id/pwd entry

                        Or just on some tries

            Can’t just get RTT for correct pwd entry

            Attacker typically has multiple attempts

P & S

            Enter ID, pwd, cookie (if present)

                        If id/pwd correct & cookie valid à enter

                                    If cookie not valid, get RTT

                        If pwd wrong, ask RTT with 10%

                                    Say that login failed


            Reduce threat of cookie theft by only storing cookies on “trusted machines” (?)

            Have a non-owner mode that user can set

            If cookie not valid: check # of failed login

                        If not in owner mode, and have few failed logins à get in with RTT

            If password fails, give RTT if multiple attempted login

            After I’ve failed pwd a bunch of times, need an RTT each times

            w/ cookie, never get RTT with

            non-ownder mode, threshold applies

Cookies not stored on non-owner operated machines

Parameters can be managed dynamically

Relay attack on RTT-based login protocol

            Malicious adversary has naïve user answer others’ RTTs with

Soln: Embedded warning

Sweatshop attacks

            Soln: notification of failed logins

            BUT: help desk support req’d

Improvement: attacker will answer some RTTs no matter what

Need better metrics for security vs usability

Q: can it be used for DOS?

            A: yes, but can balance, and ramp up time

Q: how many people fail RTTs?

            A: we don’t know

C: RTTs getting harder


Lawrence O’Gorman, Smit Begga, John BentlyCall Center customer verify. w/ querydirected passwords

Problem: eliminate personal information in customer verfication

            Costs money in terms of man hours, stored data, etc

            “Secrets” are standing targets for attackers

                        Learned by agents

                        Heard by eavesdroppers

                        Not private according to HIPPA


            Convenience is most important

            Low cost

            Secure (anything that’s an improvement)

            App: health insurance & financial call centers – telephone is still needed

            Tech: phones

                        No computation

                        Plain text

User authentication

            What you have: Tokens are expensive

            What you are: biometrics are unreliable (talk to him afterwards)

            What you know

                        Push: memorize password (people are annoyed)

                        Pull: something that is always there

                                    Traditional (mother’s maiden name)

                                    New (this paper)

Related work

            Incremental Personal question

            Incremental Challenge-response

                        Often image based

Query-driected passwords (QDP)

            N questions

            M multiple choices

            User selects n questions to answer

            Some are better than others

            Not as vulnerable to brute force

            Not as vulnerable to eavesdropping

QDP + something

            Phone in & authenticate for the question

                        Question sent to phone, which is used to answer question

                        à Token

            Client stores info: Wallet card


                        Wallet card as a codebook

                                    Card helps user get keys to answer questions

                                    Text + index

Uses an interactive telephone agent

Usage results

            Recall rate: 92-95%

            Not pure data on imposter rate

                        Obviously: closer you are to a person, easier they are to imposter

                        Soln: use different epochs in their life

                        ALSO: if I’m close to some one in general, can get maiden name etc

            10 minutes for users to enroll – people hate it

                        Verification: 1-2 minutes

Open research

            Answer distribution: want questions with close to uniform prob

                        Entropy vs. keyspace

                        Know that a smart attacker will never choose the low prob.

            Information extraction

                        Need numbers that are not searchable through databases

            Question authoring

Q: personal information release makes people uncomfortable

            A: consumers can not answer things, 3rd party doesn’t require answer to all questions, consumer can choose which to answer a priori

Q: for verification, people lose patience after 3

            A: these are people who need passwords for pwd recovery, enrollment is 8 questions



Moti Young: Rump session announcement;

            Introducing Jaques Stern: He was a mathematician, who moved into CS, and actually started to do CS.  Excellent advisor to many students, great work in cryptography, consults with the French Government: instrumental in opening France up to crypto business.


Jaques Stern - Cryptography and the French Banking Cards: Past, Present & Future

Slide: A Frenchman with a banking card as a diver off key west – surrounded by underwater meanies

History of the French banking cards

            1967 – plastic cards

            1971 – magstripe cards

                        2 tracks: ISO1, ISO2

                        Main data (in clear)

                                    Primary Acct Number (PAN)

                                    Expiry data

                                    Service data


                                    Enciphered PIN code

                                    3-DES MAC (card verification value)

Magstripe attacks - Stripe can be copied

            Physical additions to an ATM machine w/out users knowledge

                        Magstripe reader over insert slot

                        Camera to view PIN entry

            Can manufacture another card  

1990-1992 – moving to chip cards (“Going the French way”)

            Takes 2 years to phase in new technology

            Put chip into IC module, put it on a card, add data to plastic, stripe, chip

Non-crypto security measures

            Security also lies in contract regulations and criminal law

                        Protections for liability

                        Laws against fraud as a deterrent

            Visual devices for merchants to recognize fake cards

            Printed security code on back of card

                        Although: Security code is crypto-generated

            Fraudulent use detection w/ scoring systems

Chip security - Certified by Common Criteria, standardized HW security

Crypto Security 1990 – B0’

            Offline authentication

            PIN code

            Transaction logs w/in card

            (triple) DES

Chip-terminal dialogue (“Please think about flaws”)

            Card presents itself w/ card #, authentication value (RSA sig of PAN)

                        Terminal checks sig

            PIN code is sent to card, which checks against card

            Card 3DES signs transaction information (sym cryptogram)

                        Terminal sends cryptogram to authentication center

1998 Humpich case

            Humpich manufactured a card, used it in an offline context

            Claimed that he had subverted the Great French Plan, but he wasn’t smarter than us!

Flaws with 1990 plan

            Circumventing RSA: RSA was 320 bits

                        Humpich found factoring program, got RSA modulus

                        à Now they use 800 bits, soon to be 1024

            Circumventing PIN code: yes cards automatically say that they are

                        Says ‘Yes’ when I enter the PIN

                        W/ a copied RSA signature

                        à Go online more systematically, or all the time

                        à Quick detection

                        à blacklist bad cards

                        à migrate to DDA

EMV & Dynamic Data Authenication (DDA)

            Designed by V/MC, will be deployed throughout Europe

            Challenge response

                        Card signs challenge w/ private key

                        Provide Cert of issuer signed by matching public key

                        Terminal checks cert & signature

Cross-border fraud

            Have to use card in a country w/out chip capability

            Not breaking crypto, but bypassing

Card Number capture

            Merchant theft, theft from merchant

            Crypto can’t do much

Crypto 20 years from now

            Very large RSA moduli?

            Elliptic Curves?

            OR: only symmetric keys for all transactions online

French people now carry 2 crypto processors all the time: GSM phone, Banking cards

DDA has good security, remaining attacks bypass crypto

Q: Attempts to present multiple pins for yes cards?

            A: no, it’s customer service hassle, PIN isn’t really crypto

Q: What happened to Humpich?

            A: Convicted, suspended sentence, wrote a book


Simon Pugh - Security & Risk Management for Transactions for Paypass     

A: (from above talk, based on his work) Mgmt for PK & EMV: issuer keys aren’t on terminals, but V/MC list of keys is

BUT: - I’m not talking about EMV cards, but I am talking about Paypass

Contactless smart cards

A response to transponder systems like EZPass, key-fob gas payment systems (speedpass)

            All tie to credit card at the end of the day

            Phones also have been proposed as the primary payment device

US market

            Huge size, huge Infrastructure investment

            National mechanism to do something is hard

61% of consumer payment still conducted w/ cash & check

            Designed for small ticket price, to replace cash products

            (don’t want to cannabilize own products)

            Improve convenience, speed, better than magstripe card

Design issues

            Keep in mind EMV migration, high phase-in time

            Need low incremental costs for tokens, acceptance scheme

            Want a brand presence, leverage existing infrastructure



            ISO 14443 standard – familiar, already deployed

                        Token isn’t powered (Passive RFID)

            Time of .3 sec to read

Proximity design to be about 5cm


Risk assessment – shouldn’t present more fraud than magstripe card

            Eavesdropping – genuine transaction could be overheard by rogue terminal

                        Similar to magstripe skimming

                        Can eavesdrop from about 20m, depending on POS term, antenna, noise

            Pickpocketting - Someone does a fake transaction with card w/out knowledge of reader

                        Can build a big terminal w/ 1.5m range ($25,000, not portable)

                        (Many comments about how to hide it)

            C: privacy issues as well.

            Cloning, and reusing in different channel


            Prevent attacks by protecting interface

                        PKS would be expensive, hard to fit on transponder, hard to manage

            Make attacks useless by making data unusable

                        This approach will be better

            Terminal must differentiate how card was read, so people can’t clone online

                        Send account data + dynamic CVC3 calculation

Magstripe Dynamic CAM principle

            Terminal creates unpredictable number, send it to card

            Card creates unique CVC3, using number, card data, secret 3DES card key

            Card sends CVC3 to terminal

            Terminal updates CVC3

            Terminal checks transaction with issuer

            Q: If CVC3 is only 3-5 digits, can you search the space?

                                    A: It’s stored in decimal values, but yeah. 

            Q: why did you use the DD field?

                        A: nowhere else to put discretionary data in existing protocol

Fraud scenarios

            Eavesdropping: Fraudster can’t reuse CVC3 because card will detect it

            Simple pickpocketing: terminal supplies UN that won’t match recorded reply

            C: merchant fraud: some one leaves their term set for $20 for all passerby

                        A: merchant fraud can be detected, prosecuted

            Cross-contamination: we check for this, since paypass has unique feature

                        Steal paypass data, try to create magstripe card

Focus is on detection, rather than prevention

            Detection prevents reuse

Q: Regulator issues

            A: will roll it out, work with other cards, standardize for interoperability

Q: Cross-contamination: what is impact of field on other magstripe cards

            A: fields don’t impact other stripes

Q: Privacy issues

            A: Reader distance is important for legit; what can illicit users really do?

                        Improvement over

Q: Can people have a protection?

            A: wallets

Q: Time?

A: They shaved several seconds at McDon for the total transactions

            (Had to tinker with placement to prevent SUVs from knocking it down)

Q: Backup for payment failure?

            A: Deploy as dual-use for card as well.



Aggelos Kiayas - Vector Ballot E-voting Approach

Three basic approaches to evoting

            mix-net (chaum)

            homomorphic encryption (benolah)

            Blind authority

3 basic properties

            Universal verifiability – anyone should be able to verify that the tally includes all votes

            Efficient Tallying

            Writein Capability – voters can submit any value, not just value from a set

            (Also, privacy, prevention of double voting)

Question: How do the three basic approaches perform with three basic properties?

Mix-net - Mix encrypted ballots in many mixers

            Voter privacy and double voting are handled (mixers don’t collaborate)

            Writeins allowed

            Mixers must prove that they didn’t affect any ballots

            BUT: efficient tallying takes a

Homomorphic Encyrption

            Voter gets a PhD, proves that ballot if formed properly

            Votes compressed into single cyphertext

            Decrypted by a set of authorities

            Privacy, double voting handled

            Efficient, verification are good

            BUT: no writeins – inherent in design of compressability

Blind signature - Blind authority signs ballot, eliminates double votes

            Votes aggregated through anon channel (like a non-robust mix-net)

            Writeins allowed, efficient tallying

            BUT: universal verifiability

                        Need to have voter check on the output

SO: no evoting technique satisfies all three things we want


Homomorphic encryption doesn’t give us writeins,

            Mix-nets are too hard to tally

Vector ballots – 3 submission components

            Have a homomorphic encryption function E

            Predetermined candidates all have numbers

            Choose candidate: encrypt his/her number, and other 2 values are 0

            Choose writein: encrypt 1st value 0, second 1, final is writein value

Mutual exclusive writein/candidate selection

Voter must do some work to prove value is good

Voting w/ vector ballots:

            Break ballot into the 3 components

            Use homomorphic enc. to compress other ballots

                        Can easily get candidate winner

            Write-ins: Shrink & mix-net (new notion)

                        Can find out whether a bunch of ballots have a write-in vote

                        Privacy contained by having a big group

                        If 1% votes are writein, 20 ballot batches: can throw away 81% of batches

                        Now we can use a mix-net

                                    Not time-sensitive at this point

Other issues

            Need the capacity of compression mech


Jens Groth - Efficient Maximal Privacy in Boardroom Voting and Anonymous Broadcast

Anon broadcast: N players each have a vote they want to say, w/ anononymity

Election privacy: vote1 = result – sum(other votes)


Perfect ballot secrecy: coalition information à own votes & result, not other votes

Self-tallying – result reveals itself

Dispute-freeness: dishonest behavior detectable


            BBS – permanent, public message w/ known author

            Phases and stages, possibly controlled by adversary


            Registration: Each player registers a key Xi

            Voting phase: cyphertext is modified

            Each voter uses key, adds his own vote, rerandomizes the cyphertext


            O(1) key generation

            O(n) verification of proofs

            Voting O(log c)

            Verification O(n log c)


            We cannot guarantee security only after all voters have announced their vote

Panel – Building Usable Security Systems


Andrew Patrick:

Sampling of usability research: how do we make security systems more sensitive to the way people work?  We’ll have brief presentations and then discussion

Human Factors – anything that involves the user in any way


            Users – memory, motivation, can be rational, physical characteristics

            Goals and tasks – usually the focus is on goal, security is secondary

            Context of use – physical location, identity, embarrassment.


Andrew Patrick - Usability & Acceptability of biometric security systems

Many metric methods

Drivers increasing usability

            Sensors are better, cheaper, more robust – each can be bought for $100 or less

            More transparent to users

            Getting associated with access control

Concerns are performance, accuracy/convenience trade-off, physical characteristics like aging

Research being done on usability


                        Anthropometric studies: locate eyes

            Design: finger swiping for fingerprint

            Field trials for iris recog was highly accepted

                        à false rejection has to be 0!

            Iris scanning: need to look at image and scanner at the same time?

            Ergonomic issue for fingerprint scanners

            People need feedback for these systems

Acceptance drivers

            Technical interest

            Identity theft fears

            Memory load – people aren’t good at memorizing things

Concerns about acceptance

            Benefits not evident, esp. because you can’t transfer permission

                        People don’t see dangers of pins, think that they will cheated

            Worried about public failure = emberassment

            Privacy: can we get original image from digital template

Canadian study

            Didn’t know what biometrics were

            Have worries

            BUT: it will help, is coming anyway

Fundamental issues:

            They’re unique

            Need a live-test

            Covert use

            Single-use biometric system – tie fingerprint to a single application


Jean Camp – Risk Perception Failures in Computer Security

Metaphor: need to communicate environmental risks to people to change behavior

            Paint thinners are known as bad, household cleaners are as bad

            Need to link the two

Mental models – what do metaphors imply about problem and response

            Market failures – costs and downtime

                        Need regulated market, liability, insurance, incentives

            Crime or war – attack, defense, perimeter

                        People think they can rely on defenses

                        A failed model for end users

                        Soln: Go shopping if you’re in the US J

                        à Direct mandates, law enforcement

            Illness – virus, infection, epidemics

                        à computer hygiene, “public health” information

                        This is what we want: simple things that you have to do

                                    Better than market failure

                                    No one says “I’m not going to get the flu because I have no assets”

            Animals – bugs, infestation, monoculture, swarming

                        à Constant monitoring, weeding, animal control

                        biodiversity is good.

Case studies:

The Love Bug – disease, everyone knew they were vulnerable

            Used social networks

            Law Enforcement result – no law = not a crime

            No economic incentive to perpetrate

            Epidemic model

                        Transmitted from people

                        Wash hands = don’t open attachments


            User had no knowledge that they were at risk – who knew they has a SQL DB?

            Could have been detected at network level – distinct UDP packet

                        Like a public health epidemic

            LE failed – 2 terrorists groups (falsely claimed responsibility)



            Attacked the immune system itself

            Worm-blast – tried to fix people à cowpox


            Economic incentives – helps spammers

            BUT: still a public health problem – can’t get known victims to stop

SoBig II

            Victims were unknowingly breaking law

            One arrest, but he was an idiot


            We see ‘virus’  think ‘malware’ see ‘computer crime’ think ‘malware

            Public sees ‘virus’ thinks ‘health issues’ sees ‘crime’ thinks ‘risk’

            Different models suggest different responses

                        Economics can communicate the wrong thing to end users

User response

            Download – inoculation

            Push – crime & surveillance (cops will take care of us)

            Metaphor of ‘digital signatures’

                        No revocation, no agency questions


Bill Yurcik – Visualization Tools for Security Administrators

NCSA – want to protect supercomputers

            Active security research program

Sys admins are users, too

Security is a huge n-dimensional space

            Problem isn’t lack of data, it’s using the data

What we can see

            Granularity for productivity, but visualization to make it useful, easy to understand

            (colors for trends)

            Key for inferences for action


            Forensic analysis

            Vulnerability analysis

            Trend analysis – profiling

            IDS/ anomaly detection

Intrusion detection

            Binary when you know what you’re looking for

            Efficient, but scalable?


            Visualization is very powerful, can absorb lots of data in movements, colors, etc

            “When you don’t know what you’re looking for”


            Colored, 3d histogram

            Colored 3d grid, with attack tracking from above


                        Ben Schneiderman = overview and have ability to zoom in

                        Can filter overview

                        Zoom into subnet, get port activity of specific machine

Visualization pitfalls

            Human perceptual limits

            Apophenia – see patterns when there aren’t any

            Cultural/organizational biases

            Data-centric vs problem-centric visualization: excel won’t always be best


Ka-Ping Yee – Principles of Secure Interaction Design

[See his handout, on the web at http://zesty.ca/sid]

What happens when you try to design user interfaces?

Security is about dependability

            Specifications change over time

            Can’t depend on experts all the time

Usability and security depend on each other

            Not usable w/ out security, secure w/out usability

Pop-up dialog as an example of bad usability (“ambient authority”)

            Better: use a designed window to integrate permissions

            How to manage authority if you don’t know what authority is?

Summary of principles (see handout)


                        Paypal: indicated that transfer happened, have money in account

                                    BUT: paymet was withdrawn

                                    Problem: user had expected ability that was false

                        Cyphermint: Can enter different acct # from who I’m actually trying to pay

                                    Also can be forced to accept multiple ‘Bob’s

                                    Problem: identifiability is problematic


Q: Public health & security – should we have counter-viruses from the gov’t?

            A: We have mandatory inoculations for kids, but even that’s hard to enforce/enact

                        That, and it’s a bad idea and wouldn’t work

                        Only a few cases of forcing people to accept treatment: we accept autonomy

Q: What about false analogies, taking too much from metaphors?

            A: people always take too much.

                        See “Mental models of risk”

Q: You’d think education would help, but researchers say that

            A: Not perfect, but idea is the responsibility of risk

Q: What is the status of IPnvision, and what can you find in the logs that you can’t see

            A: Can always find something in the logs if you look hard enough

                        Vis. is like grepping, but can see things faster

                        Metaphor: flying by instruments vs. flying by sight

Q: Usability & security complement each other sometimes, but may want certain user behaviors

            --such as anon: want lots of traffic, but also want them to act the same way

            A: Users act from motivations, and address the motivation

Q: Why are these usability problems still there—they seem so obvious?

            A: See security & usability as add-ons in the development process

C: Many people consider themselves experts

C: Problem: conflicting objectives

            Cyphermint: Want to be able to send $ anonymously if they like

IFCA Meeting

Agenda was circulated (Official minutes available from IFCA secretary)

President: Jean Camp

Four issues – if you have an opinion, email board

            Where to host DNS

            Where to incorporate

                        Taking money

                        Non-profit issues         

Secretary: Hilde ten Berge

            Proceedings mailed

            Minutes filed, all in accordance to w/ Aguilla law

            Contact her for membership information

            Thursday morning: will get survey & list of participants

Treasurer: Ray Hirschfield

            Just took office, but waiting for audit results

            Audit results: Made money in 99 & 00, started losing money in 01-03

                        Lost money b/c of fewer corporate registrants, fewer sponsors

            Stuart: cash balance?  A: $40K (gains + losses)

            Andrew: Attendance?  A: We bottomed out last year, attendance may climb again

Nomination & Election of Directors (Markus)

            Discussion on rules: nominate anyone in the room (no seconds)

                        Every nominated candidate gets 5 min

                        Vote on candidates

            Statements of those already nominated

                        Ray:     glad to see new faces, hope to build attendance

                                    Broaden field to appeal to finance, banking, policy aspects of crypto

                                                Not just math

                                                BUT: keep a cryptographer as chair, other good bits

                                    Respect wishes of membership

                                                Did not vote for bringing conference to US b/c members didn’t

                                    Tried to get new people involved, I can maintain continuity

                                    Include and support women in the field             

                        Jean:     Conference with good papers, low acceptance rates

                                    Security is not just a process

                                    Broaden focus, expand it & make it more well known

                                    Responsiveness, growth

                        Markus – will nominate self, give rump session talk, then withdraw

                                    We should think about WiSe04 – Wireless Security

                                                Should have greater crypto focus

                                                With MobiCom, September, East Coast

                                                CFP: June 30

                                    Withdraw nomination

                        Ari       Want to be more than 2 choices

                                    Support Jean & Ray

                                    Would like to expand into Financial Data Security, even change name

            Discussion on voting process – not resolved

                        (Hey, it’s Florida!)

            Markus offers slightly less-than ringing endorsement of Ari as too stressed

Long Term Planning (Jean)

            Please volunteer to help out with the planning of reincorporation

            Poll (non-binding)

                        No objections to leaving Anguilla

                        A few objections to reincorporate in the US

Ongoing Audits

            They are an expense, but they bring value

            Q: how much is the cost?

                        A: $1500/year to get source data (3%)

            C: get a part-time accountant

            C: as a non-profit, going to have to get audited anyway

            Poll: 18 for, 1 against, all other present abstain

Selection of 2005 venue

            Anguilla (Ray)

                        Got an attractive quote last year, trying to get more info

                        Lots of you would love to go back

                        Perhaps target it for 2006 for 10th anniversary

                        Direct flights from St. Maartens

            Dominica (Stuart) – NB: not Dominican Republic

                        (Stuart has a ridiculously well done powerpoint)

                        “It’s like Vermont in the Caribbean

                        Speak English, lovely, mountains,

                        Downsides: distant/expensive to get to, only 1 hotel

                                    Hour ride from hotel to airport

                                    Not as many lovely sandy beaches

                        Pluses: mountains, waterfalls, springs, scuba/snorkel, internet in room

                                    Not a huge tourist place – cultural experience

                                    Cheap rooms

                        Compare to Anguilla

                                    Mountains vs. beaches, cheap & local vs. resort, bigger, sparser island

            Panama (Lucky)

                        Some people in panama are setting up ecash for offshore gambling

                        Promoters were responsive, sound proposal

                        Panama City is a city, not an island culture,

Conference would be at suburban resort/beach

                        Can’t speak about sponsorships or businesses, but hosts probably sponsor

                        Panama reached out to businesses, hundreds of providers

            Vote (would you go to FC in X)

                        Anguilla: 27

                        Dominica: 31


            Pure preference based

                        Anguilla:  12

                        Domonica: 18

                        Panama: 3

Results of Election

            2 blank

            8 for Ari

            17 for Ray

            23 for Jean

Adjourned – Drink Beer

Rump Session

Ari Juels – FC06 program if everything goes well

            Breakfast in bed

            Keynote: too much VC

            Lunch with William Shatner

            Financial Conundrum: why does market grow faster than the economy

            A random beacon: a server that broadcasts verifiable unpredicactable numbers

            Historical business analysis of ecash


Edith Elkin – How hard is it to manipulate voting

            Model: n voters, m candidates, preference ordering

            Manipulatability: want to adjust prefs based on how outcome looks

            CMU: based on pre-round schemes

            Can we make voting as hard as undoing 1-way functions

                        Yes & no


Shin’ichiro Matsuo – Preventing forward-dating requests on time-stamping protocol

            Time-stamping protocols: simple signing or linking hash chain

            Attack: forward-dating request

                        Easy to solve in simple case

            BUT: collusion with time-stamp authority is stickier

                        Can solve, with no change to existing TSA, or


Roger DingledineTor, Next-generation onion-routing

            Mixnet is deployed, 19 nodes

            Perfect forward secrecy

            NO mixing, padding, traffic shaping

                        Does any of this work?

            Congestion control

                        Simple rate limiting, have to keep internal nodes from attacks

            Directory servers - How do I know who to choose?

                        Node needs to keep name and PK static

            Exit policies - each person should control outgoing traffic (no spam)

            E2E integrity – can an insider change messages en route

            Rendez-vous points at a given node, so neither knows origin

            Tor is TCP, multiplatform, not p2p, user-oriented


Nick Mathewson – Traffic Analysis is easy

            High latency mixnets: mixmaster, etc

            Some system that hides

            Senders send to the same recipients over time, send more than once

            Long term intersection attacks

                        If Alice is always sending, her recipients will receive marginally more messages

                        No existing mixnet has n-squared padding or constant sending

            Early results on a simple model

            My results are based on simulations: hard to protect against

            See this paper I submitted elsewhere

            Goal: how long, in presence of bckgnd traffic, should type of sender be confident?


Makato Yokoo – Auction protocols without 3rd party services

            Incentive-compatible protocols: vickrey auctions get true value

                        Spying is useless

            Model w/out 3rd party (p2p)

                        Each player must help find winner

                        Incentive to throw out other bids

                        Goal: make my calculations irrelevant to my own winnings & payment

            See rest of presentation on Wednesday


Rachel Greenstadt - Towards markets for personal information

            Privacy problem

            Potential Soln: property rights. 

                        How viable technically?

            Do you retain rights after sale?

                        Yes à need licenses, DRM

                        No à anonymize & aggregate,

            Lesson from Oregon (ORS 677.097) – individual had property of genetic info

                        Never challenged

                        Need a clear market structure


Rzulikar Ramzan – using quasimodo trees for cert revocation

            (See his talk from Monday)

            Cert revocation is annoying – have to

            Use a hash chain – too long

            Merkle trees have some issues 


Rzulikar Ramzan – Eliminating random oracles in the Even-Mansour Cipher

            Block cipher based on applying key before and after a random oracle function

            Problem: proof that random oracle permutation applies to lesser conditions

            Theorem: cipher is super pseudorandom

            Extensions: can reduce key material

            BUT: possible attack to recover key when known


Paul Syverson – Building NetMixes from MixNets

            Synchronous batching: mix cascades beat free routes through mixnet

                        Cascade is a fixed route network of mixes

                        Relevant feature is that they’re symchonous




Jon Peha - Bringing payment technology to the unbanked


Comes from the research community, but decided to try to sell: Cyphermint

Cyphermint: software for secure financial transactions

            Despite what we say, our mission has evolved

Traditional objectives: anonymity, transaction costs, secure acct-acct transfers

            BUT: all wrong directions

            Anonymity is fun, and a few people want it

                        BUT: consumers want more

                                    Track down fraud

                                    Support for lost/corrupted

                        Gov’t want to know about ‘suspicious’ behavior

                        In the US, anonymity is probably a bad idea

            Transaction costs being low are good

                        BUT: humans are more expensive than processors

                        Want ease of use, fraud detection, dispute resolution

            Computer-computer accounts are important

                        BUT: money needs to enter & exit

Plan evolved over time

            Need added value

            V1.0 was about anonymity & superior security

                        BUT: people don’t really pay for security

                        People liked no charge-backs

            V2.0 people who didn’t have computers, have access, banks

                        New market for ebusiness

                        Bricks & mortar store can sell things not in my store

            V3.0 serve people without credit cards, bank accounts

                        Other financial services we can bring them as well!

            New strategy: serving the unbanked with eshopping & financial services

                        Debit only

Helping the unbanked

The unbanked: 10-13% of US households have no bank acct, 35% have no CC

                        Outside US, these numbers are higher

            Rapid increase in internet access usage among poor households

            BUT – very little mobil commerce numbers      

Financial services can be expensive, hard to obtain

            Unbanked pay huge amount for fin services, can’t meet min balance

Q: How hard is it to open a savings account if you have cash?

            A: Bad credit = hard to get checking, fees are high

Interface – kiosks & online

            Can use kiosks to buy things, ask directions, and put money in for later

                        Some are ATMs, checks cashed, pay bills, transfer funds

            NB: this is an interesting problem, and we’re putting PCs with cash online

            Q: is there also a private network component?

                        A: Yes

            Q: Can some one build a creative fake machine?

                        A: Our system won’t recognize it, so merchants won’t buy it; consumers duped

            Q: How do you do check cashing?

                        A: Need prior registration, have a human-in-the-loop

            Q: How do your prices compare to corner Checks-cashed places?

                        A: it’s a high risk, so we charge a comparable premium

            Stored value card is integrated into internet system

                        Cards used at any V/MC term

            Synergy: internet payments, kiosks, stored value

            C: You know, the mike isn’t on.  You don’t have to stand there.

                        A: All those years of yelling at students pays off

Design objectives

            Privacy protection for end parties, but not to system

            Flexible anonymity policies, tamper-proof

            Range of payments, including micropayments

            Scalability, currencies,

Paycash, driven by chaum’s electronic coins

            Only payment system can create a coin, anyone can check

                        Centralized authorizer checks against double-spending

            BUT: electronic coins don’t have tamper-proof records, so disputes can happen

                        Reciever signs a contract, sendor constructs and signs record w/ contract

            Sender’s coin includes record, linked with keys

                        Can show that a coin has to have been used for that record alone

                        Can now have full check every transactions

            Q: Do you need a key pair for every coin?

                        A: a key pair for every paybook of n coins

Summary: serving the unbanked, tamper proof, privacy but not nec. anonymity

            Tech: integrate coins and transaction records

            Status: accepted in FSU, kiosk systems in 7-11

Q: ATMs aren’t always online w/ your bank, but still authorize on faith

            A: [from Simon] ATMs don’t do that, or else I’ll shut them down

Q: How do you deal with PATRIOT as it relates to acct registration

            A: We follow it even if we may not have to—register with info


Auctions & Lotteries


Koutarou Suzuki - Secure Generalized Vickrey Auction without 3rd party servers

Mechanism design – eliminate incentive to cheat

            Design rules such that violating rules doesn’t increase utility

                        Like Vickrey auctions – spies don’t gain

            Rational adversery does not become active adversary

                        No costs to make protocol verifiable, still safe if crypto is broken

Auction scheme – distributed Vickrey

            Payment of a bidder is computed by all bidders except that bidder

                        What you calculate is irrelevant to what you get

            Combinatorial auction for multiple goods

            Vickrey auctions: 2nd price means that optimal strategy is to bid true value

            Gen Vickrey Auct: payment computed from second price and combinatorial sum

GVA mechanism

            Bidders compute others prices and publish it

                        Determining the price of any one bidder

            Each bidder finds their allocation

Side payments cannot be enforced: no collusion unless strictly positive gain

Q: Can you have active attacks collusion against a single player?

            A: we assume no externalities

Q: Can you use multiple identifiers to attack the system?

            A: Currently under research


Moti Yung w/ Elisavet Konstatnou et al - Electronic National Lotteries: Design & implementation

Trying to get a secure, robust system for a national lottery, increase business

            Many lotteries/day, expensive to design & test machines for randomness

            Pseudorandom bits can be used as much as you like

Design must be secure

            Users can’t cheat, including insiders

            Auditability for public confidence

            System operation must be secure

            Strict drawing times, many users, many draws

            Users cannot in any way affect the number drawn


            6000 agencies w/ phone lines into lottery computer

            Coupons in a coupon file

            2 generators with verifiable audit mechanisms

                        Secure, no leaking

Physical and network security, device security, display security

Operation requirements

            Real uniform draw, with unpredictable results, or interference

            Auditing: state & time stamping

                        Detection of all access, signed


            Traditional pseudorandom: uniform distribution, but predictable w/ limited # of states

            Crypto-secure PNG – in principle can be guessed given initial state: det algs

            Truly random number generators: depend on physical processes, hard to audit

            Soln: combo of truly random and crypto-secure PNG

                        Internal verification that repeat process after production based on early commit.

                        NB: don’t have public verification

Need to prevent post-betting of picking the number after having seen winning number

            Use hash value of all coupons in the number selection

            Now can test by trying to regenerate winning number if we have a corrupted coupon file

Hash of coupons + truly random physical value à Naor-Reingold PNGà crypto à seed

            Verifier takes values from each step, tries to duplicate

2 families of PNG, 4 generators overall: algebraic (BBS & RSA)  & block cipher (DES & AES)

3 physical truly random devices, one clock phase & two HW


            Apply constant online statistical tests of all generators

Cryptography is needed where randomness is of value

            Basic tools useful, incorporate real world security too.


Helger Lipmaa w/ Edith Elkind - Interleaving Cryptography and mechanism design: Online Auctions

Vickrey auctions are great theoretically, but vulnerable to cheating auctioneer, require thought

            Crypto takes into account security, but not cognitive thoughts

Individuals have preferences, should get something out of market participation

            Design the mechanism to make honesty optimal

            Participants don’t care about privacy, or want to harm others

            Many participants with secret input that stays secret

Design criteria

            Pareto-efficiency or revenue max

            Resource effectiveness

            Security against malicious auctioneer


            Minimal cognitive cost

                        Tradeoff with round-effectiveness: more time = better computation

                        Tradeoff with privacy: if I know others valuation, I can better compute own

New mechanism: multiple rounds

            Only highest m bids of every round is revealed

            Rounds continue until 2nd highest price doesn’t change

            Much lighter cognitive load

Trying to combine two different research approaches: crypto & game theory

            Get neat features that simple layering doesn’t give you

Q: what kind of strategy should a malicious actor take?  Can you guarantee pareto?

            A: Yes. 

Q: How big an m do you set?

            A: as few as possible.  Going from 2 to 3 doesn’t help privacy, need data about psych


<MISSING – Notes from Guiseppe Ateniese & Breno de Medeiros>



Panel: Game Theoretic & Cryptographic Tools


Vanessa Teague - How two selfish players can select correlated random actions

How to use crypto to solve a game theory Coordination problem:

Moderate benefits from cooperating, benefit from taking action, everyone lose if all act

Nash equil: one acts, the other doesn’t (2 equil)

But: Nash is not socially optimal—both have incentive to deviate from inaction

Game theory: correlated equilibrium

            Trusted third party announces a probability dist

            Tells each player what to play, but keep it secret

            Equilibrium to always obey

Interesting question: what if you don’t trust the trusted party?

            Already solved by Dodis, Halevi & Rabin, Crypto ‘00

            Players run secure fn protocol to select actions

                        each player learns its action

            Players play game, and coop is they don’t suspect the others

                        Minimize harms if they suspect à less total payoff

Blindable encryption

            A chooses blinding factor for message X, sends cipher + blind to B

            B decrypts X, but can’t learn X because of blinding fn, sends X back to A

Goal: choose a pair of actions from a list, PKs

            A & B should be able to confidently choose their action

A blinds B’s action with 0

            B gets own action, but not the correlated A action

Non-uniform distribution don’t work with D, H & R

            They just say iterate until you have a uniform distribution

            Suppose both players know non-uniform dist

            B divides distribution into uniform blocks that contain either 1 or 2 actions

            A chooses a random block, which comes with a probability

                        Blind decrypt from B

            Get their own action

            Efficient: bound by inverse of smallest prob. To assemble the blocks

Can solve correlated equilibrium w/ crypto, w/ non-uniform dist

Q: What about iterated game?

            A: Model designed for a one-shot game


Pino Persiano - Efficient and Usable Multishow Non-transferable Anonymous Credential System

Motivation: discounts based on personal attributes

            Standard solution: bob sends certificates to service provider

            BUT: bob’s privacy

Goal: Bob should get credential that does not disclose

            Multishow property: a coalition of service providers can’t correlate credentials to bob

Soln 1: Brand’s PKI

            Can still have linkability, since while proof is different, cert is the same

            Soln: Bob gets a bunch of certificates, uses a different one for each

                        Need lots of cert, for each service and each transaction

Soln 2: Camenish or Verheul

            Bob converts the given cert into new, unique cert

            BUT: others need more info to trust bob’s transformation

            Soln: credential for each permission set

                        Too many credentials, for each service

Goal: one cert with unlinkability

RSArep problem, DLrep problem used

            Given a Boolean formule, user knows given rep iff

System setup, each org publishes keys

            Enrollment: user sends credential to org, sends back computer pair C, S

                        S is signature of G

            User can compute S’ and G’ à multishow property

            Bob can prove that S’ is valid

Usability – user can prove general statements over the credentials


Non-tranferability: we can discourage bob from sharing his credential

Include private info he does not wish to share

Same computation time, but only need one cert from the authority

Q: can you revoke certificates?

            A: Organization needs to publish list of credential revoked, user proves not on list

                        Same problem of revoked sigs

C: Usability is part for security to make sure you’ve got enough credentials to hide in


Jaap-Henk Hoepman - The Ephemeral Pairing Problem

How to pay wirelessly at the right counter

Problem: can end communicating with wrong cash register in crowded environment

            Goal: short term pairing, but not authentication of identity

            N physical nodes w/ human operators, broadcast network

            Alice & Bob don’t share info a priori, channel can be authentic or private

                        Want to establish a shared secret over broadcast channel, but can’t send a lot

            Can send many bits on broadcast, few bits on point to point

Similar to encrypted key exchange (EKE)

            Samll password shared, want to exchange larger session key

            Alice generates key pair, encrypted with password, sends to bob

            Bob generates session key, encrypts it with Alice’s public key

                        Attacker only has one chance to use a dictionary attack, useless

            Vulnerable to active attacks, but not offline passive attacks

Ephemeral key exchange problem depends on channel

            Authentic, private channel à alice sends bob password, use EKE

                        Private channel protects password, authentic protects against direct attack

            Private, nonauthentic password

                        Alice & Bob send each other a password, XOR it together

                        Now we have a shared password à EKE

            Open, unauthenticated channel requires 4 phases: want a key exchange

                        Commit: broadcast hash of random numbers

                        Authenticate: Gets a short authentic hash over point to point

                        Key exchange: Can correlate two hashes to procede

                                    Exchange keys over broadcast

                        Key validation

Performance: passive attacker

            Probability of active attacker is bound by guessing hash from the two exchanges (low)

Implementation Need the low bandwidth private channel

            Brief physical contact, aiming a mobile, data entry

Future work: unidirectional channel, anonymous broadcast networks, weaker assumptions

Q: Unidirectional channel just for side channel?

            A: Yes.

C: Combining low bandwidth w/ broadcast is like a phone w/ RFID. 

Q: Existing key exchange protocols aren’t sufficient?

            A: EKE is good for a few cases, but interesting bit is the non-private channel



About these notes

These notes were recorded on the fly by Allan Friedman, and any omissions or inaccuracies are purely his fault.  To learn more about the papers here, please see the proceedings (to be published by Spring-Verlag) the IFCA website, or contact the authors directly. 


I apologize for the horrendous formatting; I took notes on a windows box and was lazy about dumping into HTML, so plenty of nasty artifacts remain.