On 06/24/2015 07:19 AM, Dennis Lee Bieber wrote:
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.
You got it. I didn't want to explain any more than necessary. But yes,
the recipient just stores the data for 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.
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.
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.
Yes. This is done for "imaged" systems, but I don't have control over
the storage machines.
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.
Thanks for your response.
--Randall
--
https://mail.python.org/mailman/listinfo/python-list
