<<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.