1997-10-31 - Re: Protocols for Insurance to Maintain Privacy

Header Data

From: Mix <mixmaster@remail.obscura.com>
To: cypherpunks@cyberpass.net
Message Hash: 407cef0111d48a347faaab2a92afb489b52d8fb09cd471be4cd60d0c55ac6d02
Message ID: <199710310111.RAA01731@sirius.infonex.com>
Reply To: N/A
UTC Datetime: 1997-10-31 01:26:21 UTC
Raw Date: Fri, 31 Oct 1997 09:26:21 +0800

Raw message

From: Mix <mixmaster@remail.obscura.com>
Date: Fri, 31 Oct 1997 09:26:21 +0800
To: cypherpunks@cyberpass.net
Subject: Re: Protocols for Insurance to Maintain Privacy
Message-ID: <199710310111.RAA01731@sirius.infonex.com>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

I wrote:
>I have my doubts as to whether it is possible to set up a really good
>anonymous insurance scheme.  At some point the customer must
>physically be matched up with the policy.  The damage may be
>minimized by putting a hash of the customer's DNA markers in the
>policy instead of the markers themselves.  But, when the customer
>wishes to draw on the policy, his or her markers will have to be
>taken.
> 
>If there were a way for the representative of the insurance company
>to absolutely verify the DNA markers such that the customer could be
>absolutely certain the information didn't leave the room, a really
>good anonymous policy would be feasible.  But, I can't think of a way
>to do this.

I've thought about this some more and there is a way to do this that
at least works in theory.

Let's say there are 30 DNA markers to be used to uniquely identify a
physical person.  When creating the contract, the customer creates 30
hashes based on each marker.  Prior to the time the customer has a
health problem, privacy is well assured assuming he or she doesn't
have a blood sample taken forcibly.

When the customer goes in for treatment, the insurer selects at random
one of the 30 markers and verifies it.  If it checks out, treatment is
provided.  The way to prevent people from trying to get lucky on the
markers is for the customer and the insurer to make a bet before the
test.  This is a safe bet for the customer - he or she knows the
outcome.  If the odds and payoff are set correctly, it's a good deal
for the insurer, too, because he or she will make money on fraud
attempts.

Let's take the worst case: only one of the 30 marker is different.
Let's say the insurance contract consists of a health bet with a
payoff of $100,000 if the ailment insured for is found.  If the
customer is willing to bet $3 million that any marker selected will be
correct, the insurer breaks even.  However, since the customer knows
with certainty the outcome of the bet, he or she is safe betting
(theoretically) any amount.  This can be set arbitrarily high so that
the insurer actually stands to make a substantial amount of money off
fraud attempts.

In practice some provision will have to be made for people who can't
arrange the $3 million, such as taking fraud artists out to the
parking lot and shooting them.

And there still needs to be a way for one DNA marker to be tested for
in a way which guarantees that none of the others are studied.
Perhaps when the customer goes in, he or she takes samples of DNA with
all thirty markers.  When the insurer selects a particular marker, a
blood sample is drawn, and the customer puts in DNA with the 29 other
markers so that it will not be possible to study any marker other than
the one intended.

If each insurance contract is linked to only one type of illness, then
the only information revealed is that somebody with one particular DNA
marker had such and such an illness.  This seems pretty secure.

Monty Cantsin
Editor in Chief
Smile Magazine
http://www.neoism.org/squares/smile_index.html
http://www.neoism.org/squares/cantsin_10.htm

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEVAwUBNFjP6JaWtjSmRH/5AQGwjgf/SIMSKV3prkmD3WDaiwojOhgxA+V0iLeY
UAwHUKoOgIQAZ+5SKz2SsP6219jyi4i1mGbQFwXc8kydeEuia81/gAReo+63wZgB
S6hlh9bUc4lp//S/ql5YISypNEKWXE6o7hE3IvdAeUrRlxEyU04fLmwW2UcejeFB
rTdqFQLsTbONf1bvevJ4MplnhG/O7fRUDF3jneRxDZuib60EO8zUvbvpvDhaYM/e
TMeuK5OywHOCX6EQc5eZ7ER1pIWgxR1cXwm428Qvk07z8VoTDJyy6QMLs+EzPcp6
Es94M2JezFmDAfD6nDGdLzrs8h4IJITdjWujLL4VQeJi6LwP7RB5NQ==
=eHkn
-----END PGP SIGNATURE-----







Thread