Re: [perpass] (Possibly Dumb) EMail Security Idea

David Singer <singer@apple.com> Wed, 04 September 2013 23:26 UTC

Return-Path: <singer@apple.com>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3FB11E8208 for <perpass@ietfa.amsl.com>; Wed, 4 Sep 2013 16:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGdwK-CoUIPq for <perpass@ietfa.amsl.com>; Wed, 4 Sep 2013 16:26:33 -0700 (PDT)
Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id F406A11E8144 for <perpass@ietf.org>; Wed, 4 Sep 2013 16:26:32 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; CHARSET="US-ASCII"
Received: from relay8.apple.com ([17.128.113.102]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MSM00EDBJS3MIW0@mail-out.apple.com> for perpass@ietf.org; Wed, 04 Sep 2013 16:26:31 -0700 (PDT)
X-AuditID: 11807166-b7fd66d000006a64-b2-5227c1a7d76c
Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id A8.66.27236.7A1C7225; Wed, 04 Sep 2013 16:26:31 -0700 (PDT)
Received: from singda.apple.com (singda.apple.com [17.197.32.11]) by spicerack.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MSM007WPJS6NF20@spicerack.apple.com> for perpass@ietf.org; Wed, 04 Sep 2013 16:26:31 -0700 (PDT)
From: David Singer <singer@apple.com>
In-reply-to: <52278CC3.5090002@funwithsoftware.org>
Date: Wed, 04 Sep 2013 16:26:38 -0700
Message-id: <A704B12A-8564-4634-8E35-6453DBF45465@apple.com>
References: <00c201cea94a$ed5d45b0$c817d110$@riw.us> <9B462ED5-963C-4618-8FA2-1FA041EB0C72@tik.ee.ethz.ch> <52278CC3.5090002@funwithsoftware.org>
To: perpass@ietf.org
X-Mailer: Apple Mail (2.1508)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FCsobv8oHqQwcGf8hZ3L3WwODB6LFny kymAMYrLJiU1J7MstUjfLoEr4+oZp4LlPBW3Wx8yNjC2cnUxcnJICJhITN2+jA3CFpO4cG89 kM3FISQwmUli1rRTzBDOGiaJu2smsINUMQtoSazfeZwJxOYV0JPYPOMFWFxYwEri9e5LLCA2 m4CqxIM5xxhBbE4BY4nG5deZQWwWoPieCc9ZIOZoSzx5d4EVYo6NxLsXJ5kglk1llLi09xBY QkRARGLRqmdANgfQebISO38nTWDkn4XkjFlIzpiFZOwCRuZVjAJFqTmJlRZ6iQUFOal6yfm5 mxjBAVaYtoOxabnVIUYBDkYlHt4GY/UgIdbEsuLK3EOMEhzMSiK8FiuBQrwpiZVVqUX58UWl OanFhxilOViUxHkPpAGlBNITS1KzU1MLUotgskwcnFINjA3PndctZbayvSekw+zMKJGUYH/J 8biYPcu6g5zcAZYbjD+7z934qP+RQv1Pdp3TD7cqmO5iF3D52PXdZba98j7zcOMfUlun8N0p Dfxifo6taWlI+urZ0kIsdVn8b1UESme/Ol+ZMl2HZVsiW0XT5wSFzf56bHy1wSlpvfdf6Oc2 XtP8e4RFiaU4I9FQi7moOBEAzD93iSwCAAA=
Subject: Re: [perpass] (Possibly Dumb) EMail Security Idea
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Sep 2013 23:26:39 -0000

I fear this solution may suffer easily from the 'apparently separate channels problem'.

I recall some incident where people had bought triple-redundant links from different long-haul providers -- who all used the same underlying fiber.  One backhoe did them all in.  Similarly, if the client can easily identify which pieces go together, so can a snooper.


On Sep 4, 2013, at 12:40 , Patrick Pelletier <code@funwithsoftware.org> wrote:

> On 9/4/13 2:14 AM, Brian Trammell wrote:
> 
>> I presume each chunk is (1) encrypted and (2) non-contiguous? Otherwise you have the problem that the information density and interesting-information-density in most email messages is unevenly distributed, and then you only really need some subset of the content to get the interesting information out.
> 
> This reminds me a little bit of what Tahoe-LAFS is doing, since they encrypt, then do erasure coding, and send the pieces out to different servers.  The only difference is that you're doing it with email instead of files.
> 
> On the other hand, if you don't want to encrypt, then you could solve the information density problem by using an AONT:
> 
> https://en.wikipedia.org/wiki/All-or-nothing_transform
> 
> Then each piece would mean nothing unless you had all the pieces.
> 
> --Patrick
> 
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass

David Singer
Multimedia and Software Standards, Apple Inc.