[Endymail] Concealing the email address of the subscriber.

Phillip Hallam-Baker <phill@hallambaker.com> Fri, 29 August 2014 15:22 UTC

MIME-Version: 1.0
Sender: hallam@gmail.com
Date: Fri, 29 Aug 2014 11:22:01 -0400
Message-ID: <CAMm+LwiC7cp3uS3HtXQzCaVyg_E44-7xRT+u2h_LL=VEc60s+A@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: endymail <endymail@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/endymail/5K_WniqSvjmLiVAtbOBrwzEVvJc
Subject: [Endymail] Concealing the email address of the subscriber.
Precedence: list

Problem: Allow an email sender who knows an email address to locate a
record giving key information without disclosing address to an
attacker.

To simplify the argument we are only considering this part of the
puzzle here and hypothesizing that there is a separate infrastructure
whose sole purpose is matching email addresses to records.

Obviously if we are using CT with this then any information that goes
into this infrastructure has to be validated in CT but that can be via
a hash of the data which is non-disclosing.


Approach 1:

Let email address be aç
Locator is H( "alice@example.com" )
Service maps Locator to record.

Strength: Simple
Weakness: Attacker can derive the email address by brute force.


Approach 2:

We have two locators each of which contain only part of the email address.

Locator1 is H( "lice@example.com" )
Locator2 is H( "alic@example.com" )

Each locator is presented to a service which returns a set of opaque
locators V1, V2. There is a possibility of collisions here.

Final locator is the XOR of V1, V2...

Nah, combinatorics would be horrendous.


Approach 3:

Anyone got something better that does not allow the brute force attack
- other than simply increasing the linear work factor for the
attacker?

[Endymail] Concealing the email address of the su… Phillip Hallam-Baker
Re: [Endymail] Concealing the email address of th… Natanael