[Cryptography] In the event of my death, master password

[Phillip Hallam-Baker]

On Wed, Feb 27, 2019 at 7:47 PM Paul F Fraser <paulf at a2zliving.com> wrote:

> Hi,
>
> Trying to work out for my project, how best to handle a master password
> for relatives and others to access data after death, including data about
> ongoing subscriptions etc..
>
> Some thoughts
>
>    1. Password in sealed envelope which would be obvious if accessed.
>    2. Pin number in sealed envelope which could decrypt the password.
>    3. Split password and have friends or relatives have parts.
>    4. Shamir secret sharing with friends or relatives.
>    5. etc..
>
> More to the point, is how would you (with a technical background) like to
> access yout parents password for example?
>
> How best would a non technical person, possibly very old, access the
> passsword with minimum friction
>
So as it happens, I pushed out this draft last week. The code is not quite
ready yet but it will be very soon. I just have to get the version that
produced the draft to pass all the unit tests:

http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html

UDF is simply a modern way to present and use PGP fingerprint-ish types of
data.

So a 128 bit key looks like this:
Key: EA6Q-YPKA-WZH4-64VU-ADGN-4UGM-TSXQ

The data format has a one byte type identifier followed by n bytes of data.
In this case it is a 132 bit key. intended to be used as input to a KDF so
the encryption can still be 256 bit.

We can share the keys using Shamir secret sharing, for example, this is 3
shares with a quorum of 2:

Share 0: SAQB-7EV5-OUJG-ZWXJ-BRRC-HMOB-TEZT-Q
Share 1: SAQQ-EGJ5-VFXI-TZS7-MTBX-VBJS-MXE4-C
Share 2: SARO-JH55-3XFK-N4OV-XUSN-CWFD-GJQH-2

OK, so far nothing you haven't seen before but this is actually documented
and written up so its a bit more than a suggestion.

Now for the new part. We can create a UDF URI. So lets say our secret was:
ED3O-CIJB-M57X-LCGZ-RAIX-K4KK-2WIU-XE

We create a UDF URI with a domain name where we are going to store the
document:
udf://example.com/ED3O-CIJB-M57X-LCGZ-RAIX-K4KK-2WIU-XE

We can turn that into a QR code.

To resolve the URI, the app first takes the Content Digest fingerprint of
the secret. We use twice the precision of the input.

MAQJ-VVJB-TKX5-BNL6-7WPI-UEU4-QJVZ-GV2C-XUOJ-5QHC-YGBS-BKE7-76U3-RHNU

Now we do Web Service Discovery to find the Web Service Endpoint and splice
the fingerprint on the end.:

https://example.com/.well-known/mmm-udf/MAQJ-VVJB-TKX5-BNL6-7WPI-UEU4-QJVZ-GV2C-XUOJ-5QHC-YGBS-BKE7-76U3-RHNU


So now we have a mechanism for going from a QR Code to locate an encrypted
copy of your document in the cloud and decrypting it without putting the
encryption key at risk.


I am pretty sure that we could use this mechanism to make payment of
invoices easier. Existing electronic means based on email are insecure and
account based schemes only solve the problem for the biller, not the
customer.

It could probably be used to achieve HIPPA compliance. The key thing is
that the documents in the cloud are encrypted but the keys are never in the
cloud.

This is one of my bootstraps for the Mathematical Mesh. Instead of
insisting on going all electronic cold, provide people with the on-ramp.
The process of resolving the linked document could be used to trigger a
binding of credentials that allow us to make use of Mesh Secure
Transactions (different name for secure email not based on SMTP, not trying
to replace regular email, just eliminate the clutter that makes securing
email so hard).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20190228/6597b788/attachment.html>