[Cryptography] The Mesh

[Phillip Hallam-Baker]

On Fri, Jul 10, 2015 at 2:45 PM, Ralf Senderek <crypto at senderek.ie> wrote:

> On Fri, 10 Jul 2015 01:32:55 Phillip Hallam-Baker wrote:
>
>  The mesh does not do any cryptography at all, it is just a dropbox
>> for exchanging small quantities of crypto info. So in the above example,
>> the admin machine pulls the S/MIME and OpenPGP decryption keys
>> that the device is going to need to read emails and encrypts them under
>> the device key and uploads the profile to the mesh.
>>
>
> I understand that the mesh is something like a cloud storage for encrypted
> keys the user needs on different devices. It just makes the keys available
> wherever they might get used. But, doesn't that mean the secret keys must
> be stored in the devices in plain text? Or, if you use passwords to
> protect them, you'd run in all kinds of key management problems, (forgotten
> passphrases etc.)
>

There are different levels of secret keys. The master keys are only ever
constructed once unless there is a complete catastrophic meltdown requiring
recovery. The admin keys would normally be password protected and kept on a
few machines.

Remembering ONE [Singular] password as a second factor without any idiotic
pa$$w0rd rules is pretty easy actually. Especially if you can have two
words in the password. But since it is only ever used to unlock a private
key that is on the user's device, brute force attacks aren't possible until
after the user has been breached.



The administration device at least must store the personal PKI's root
> signing key to be able to chain-in all other certificates a user might
> need. If you'd use a password for protection here, that'll be entirely
> necessary. So, if someone else's email cert has been accepted and
> chained, signed and uploaded to the mesh, it is available on all the
> devices, but how do you make sure, that the right cert is being
> accepted by the personal PKI?


Actually, I have combined an idea by Brian LaMacchia and Phil Z.

The certificates for use in the mesh have a particular profile

1) The Subject key identifier is a UDF fingerprint (i.e. truncated
SHA-2-512 digest) of the KeyInfo Block

2) So is the Authority Key Identifier.

3) Policy constraints and other PKIX idiocy are utterly ignored as they are
utter crap.

4) Not using PKIX mechanisms for revocation. That is something that only
really makes sense in a public PKI.

5) Each will eventually have a timestamp embedded that has the current
integrity value of the mesh when it was created. This provides a method of
defeating backdating attacks.

6) I add my own extension OID allowing me to specify the mesh purpose of
the cert.

Reading through the docs on various chain building engines, I realized that
getting them to do what I want would be very hard. Implementing what I want
with some profile constraints, much easier.

A private PKI consists of of more than a dozen or so Certificate Signing
Certs. When I read them into my cert collection, I can construct all the
cert chains etc. with little difficulty. I verify that each cert is valid
according to the profile requirements etc, and check that it chains to the
root of the personal PKI.


I suspect you'll run into all the
> well-known difficulties that makes key management an unfriendly
> task for the ordinary user.


You would not know you were using it. In use, the entire system is
completely frictionless. The only time a user ever needs to be aware of
using encrypted mail is when they want to force use of encryption or force
use of encryption with a key they have a verified fingerprint of.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150710/a5ce913f/attachment.html>