[1823] in linux-security and linux-alert archive
[linux-security] Re: "Flavors of Security Through Obscurity"
daemon@ATHENA.MIT.EDU (Richard Watts)
Sat Jun 6 15:58:14 1998
From: Richard Watts <Richard.Watts@cl.cam.ac.uk>
To: linux-security@redhat.com
In-Reply-To: <3577C3BF.A89E2407@Globalone.net>
Date: Sat, 6 Jun 1998 13:31:46 +0100
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
On Fri 5 June 1998, Raphael Ho
<Raphael.Ho@globalone.net> wrote:
[ might it be a good idea to move this off-list ? ]
>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
But that's OK in the intelligence sector, since the players are
you (the NSA, for the sake of argument) and other SIGINT agencies:
the other agencies are unlikely to tell you if they find a flaw,
so your best bet is to keep the code secret, and make their jobs
slightly harder.
Secret algorithms do place a real barrier in the way of the attacker.
The argument against them is that, unless you are the NSA (and even
then):
(i) This barrier is usually trivial for the determined attacker.
(ii) Keeping your algorithm secret means that you miss out on
peer reviewing which could stop you deploying an algorithm with
a serious flaw.
The (entirely separate) argument against using a crypto algorithm
designed by someone else, whose security you can't verify, is that
you're trusting your security to the designer of the algorithm, who
typically cares much less about your secrets than you do.
[snip]
>> 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?
I believe that his point is that control-flow-modifying crypto
algorithms have a much larger keyspace than non-self-modifying
algorithms (and are harder to analyse). Unfortunately, that keyspace
is also horribly sparse, and by his own argument, there exists no
(fast) general algorithm for determining whether you have a good
key or not.
The point about keys is not so much that they're small, as that
the space is dense - _any_ DES key should be as good as any
other: the amount of effort required to discover if my particular
key is good or not should be small. There may well be (indeed,
there must be) control-flow-modifying crypto algorithms with this
property, but it'd be very hard to show that they were secure.
This (incidentally) is one potential way to `break' RSA: don't
find a way to factor any large composite, just find an algorithm
which can factor large composites of factors which fail a test
as difficult as trial division - that opens up a lot more attacks,
because it effectively cripples probabilistic primality testing and
makes key generation a thoroughly horrible thing to do (cf.
secure ZKPs involving Hamiltonian circuits).
[snip]
>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.
Erm, this is what it means to say that DES is not a group: in any
group G with operation o, f o g = h (f,g,h here would be DES keys, and
o is encryption).
If it were true that f o g = h, 3DES would be rather a silly thing to
do (which is how the question came up in the first place). Schneier
gives Campbell & Wiener in Proc. Crypto '92 as a reference for this
(though he defines this property in terms of closure and purity).
Obviously there is a program which is the inverse of 2DES (or any
other isomorphism you care to mention), but there is no practicable
general way of finding such programs.
[snip]
Richard.
--
----------------------------------------------------------------------
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
