tags:

views:

170

answers:

4

Warning: This question has been heavily edited. I tried my best to guess the original author's intentions. Please view the original version.


I'm unsure on how to use the GPG command line tool, that we're using to encrypt files.

File.txt is a simple text file:

Testing
hello world  
My security things.

This is how I encrypt the file:

gpg --symmetric File.txt 

This gives me a new, encrypted file: File.txt.gpg

If someone else now modifies the encrypted file, I'm no longer able to decrypt it.

$ gpg --decrypt File.txt.gpg 
gpg: no valid OpenPGP data found.
gpg: decrypt_message failed: eof

How can I get the content of my file, even though someone has modified it?

A: 

You should produce and distribute a digest of the encrypted file together with the encrypted file itself.

Before decrypting the file, compute the digest and check if is equal to the provided one. If the digests doesn't match then the encrypted file has been corrupted and is invalid.

You can't encrypt a file, then modify it and pretend to be still valid encrypted.

fabrizioM
Actually, you can't **GPG** -encrypt a file, modify it, and pretend it's still encrypted. This is algorithm dependent. For instance, it's trival to see that you could do so with ROT-13 "encryption". Finding strong crypto algorithms that also allow partial editing is a hot research topic.
MSalters
A: 

There is no way you'll be able to do this with just the encrypted file.

I believe what you're looking for is data redundancy. CDs for example have it. You can make a scratch on one and the whole data is still readable, despite the fact that much data got lost with the scratch.

The simplest way of doing it is to just store the file twice, using a checksum you can determine if one of them has been modified. More advanced techniques use interleaved checksums and parity bits/bytes. An overview over error detection and correction techniques can be found on wikipedia.

I do not recommend you implement it yourself. It's much simpler and more secure to just use a already existing implementation. (I'm sure there are some out there, but I don't know them.)

Georg
+3  A: 

The typical symmetric encryption modality operates on blocks of data, and the results of each block are used to encrypt the next block.

A block is typically 128 to 256 bits long. If any bit within a block is corrupted, then the entire block cannot be decrypted. If this were not the case, then it would be possible to get some information about the contents of the block even without the key. An important part of any good encryption algorithm is that a change of a single bit in either the plaintext or the cyphertext can cause changes to any number of bits in the corresponding cyphertext or plaintext.

Another important feature of the encryption mechanism is that identical blocks in the plaintext are not encrypted to identical blocks in the cyphertext. If they were, then it would be possible to gain information about the contents of the plaintext. For example, bitmapped image file might be legible when encrypted if each block were encrypted the exact same way, because of the patterns that emerge. For this reason, the results of encrypting one block are sometimes used to encrypt the next block. There are also common modalities in which only the key affects the encryption of subsequent blocks, not the plaintext.

If the results of encrypting one block affect how the following blocks are encrypted, then corruption to a single bit in a single block will cause the rest of the cyphertext that follows that block to be unrecoverable.

Jeffrey L Whitledge
+1  A: 

Answering the original question in layman's terms;

Unless you know exactly what changes someone made to your encrypted file, your content is gone, and you probably cannot get it back.

That's why encrypted files are used to secure your data; they're really, really hard to work backwards.

Dean J