Subject: [VIPR] Privacy concerns

From: Michael Procter <[email-masked]>
Date: Fri, 21 Oct 2011 18:57:55 +0100

I've just submitted a draft[0] which summarises most of the privacy
concerns that have been raised in recent times, along with the
suggested mitigations from the list.  This is clearly not exhaustive,
but I was losing track of which concerns we had addressed and which
ones were still on the table.  I thought a draft would be a good place
to keep track of these issues for the time being.

Comments, suggestions, text happily accepted.

Regards,

Michael

[0] https://datatracker.ietf.org/doc/draft-procter-vipr-privacy-concerns/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 22 Oct 2011 10:52:21 -0700

Hi Michael,

> [0] https://datatracker.ietf.org/doc/draft-procter-vipr-privacy-concerns/

in Section 1.1.1:

Note that I refined and tested this proposal since I wrote the email that is the
source for this section.  My new proposal[1] is to use bcrypt for the Caller-ID
alone, so rehashing on the PVP server side is limited to the calls made to the
terminating phone number in the last 48 hours.  The salt and the number of
rounds is part of the hash string, so the only configuration parameter would be
to have the minimal number of rounds under which a PVP server refuses a hash.

The main problem is that the phone numbers that are the most interesting to
attack are also the one that generates the most calls per 48 hours interval
(e.g. 1-800 numbers).  This means that the number of rounds must be balanced
between the desire to made the hash practically unbreakable, and the time to
rehash the phone numbers for the last 48 hours.  Again we are in a situation
where a VIPR domain registering a phone number may want that PVP clients use
different algorithms depending on the phone number.  So instead of having only
the minimal number of rounds in the configuration file, we can have both the
minimal number of rounds and the default number of rounds in the configuration,
and let the VIPR domain change the default value for each registered number
(down to the minimal value) inside the RELOAD registration.

I used a 4 cores computer to crack a phone number hashed with 2^4 rounds, and it
took 106 minutes (410 minutes of CPU) to crack it, *knowing* the area code.
There is ~300 area codes in the USA, so if all area codes were tried in
parallel, it would take 22 days.  And it is for one phone call, and with only
2^4 rounds.   With 2^10 rounds, it would take 6 years to crack this phone number
with the same hardware.

The bcrypt paper claims that "its inner loop relies exclusively on operations
that are efficient on general-purpose CPUs, leaving little opportunity for
specialized hardware to achieve dramatic improvements", so using GPU would not
help much.  But if we start with the smaller cost that one's would not pay for a
phone number, then evaluate the CPU power this cost would buy on Amazon EC2[2],
and then calculate the number of rounds that would use this CPU power, then we
could assign a default minimal number of rounds in the global VIPR configuration
file, and increase it as the cost of Amazon EC2 decreases.

[1] http://www.ietf.org/mail-archive/web/vipr/current/msg00088.html
[2]
http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org