Corrupting files

[Atom Smasher]

On Mon, 12 Jun 2006, Tom Thekathyil wrote:

> A wishes to send message to B.
>
> A encrypts message using B's key. Opens encrypted message and corrupts 
> the file by altering one or more characters/adding redundant lines of 
> code, e.g. changes case of first occurrence of 'T' in the code. Saves 
> file and sends to B.
>
> B will get an error message when trying to decrypt message. However B 
> knows that the first occurrence of 'T' needs case conversion and edits 
> file. The edited file is now capable of being decrypted.
>
> Since no one apart from A & B knows how the encrypted file has been 
> corrupted, this seems to be a method of increasing security.
>
> Question: Is there in theory any way of breaking the corrupted 
> encryption through brute force?
=========================

why not pipe the encrypted output of gpg through a captain midnight secret 
decoder ring? because it doesn't add any real security.

i can't give an authoritative answer on the security of this, but i can 
say this... bear in mind that a pgp encrypted message consists of one or 
more packets containing "header" information, such as the encrypted 
session key, symmetric algorithm, compression algorithm etc. there will be 
one of these packets for each recipient the message is encrypted to.

following the header packets, are the [symmetrically] encrypted data 
packet(s) which, AFAIK, don't have any inherent structure.

the data in the header packets is fairly well structured... using a text 
editor, it would be easy to make a change towards the beginning of the 
armored message that would be very easy to discover and correct. that 
would result in no real added security.

assuming that the decrypted data (plain-text) is structured in some way, a 
change to the armored message would corrupt all data after the change is 
made (the session key would have to be recovered to get this far). if an 
attacker has recovered the session key, and the decrypted data starts off 
having a certain structure and then turns to garbage, an attacker should 
be able to figure out what part of the armored message is corrupt, and fix 
it with trail and error.

so, if this were to add any security at all, the first step would have to 
be editing part of the armored file that corresponds to the beginning of 
the encrypted data packets.

again, i can't say that this *would* add any security... but clearly there 
are several ways to do it that would *not* add any real security.

btw, what's the threat model where this is advantageous?


-- 
         ...atom

  ________________________
  http://atom.smasher.org/
  762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
  -------------------------------------------------

 	"HEY! HO! LET'S GO!"
 		-- The Ramones