[Cryptography] Fwd: [Secdispatch] Call for Agenda items

Phillip Hallam-Baker phill at hallambaker.com
Fri Jul 5 00:20:06 EDT 2019


I have just released a new set of docs for the Mesh. It is nearing
completion. The last thing to do is to put the output of the examples into
the documents and I am using that as an opportunity to make a last editing
pass getting everything I can as correct as I can.

I will be at Montreal IETF if people are going.


Right now, the only person funding this work is me (though I am grateful
for the considerable amount of previous support from Comodo). I am
currently looking at options to take the work further. The one
non-negotiable criteria being that this is at root a communications system,
it can only reach its full potential if it is unencumbered, that means
anyone can use it or extend it without fees, licenses or permission.


The objective of the Mesh is to make computers easier to use by providing a
security infrastructure that works without users needing to be aware that
they are using it.

The Mesh can be used as a mechanism for managing credentials (passwords,
private keys, etc.) for existing security applications (SSH, OpenPGP,
S/MIME) or it can be used as a platform for developing new applications
(end-to-end secure password catalog, secure contact exchange).

One of my frustrations with the current situation in the industry is that
we haven't moved on from cryptography developed in the 1980s. We have
better algorithms to use in place of DES, MD5 and RSA but we haven't added
a new capability since BitCoin added hash chains to the canon ten years ago
and the patent on that was 1990.

The Mesh introduces a new set of cryptographic techniques:

*Uniform Data Fingerprints*: Think of this as 'Cryptography on rails'.
Rails is a powerful framework because it uses the same name for the same
field in every situation. UDF does the same for cryptographic keys.

*QR Codes*: Imagine being able to scan a QR code on your bills, your pay
stubs, tax advice, etc and get to a machine readable copy of the document
you are reading. That is what EARLs provide.

*Multi-Party Key Generation*: Weak keys have been a problem for decades and
now we have to consider the possibility that a key was compromised by the
device manufacturer. But keys generated during manufacture that cannot be
extracted could be the very best keys to use (if we can trust them).
Combining keys generated on multiple devices allows this concern to be
mitigated.

*Multi-Party Decryption*: Traditional CRM schemes use the Ford-Wiener key
release with a key server in the cloud dispensing decryption keys to
authorized readers. The problem with this approach is that our chief data
confidentiality concern is a breach of the cloud, i.e. the key server.
Separating the decryption function into two parts and requiring both to
participate enables a key server to control decryption of data without
being able to decrypt.

*DARE Envelope*: This is a new PKCS#7 type format built on JOSE which
provides the hooks needed to support the Multi-Party Decryption scheme DARE
Container.

*DARE Container*: An append only log format supporting incremental
encryption and authentication. If I am talking to VC, I might even call it
a block chain.

*Shamir Secret Sharing*: Personal Escrow of the user's keys is supported
with up to 16 shares and a quorum of 1-15.

There is quite a bit more to the system but it remains remarkably compact
and especially so considering the scope of its capabilities.

One innovation that addresses a current concern is that Mesh Accounts are
the property of a user and not the service provider. So if I want to change
my service provider from example.com to example.net, I can do that at any
time of my choosing and I don't need example.com to co-operate of give
permission for the transfer.

The trust model does have a role for Certificate Authorities but this is
optional and limited to the discovery process, CAs are not ongoing
participants in every transaction. Direct exchange is also supported via
both an in-person model (e.g. QR code exchange or bump phones) or remotely.


All the reference code is MIT License and copyright Comodo Group (to
Version 2.0) and Comodo Group and myself (3.0 on). The tool chain used to
build the system is MIT License and my copyright. I have attempted to avoid
encumbered technology and I am not aware of any valid claims on the current
specs but make no warranties in that regard.


I have submitted all the documents as Internet drafts but there is a catch,
I am writing the documents assuming that the transition to HTML RFCs is
going to happen. So you can read them as plaintext drafts if you insist.
But the HTML documents have diagrams and use superscripts and subscripts
for the math rather than X_A which makes them a lot easier to read.

The architecture draft provides an overview of the project:

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

The following drafts are nearing completion. I am currently working on
getting the worked examples from the running code worked in:

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


I might have the protocol specification available by Montreal but that
might slip.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20190705/a50f055d/attachment.html>


More information about the cryptography mailing list