On Fri, 08 Jan 2010 20:14:51 +0100, Daniel Fetchinson wrote:
> I have a plain text file which I would like to protect in a very simple
> minded, yet for my purposes sufficient, way. I'd like to encrypt/convert
> it into a binary file in such a way that possession of a password allows
> anyone to convert it back into the original text file while not
> possessing the password one would only see the following with the
> standard linux utility 'file':
>
> [fetchin...@fetch ~]$ file encrypted.data
> encrypted.data: data
If that is your sole requirement, then the addition of a single non-text
byte (say, a null) anywhere in the file would be sufficient to have file
identify it as data. You say "encrypt/convert" -- does this mean that you
don't care if people can read the text in a hex editor, so long as file
identifies it as data?
Would something like a binary Vigenere Cipher be sufficient?
# Untested
def encrypt(plaintext, password):
cipher = []
for i, c in enumerate(plaintext):
shift = password[i % len(password)]
shift = ord(shift)
cipher.append((ord(c) + shift) % 256)
return ''.join([chr(n) for n in cipher])
def decrypt(ciphertext, password):
plain = []
for i, c in enumerate(ciphertext):
shift = password[i % len(password)]
shift = ord(shift)
plain.append((256 + ord(c) - shift) % 256)
return ''.join([chr(n) for n in plain])
(How times have changed... once upon a time, the Vigenere Cipher was
considered the gold-standard unbreakable encryption technology. Now it
merely qualifies as obfuscation.)
Is it acceptable if there is a chance (small, possibly vanishingly small)
that file will identify it as text? As far as I know, even the
heavyweight "serious" encryption algorithms don't *guarantee* that the
cipher text will include non-text bytes.
> and the effort required to convert the file back to the original text
> file without the password would be equivalent to guessing the password.
If you seriously mean that, then "lightweight encryption" won't do the
job, because it is vulnerable to frequency analysis, which is easier than
guessing the password. You need proper, heavy-weight encryption.
> I'm fully aware of the security implications of this loose
> specification, but for my purposes this would be a good solution.
Can you explain what your objection to real encryption is? Are you
concerned about the complex API? The memory requirements and processing
power required? (Neither of which are particularly high for small text
files on a modern PC, but perhaps you have to encrypt tens of millions of
huge files on an underpowered device...)
> What would be the simplest way to achieve this using preferably stock
> python without 3rd party modules? If a not too complex 3rd party module
> made it really simple that would be acceptable too.
The problem is that, as I see it, you've assumed a solution rather than
state what your requirements are. I'm *guessing* that you are more
concerned of having to learn to use a complex API, rather than actually
*requiring* a lightweight encryption algorithm. If that's the case, then
something serious like blowfish or similar would be perfectly acceptable
to you, so long as the API was simple.
(On the other hand, perhaps vulnerability to frequency analysis is a
feature, not a bug, in your use-case. If you forget the password, you
have a chance of recovering the text.)
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
