Path: csiph.com!usenet.pasdenom.info!news.redatomik.org!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Dennis Lee Bieber <wlfraed@ix.netcom.com>
Subject: Re: Pure Python Data Mangling or Encrypting
Date: Wed, 24 Jun 2015 08:19:03 -0400
Organization: IISS Elusive Unicorn
References: <mmcagn$aa5$1@ger.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.14.1435148356.3674.python-list@python.org>
Lines: 37
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:93076

On Tue, 23 Jun 2015 14:02:45 -0500, Randall Smith <randall@tnr.cc>
declaimed the following:

>Chunks of data (about 2MB) are to be stored on machines using a 
>peer-to-peer protocol.  The recipient of these chunks can't assume that 
>the payload is benign.  While the data senders are supposed to encrypt 
>data, that's not guaranteed, and I'd like to protect the recipient 
>against exposure to nefarious data by mangling or encrypting the data 
>before it is written to disk.
>
	Pardon, but that description has me confused. Perhaps I just don't
understand the full use-case.

	Who exactly is supposed to be protected from what? You state "data
senders are supposed to encrypt" which, if the recipient doesn't have the
decryption key, implies the recipient -- isn't the real recipient but just
a transport/storage place until the data is retrieved by the end-user.

	If "you" do the encryption on the storage machine, then you need to
also do the decryption when returning the data to the end-user -- which
means the key is available somewhere on the storage machine, and the local
user might obtain access to it and the stored data.

	Given the assumptions I'm making, my recommendation is likely to be
something on the nature of: use an OS designed with security at the core of
the file system; each sender has their own login UID, and the file system
is configured to grant r/w access only to the login -- no execute
permissions, no access by someone not logged in as that user, etc.

	Or maybe bypass file system and use a client/server database (no
SQLite3) for the storage media, with the database privileges configured so
only your receive/return application can see the data -- and even that
could have configured logins per user.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/