Corrupting files

Ingo Klöcker kloecker at kde.org
Tue Jun 13 10:59:57 CEST 2006


Am Dienstag, 13. Juni 2006 09:02 schrieb Samuel ]slund:
> On Mon, Jun 12, 2006 at 11:55:54PM +0200, Ingo Klöcker wrote:
> > No, it doesn't. You are still believing in security-by-obscurity
> > meaning that your additional "encryption" only works as long as you
> > and the recipient are the only ones who know the secret rule.
>
> Please Ingo, _all_ encryption is based on "security-by-obscurity" if
> an attacker finds the secret key _any_ encryption system is toast.

You know very well that "security by obscurity" refers to keeping the 
encryption algorithm secret.

> > Anyway, why do you actually think that what you want to do would
> > make any sense? If the encryption algorithm you use is too weak so
> > that additional "encryption" methods are necessary then you
> > probably shouldn't use this encryption algorithm in the first
> > place. And if the encryption algorithm you use is strong enough
> > (e.g. AES) then you gain nothing by additional "encyrption" methods
> > unless those additional "encryption" methods are an even stronger
> > encryption algorithm than the first one (but then why apply the
> > first one).
>
> I can think of some possible scenarios; if an attacker is has
> automated the attacks, especially with attacks tailored for each
> known algorithm, then making the message not conform to known
> algorithms and structure should break the automation.

I don't see why such a scenario would make any sense. If the automated 
attack would have any chance of success then the used encryption 
algorithm was too weak. Otherwise it doesn't matter whether the 
automation works for the message or not.

> Another could 
> be, how would an attacker tell the difference between a random
> intercepted file that has been corrupted in transit and one with an
> additional human decryption step, e.g. during the window between key
> compromise and revocation. In this case we are dealing with humans
> that does not necessarily have huge amounts of resources and
> patience.

Maybe you have a point. Still using a self-created obfuscation scheme 
doesn't feel like a really good solution for this threat model.

> I'd be impressed by any people communicating that actually had the
> patience to keep up this kind of scheme, since any communication
> needs manual intervention.

Sure. But as others have said earlier there are better ways to use a 
secure channel than to agree on such a stupid additional obfuscation 
step. If anything, then use a second symmetric encryption step for this 
special two-way-only communication.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20060613/476501d5/attachment.pgp


More information about the Gnupg-users mailing list