lightweight encryption of text file

[Steven D'Aprano]

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':
> 
> [fetchinson at 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