Re: Windows->Linux. Graphical terminal emulator.

From: P.T. Breuer (ptb_at_oboe.it.uc3m.es)
Date: 01/08/04 

Date: Wed, 07 Jan 2004 23:40:20 GMT

In alt.os.linux san <san@sanbase.com> wrote:
> P.T. Breuer wrote:
> > In alt.os.linux san <san@sanbase.com> wrote:
> >
> >>code), on the client side (Windows) and on the server side (Linux).
> >
> >
> >>The steps:
> >>1. client generete and send to server a random number (i) using RSA
> >>public key.
> >
> > Vulnerable to man in the middle attack first time. The client doesn't
> > have the servers public key until it contacts the server, so a proxy
> > can simulate the server to the client, providing its own key instead of
> > the servers key.
> >
> > The rest is obvious.

> It seems so you do not understand it clearly. A client has only a public
> key or it receive this key from server side for each new session.

So it's vulnerable to a man in the middle attack.

> If someone (hacker) will simulate server, he will received some sequence
> of bytes. In our case it will be 64 bytes. It is a number (4 bytes)
> encrypted with public key.

No it isn't. The client does not have the servers public key until it
contacts the server for the first time, which is when it is vulnerable
to being given a false public key by a man in the middle.

> Hacker has not a private key so he can not
> decrypt it.

The man in the middle does have the private key, because he made the
private and public keypair, the public half of whch he gave to the
client, saying that it was "the servers" pulic key.

> Private key can only encrypt information but not decrypt it.

Thanks - but I know the theory! I wrote the RSA implementation used by
the internet banks in south western europe.

> Server should to send this number (I mean 4 bytes) back to client using
> its value as a pointer to the RNG. Hacker can do it but the values will
> be different and client will close the session. That's all.

False - the man in the middle will supply his public key to the client
and decrypt the rsults himself.

If you are suggesting that there is a unique public key associated with
all your servers, so that the clients can always contact exactly the
servers an no imposters, tough - we get a copy of the server code and
extract its keybair by reverse engineering.

If you are suggesting something else again, you had better come clean!

And please tell me you *know* about the Public Key Infrastructure
(PKI), the PPP, and various other networky-cryptography-security
standards!

Please use ssl. Do not attempt your own cryptography.

> >>2. server decrypt this number using RSA private key.
> >
> > It will be decrypting the number provided by the man in the middle, not
> > that provided by the client.

See?

> >>3. Server and client using this number for synchronization of the RNG.
> >
> > Man in the middle simulates it to both sides.

OK?

> >>After that:
> >>Sender: output=char+RNG[i++] -> Receiver" char=input-RNG[i++];
> >
> >
> > Are you saying that they are using a generated offset (module 256)?
> > They aren't doing an xor?
> >

> Ok. let's RNG generate such sequence: 1, 10, 250, 3, 100 ...

I don't need examples. A simple yes or no is fine.

> > Uh - even without the man in the middle, this is vulnerable to
> > poisoning attacks. One can see the start so if one can induce the client
> > to send a known startup text, one can see the first RNG offsets used,
> > and that should be enough to narrow the search for the seed.

> See above. I think you understand now that it is a nonsense.

No, I understand that you don't understand. It isn't nonsense.

And even without the RSA keys it is easy to decrypt - we can calculate
the entropy of every 8 byte sequence, in a rolling calculation. The
entropy will peak at the points where you have injected 8 bytes of
random nonsense. We can observe the period, and excise the random
insertions.

(We can also now examine the random insertions for statistical biases
introduced by your pseudo RNG)>

That leaves us the raw stream encrypted with a simple + offset
generated by a pseudo RNG. At that point we can do a
poisoning attack.

> >>In the channel we will have a random stream (noise).
> >
> >
> > It's not random - we all know where in the stream it is or neither side
> > could discard it! It's probably the first and last 8 bytes of every
> > sequence of 64 bytes. Or something like that. Anyway, the algorithm
> > will be known as we can debug the client. So we can discard the random
> > bytes. So they don't help you to make the search space larger.
> >
> >
> >>Can you decrypt this stream on the fly?
> >
> >
> > See above.
> >
> >
> >>For decryption you should:
> >>1. Have the algorithm of the RNG (probably it is not a problem)
> >
> >
> > Indeed.
> >
> >
> >>1. Catch the start of the session and get first 64 bytes.
> >
> >
> > Aha, I thought so. Well, what's the problem with that? We can see every
> > packet on the net if we can see any!
> >
> >
> >>2. Decrypt RSA key and using it for decryption of the number (i).
> >
> >
> > Not necessary since (1) we can do a man in the middle attack, or (2)
> > we can deduce the seed used by observing the initial part of the
> > stream.
> >
> >
> >>2. Take any byte in the stream one by one. If you lost one byte - you
> >>lost the synchronize.
> >
> >
> > So what? And we don't lose any bytes, since the server and client
> > don't.
> >
> > Now - how were you planning on detecting somebody who altered the
> > stream?
> >
> > Answer, you weren't.
> >
> > This is not cryptography. Please just use the standard ssl mechanisms.
> > Do not attempt to invent your own.
> >
> >
> >> >I wouldn't pay someone who can't even spell "authorized" correctly on
> >> >their website. Must say something about the security.
> >
> >
> >>Thanks. Fixed.
> >>I'm Russian, so my English is not my strong side.
> >
> >
> > You have the same access to a spell-checker as we have.
> >
> >
> >>On the other hand if you would try to speak Russian...
> >
> >
> > We would use babelfish for a weird approximation and pay a translator to
> > get it right. If we were serious.

Peter

Relevant Pages

  • Re: Windows->Linux. Graphical terminal emulator.
    ... The client doesn't ... >> have the servers public key until it contacts the server, ... So it's vulnerable to a man in the middle attack. ...
    (alt.os.linux)
  • Re: Windows->Linux. Graphical terminal emulator.
    ... Vulnerable to man in the middle attack first time. ... The client doesn't ... have the servers public key until it contacts the server, ...
    (alt.linux)
  • Re: Windows->Linux. Graphical terminal emulator.
    ... Vulnerable to man in the middle attack first time. ... The client doesn't ... have the servers public key until it contacts the server, ...
    (alt.os.linux)
  • Have Script Deal with SSH/SCP password Prompt
    ... I have my one client with the private key and numerous servers with the ... public key to one of the servers? ... SCP will prompt for a password and my script will ...
    (comp.security.ssh)
  • [NT] Dark Age of Camelot Man-In-The-Middle
    ... use of RSA public key cryptography and an RC4 based symmetric algorithm. ... Seeing the imminent release of code for cracking the game client (which ... At the beginning of each TCP session, the server sends a 1536 bit RSA ... void bytes_out(unsigned char *data, int len) ...
    (Securiteam)