Re: [Mathmesh] Configure SSH with UDF key...

Michael Richardson <> Sun, 29 September 2019 22:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87BB2120073 for <>; Sun, 29 Sep 2019 15:37:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AUegw2lHaWb4 for <>; Sun, 29 Sep 2019 15:37:41 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2904120025 for <>; Sun, 29 Sep 2019 15:37:40 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 556F03897D; Sun, 29 Sep 2019 18:35:40 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id BC410373; Sun, 29 Sep 2019 18:37:38 -0400 (EDT)
From: Michael Richardson <>
To: Phillip Hallam-Baker <>
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Sun, 29 Sep 2019 18:37:38 -0400
Message-ID: <30079.1569796658@localhost>
Archived-At: <>
Subject: Re: [Mathmesh] Configure SSH with UDF key...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 29 Sep 2019 22:37:42 -0000

Phillip Hallam-Baker <>; wrote:
    > The biggest hassle with SSH is how to install your private key on each of
    > the devices that you want to use it from. In theory of course, you want to
    > have an independent key for each device so that you are not completely
    > hosed if you lose one of them or you are passing through an airport and
    > someone demands you login to your laptop.

    > But most people have one private key and they move it from one machine to
    > another in email. Oh and 'most people' probably isn't most of the people
    > here. It only takes one pinhead to bust a hole in your corporate defenses.

So you have a fairly reasonable use case.

I also observe the 90% of people don't use ssh private keys or understand how
to use ssh-agent, or understand that they can keep their private key in some
central place and use ssh -A/ssh-keyadd to gain access to it for the current
session.  This turns SSH into a far more KRB5-like ticket system with limited
lifetimes, and so the private key on the laptop only lets one get to the
"home cloud"(owncloud) machine that holds the master key.

But MMM should let us do other things with SSH keys.  Since 1996, I've wanted
to do signed statements about logins, rather than hacking
~/.ssh/authorized_keys files.

    > So I have been looking at recovery mechanisms for Mesh profiles. And one
    > very promising approach is to use a KDF and a strong password to generate
    > them.

    > KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_signature")
    > KDF ("ZAA2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ-GIYA", "mmm_master_escrow")

    > So the encryption and signature keys are generated from Z

    > All we need to do now is to escrow ZAR2-UJUY-H7TF-SFLK-CWAW-TKC4-O5HQ which
    > we can do by Shamir Secret sharing.

    > What if we could also do

    > KDF ("ZAA5-7VB6-IJXJ-WKHX-NZQF-OKGZ-EWVN-AQQE", "ssh_client")

    > Now we have a really quick way to reconstitute the authentication key on
    > each of the user's devices.

If I understand you correctly, you are trying to find a way to generate the
private key(s) in a deterministic way from a master secret which can be

This way, the user doesn't use email to distribute their private key, but
rather can just recover it each time they might need it after a dangerous
situation. (Such as going through a border control, etc.)

    > What I was thinking of for implementation is to define a new type code,
    > probably 200 which gives an initial letter of Z. Then make the following
    > two bytes a 16 bit registry code saying what the key is to be used for
    > (Mesh, SSH, etc.)

Seems like a useful thing.

    > As with passwords, we might well need to help people follow their current
    > workflow in a not quite so stupid fashion before we try to change it.

An illustrative video would help.

Michael Richardson <>;, Sandelman Software Works
 -= IPv6 IoT consulting =-