HP3000-L Archives

June 1998, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dirickson Steve <[log in to unmask]>
Reply To:
Dirickson Steve <[log in to unmask]>
Date:
Fri, 12 Jun 1998 18:00:41 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (44 lines)
        <<Ok, but are you willing to decrease the S/N ratio of your
communications link by an order of magnitude (or whatever) in order to do
this?  Will the customer be willing to pay for 10x the network bandwidth
between the client and 3000?>>

1)      Why would it need to be 10:1?
2)      Even if it is, would that really be that significant? There don't
seem to be all that many applications where the performance limit is the
bandwidth between the server and the client. If the application is such that
megabytes of data must be shipped over the wire, it might be worthwhile
re-thinking the architecture rather than worrying about bandwidth. Certainly
there are bound to be exceptions, but they are also certain to represent a
small minority. Especially if the security, and thus the S/N ratio, is
variable as required by the sensitivity of the data being transferred.

        <<You still need to have some shared secret to initialize your
pseudo-random number generator with so that both ends agree on where the
signal is amongst all the noise.  Without something like this the signal
will be in the same place every time you start a new connection, and it
becomes relatively easy to figure out with a known plaintext attack.
Especially at the start of a connection when the least information is
available for generating randomness but the most sensitive information
(logon passwords) are being exchanged.>>


But that "least and most sensitive" thing is purely a convention: responding
to an "MPE_XL:" prompt with a "HELLO" command and then a password is great
for direct-connected 1200BPS terminals, but how much data could the client
and server exchange between the time you see the prompts and the time you
press <CR> after entering the user name or password? They could exchange
hundreds/thousands of bytes of data to build up the encryption setup.

In fact, you could have a system where there was a (more or less) continuous
exchange of packets between the server and the client at startup of the
link; somewhere in that stream, with the exact location dependent on the
encrypted data itself, the encrypted password would be passed. Some time
after the password was passed and validated, the continuous exchange would
be terminated. With arbitrary/random message sizes and boundaries used for
this "noise exchange", it would be pretty tough to decide what to attack.

Steve

        G.

ATOM RSS1 RSS2