[1818] in linux-security and linux-alert archive
[linux-security] Re: "Flavors of Security Through Obscurity"
daemon@ATHENA.MIT.EDU (Raphael Ho)
Fri Jun 5 18:21:09 1998
Date: Fri, 05 Jun 1998 18:09:03 +0800
From: Raphael Ho <Raphael.Ho@globalone.net>
Reply-To: Raphael.Ho@globalone.net
To: linux-security@redhat.com
Resent-From: linux-security@redhat.com
I am not a security/encryption expert - I just happened to have
taken a 1 year course in encryption theorems in University.
Just my 2 cents.
Brandon K. Matthews wrote:
> Actually it is a very good idea to keep
> secret the algorithm (in all its representations), as long as you
> can afford to do so. That is why major governments do exactly
> that.
>
Gibberish.
This way, nobody can check for flaws in the algorithm - actually,
this could theoretically allow the implementing person/organization
to add "back doors" to decrypt your message. The only reason
why DES and PGP is so popular is because the source is open,
and anybody can check for flaws themselves.
I am sure some *unnamed* government would love to let you use
their secret encryption program.
> As you see, the reasons are of a practical nature, and are not
> derived from any fundamentals in cryptology. If we could find a
> practical way to keep secret both the key (that is the data the
> encryption method operates on) and also the method itself (or at
> least part of the method), then security would be greatly
> enhanced because the attacker would have less knowledge to work
> with.
>
If the implementer kept part of the encryption method secret,then the implementer
holds an amazing amount of power over
any organization that uses that algorithm.
c.f. my above comment, and that film featuring Sandra Bullocks.
> a) Machine generated secret ciphers.
>
> Today there are only a few encryption algorithms that are
> generally accepted as good. But suppose there existed a generator
> program which could construct a new encryption algorithm
> depending on some random input.
How can you generate an algorithm based on an input? Even if
it does, this random input is therefore (by definition) a 'key'. Crack the
original key, along with the program that generates the algorithm,
et voila! You have cracked the message. This "random input" must
also be transmitted to your destination in order for them to generate
the decryption box. And how are you going to do that? via DES?
> b) Intrinsically secret ciphers.
>
> Extend secrecy to parts of the encryption method. In his book,
> Schneier very briefly describes a variant of DES where the Sboxes
> (which most people would consider as part of the algorithm) are
> variable and depend on the key. Another very interesting
> possibility would have the key express the encryption method. In
> other words consider the key as the program, and the cipher
> simply as an interpreter, that follows the key's instructions to
> scramble the plaintext or unscramble the ciphertext. This would
> call for large keys, but not larger than keys used in public key
> encryption.
>
c.f. above comment.Secret algorithms are untrustworthy by definition, and if the
"secret
algorithm" is only distibuted to a small group of trusted people, then
it might be acceptable. If this "secret algorithm" is distributed to any
body else, they just need to find your key to decrypt your message.
> c) "Variable" ciphers.
> Here is the definition of another cipher of this type (let us
> call it "heavy DES"): Start by randomly defining 16K DES keys;
> you need less the 1 MB space in your hard disk to save them.
> Suppose that this large key set is public (either by choice or
> because an attacker gained access to your computer and stole it).
> So now you have a large set of DES ciphers with *known* keys; the
> effort to break any one of them is 1. Now define a secret key of
> 140 bits. Use 14 bits at a time to index one of the 16K DES
If you encrypt something twice with different keys,you can decrypt it with both
keys - but mathematically, there is another
key of a similar length that can decrypt that message equally well.
(since encryption is basically a factorization excercise, there are more
than one way to skin a cat.) I don't have mathematical proof of this,
so I will stand corrected if somebody could proof otherwise.
If my assumptions are correct, you are only as secure as the
plain vanilla "lightweight" DES. Encrypting a message 140 times with
56bit keys would not make it more secure.
(Does someone know Phil Zimmerman here? Maybe he could end
this once and for all.)
Just my $0.02
Regards,
Raf.
--
----------------------------------------------------------------------
Please refer to the information about this list as well as general
information about Linux security at http://www.aoy.com/Linux/Security.
----------------------------------------------------------------------
To unsubscribe:
mail -s unsubscribe linux-security-request@redhat.com < /dev/null
