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
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
