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 21:51:00 -0400
Organization: IISS Elusive Unicorn
References: <mmcagn$aa5$1@ger.gmane.org> <q67loadve6lsrh672u47omr04tvqttt6jd@4ax.com> <558AF89E.1070105@tnr.cc>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.41.1435197071.3674.python-list@python.org>
Lines: 48
NNTP-Posting-Host: 2001:888:2000:d::a6
Path: csiph.com!usenet.pasdenom.info!news.stben.net!border1.nntp.ams1.giganews.com!nntp.giganews.com!newsfeed.xs4all.nl!newsfeed7.news.xs4all.nl!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Xref: csiph.com comp.lang.python:93114

On Wed, 24 Jun 2015 13:36:14 -0500, Randall Smith <randall@tnr.cc>
declaimed the following:

>
>Right again.  A legitimate data owner would encrypt the data.  The 
>storage machine is encrypting to protect itself against unwanted 
>exposure to unencrypted malware.  Not that they would go looking at the 
>files, but their virus scanner or file indexer might.
>
	Why? Is this server machine openly accessible -- providing a command
line to anyone? And then making your stored data chunks available to any
user to invoke as programs?

	The worst a virus scanner should do it delete or quarantine a file
because it reads signatures that the file IS malicious. A file indexer may
build up a list of strings from the file, but unless someone can access the
index itself its just a waste of time (better handled by turning off the
indexer).

>Yes.  This is done for "imaged" systems, but I don't have control over 
>the storage machines.
>
	Then I think you have a flawed security policy. Your storage servers
should be the tightest controlled machines on the net.

>I'm leaning towards using a random substitution cipher suggested by 
>Devin Jeanpierre.  If you see any weaknesses in that solution, I'd like 
>to hear them.
>

	And I'm still leaning toward using a decent client/server RDBM (even if
the "client" is running on the server machine to accept transfer requests).
With the proper time spent designing the database, you might be able to
implement stored programs to do encryption as a record is inserted, and
decryption as it is retrieved. The key would be locked to the stored
programs which are only executable from the client submitting SQL
statements, but which can not be read by anyone other than the DBA user.

	This also prevents any inadvertent execution of user data as it doesn't
appear in the file system itself, it is saved as BLOBs in the database. End
user identification and "file name" would be the retrieval keys (not
encryption keys) and required for all SQL (again, stored programs to
enforce such).

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/