Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh?

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 08 April 2019 19:24 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: endymail@ietfa.amsl.com
Delivered-To: endymail@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542F312032B for <endymail@ietfa.amsl.com>; Mon, 8 Apr 2019 12:24:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.646
X-Spam-Level:
X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRIh9UW0Eff6 for <endymail@ietfa.amsl.com>; Mon, 8 Apr 2019 12:24:23 -0700 (PDT)
Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E61E120424 for <endymail@ietf.org>; Mon, 8 Apr 2019 12:24:23 -0700 (PDT)
Received: by mail-ot1-f42.google.com with SMTP id t8so13276436otp.7 for <endymail@ietf.org>; Mon, 08 Apr 2019 12:24:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tiBO40rMTJ/yccdBbBu/D+byaeVzh/w2c0PZohjMfnc=; b=o87khw2U7cpgW3QQBAGUm62RnEjVXDcP01je9WalgvqsdKhKRYwmsRkfajoRJhgB3A 7dIG3rJ50yonjF8Fk1tZrNPIttBI8QKRm1UPasVEmB0QZs+/YkQFGyer1/cuBRwkXM32 IJj/8Sr15+c9eSv5yvwq8oOcN+RpgCOkkYyI36bn4QuDljwfLvDa2sxd1bjMGpcckuHH pi7aIPAX9uODRLrCOPqjxK0FNteku5AWK7dyb7y7FsDY8m4loCqX9Vh0JjTFNMrsGhM5 +O13AN20QG9anOEI0nPfaFOR1c3RDH64hIznlKRnnfTOIxEYH3N8Qekjmo3oLaPACaoI 2m0g==
X-Gm-Message-State: APjAAAWzIte5r56sclAZP3Ev8jdDpaqoyxbhydezSDe3m8A8z41xW/1v O6gwyLt7LRlTG0qBWHC9ibKpo7QGRq2n8Wfb4Qs=
X-Google-Smtp-Source: APXvYqxVYDT9LuSjy2MujyrP1J9TxMK4NrXuPObc5MeSEOG5+A/36C74/+mw6SGQBw5sXz4ewf4XJt15Vx7p4t3iX4c=
X-Received: by 2002:a9d:550d:: with SMTP id l13mr20370736oth.173.1554751462286; Mon, 08 Apr 2019 12:24:22 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+LwhjPF8QqJ41HQ4__2_KnZZXfmJ_55X2HtrhyTz=i=8j=A@mail.gmail.com> <2E619909-61A1-4DB6-B073-DA55958F38EE@cs.columbia.edu>
In-Reply-To: <2E619909-61A1-4DB6-B073-DA55958F38EE@cs.columbia.edu>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 08 Apr 2019 15:24:11 -0400
Message-ID: <CAMm+LwiN3FXJYH4QBYLrZkHLyu6aD-tAzZ2v=crmAZVER38cJA@mail.gmail.com>
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
Cc: endymail <endymail@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009faabf058609c843"
Archived-At: <https://mailarchive.ietf.org/arch/msg/endymail/zfXDVYtIYe8SQqEK6r-c49wH2H8>
Subject: Re: [Endymail] Restart Endymail to discuss the Mathematical Mesh?
X-BeenThere: endymail@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <endymail.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/endymail>, <mailto:endymail-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/endymail/>
List-Post: <mailto:endymail@ietf.org>
List-Help: <mailto:endymail-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/endymail>, <mailto:endymail-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 19:24:24 -0000

On Mon, Apr 8, 2019 at 2:32 PM Steven M. Bellovin <smb@cs.columbia.edu>
wrote:

> Slightly off-topic, but folks on this list may be interested in
>
> https://www.cs.columbia.edu/~smb/papers/eurosys-2019-submission408-e3-final-1.pdf
> .
> We plan to release the code as open source.
>

Looks interesting. I can see some clear convergence in mechanism. Though it
is not clear to me how you are dealing with the per device keys.

My approach is to split the decryption key. Which means I can add and
remove devices etc. in no time at all. When I provision a new device, the
administration device knows the private key for each of the applications I
might provision to it. To add S/MIME capabilities, it splits the private
key in two, sends one to the service and encrypts the other under the
public key of the device. So the service only has a random number and the
device can't decrypt without the device helping.

The crypto is a scheme Matt Blaze and Torben Pederssen discovered.
Depending on how you look at it, you can consider this to be Proxy
Re-encryption or Distributed Key Generation. It is actually a simple case
that sits at the intersection of both.