[SIMSOFT] Protecting Privacy with Translucent Databases

[R. A. Hettinga]

--- begin forwarded text


Status: RO
Date: Sat, 3 Aug 2002 20:36:04 -0400
To: "R. A. Hettinga" <rah at shipwright.com>,
 Digital Bearer Settlement List <dbs at philodox.com>,
 daw at mozart.cs.berkeley.edu
From: Peter Wayner <pcw at flyzone.com>
Subject: Re: [SIMSOFT] Protecting Privacy with Translucent
 Databases

>
>
>
>I'm glad commentators are beginning to point out that
>more care should be put into protected personal information.
>However, solution proposed in this article seems to me to
>be more complicated than necessary.
>
>I can't find any legitimate reason why colleges should need your
>SSN when deciding whether to admit you.  They get away with it because
>they can, but that doesn't mean they are right to do so.
>
>It seems to me that a much more privacy-friendly solution would be
>to simply refrain from asking for sensitive personal information like
>SSN and date of birth -- name and a random unique identifier printed
>on the application form ought to suffice.  (If SSN is later needed
>for financial aid purposes, it could be requested after the student
>decides to matriculate.)
>
>Am I missing anything?


Yes, a random nonce would be fine in many cases. The hash of the SSN,
the birthday, or combination, however, is much easier for a person to
remember. The random nonce requires a person to keep a copy. That may
be good practice, but it's not always practical. Hard disks crash.
Buildings burn down. Etc.

Hashing can also be quite flexible. In this case, PU might store
SHA("Yale sux"+ssn) while YU might store SHA("Princeton sux"+ssn) in
their databases. ('+' means concatenation.) The results would be
quite different and the databases couldn't be cross linked. But if
someone knows their ssn, they can call up the records quickly.

There are many limitations to this approach as there are limitations
in all cryptography, but I think it has a few advantages that are
well worth the few extra cycles for the hash function.  If this
computation is done on the client machine, the results are quite
secure even without SSL protecting the link. This is actually fairly
easy to implement with a Java applet.

--- end forwarded text


-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com