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. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com https://www.metzdowd.com/mailman/listinfo/cryptography