On 06/24/2015 11:27 PM, Devin Jeanpierre wrote:
On Wed, Jun 24, 2015 at 9:07 PM, Steven D'Aprano <st...@pearwood.info> wrote:
But just sticking to the three above, the first one is partially mitigated
by allowing virus scanners to scan the data, but that implies that the
owner of the storage machine can spy on the files. So you have a conflict
here.
If it's encrypted malware, and you can't decrypt it, there's no threat.
Honestly, the *only* real defence against the spying issue is to encrypt the
files. Not obfuscate them with a lousy random substitution cipher. The
storage machine can keep the files as long as they like, just by making a
copy, and spend hours bruteforcing them. They *will* crack the substitution
cipher. In pure Python, that may take a few days or weeks; in C, hours or
days. If they have the resources to throw at it, minutes. Substitution
ciphers have not been effective encryption since, oh, the 1950s, unless you
use a one-time pad. Which you won't be.
The original post said that the sender will usually send files they
encrypted, unless they are malicious. So if the sender wants them to
be encrypted, they already are.
"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."
The cipher is just to keep the sender from being able to control what
is on disk.
I am usually very oppositional when it comes to rolling your own
crypto, but am I alone here in thinking the OP very clearly laid out
their case?
-- Devin
Thanks Devin. You understand the issue perfectly despite my limited
description of the system. I've fully implemented and performance
tested your suggested solution and am quite happy with it.
Though the issue is solved, I would be glad to listen to any remaining
criticisms, suggestions or questions.
--Randall
--
https://mail.python.org/mailman/listinfo/python-list
