On Sun, Apr 01, 2007 at 02:05:58PM -0400, Dave Ahn wrote:
> On Sun, Apr 01, 2007 at 03:31:41AM -0400, mark at mark.mielke.cc wrote:
> > A secret key is a secret key. However encoded it is, or however black
> > boxed it is. RES-RSA is obscure. It is not secure. Sometimes obscurity is
> > enough. In this case, my point was, that it must be enough. It isn't possible
> > to secure the system unless you control all points at all times.
> RES-RSA neither obscures nor secures.  It obfuscates using a published
> transformation algorithm.  Your original response implies that PKC is
> the "real problem" with the Netrek binary verification system, but I
> contend that that is not true.  The "real problem" is the multiple
> vectors of attack in circumventing RES-RSA, not breaking the functional
> transform or reverse engineering the key.  If you are claiming that the
> functional transform used in RES-RSA is cryptographically weak and is
> easily reversible, I'd like to read your analysis because I have a
> passing interest in cryptography.

Sorry - I wasn't clear. I'll take another stab at it:

Public key architecture cannot solve the problem, because the secret
key is freely and widely distributed to the public. The secret key may
be concealed beneath a state machine, a physical black box card,
random number of link order. From a design perspective, the secret key
*is* included, and since the ability to use the secret key is a
necessary part of the function, the ability to reproduce it is
therefore also included.

Public key architecture, in this case, is only better than reserved.c
in that few people understand the technology. RES-RSA may be more
obscure than a straight RSA implementation. Public key architecture is
not providing a significant benefit over any other encryption or
encoding scheme. You could have a 'functional' 3DES implementation and
it would accomplish the same value. Heck - why not include a random
algorithm in the software instead? Random if(), for(;;), and various
arithmetic operators in a sequence. It would have the same
benefit/effect. :-)

The underlying point here, is that it is *not possible* to 100%
guarantee that the client is legitimate unless you can control the
software and hardware on the client.

Sorry if this point isn't of concern to you, or if I confused the
issue in any way. :-)

Cheers,
mark

-- 
mark at mielke.cc / markm at ncf.ca / markm at nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/