I think the simple answer is: vnc cannot because it cannot code itself. The developpers willnot/cannot because it is not in the developmentpath.
As far as I'm concerned, the developmentpath for the core vnc development will not incorporate new features like these as long as the spinoffs like zvnc, yvnc, xvnc, wvnc, vvnc, uvnc and such have not implemented it successfully and satisfactory. Leaves out YOU: Do it yourself or pay someone to do it for you. CBee -- C. Beerse mailto:[EMAIL PROTECTED] talkto:+31(71)5256660 > -----Original Message----- > From: Mike Miller [mailto:[EMAIL PROTECTED]] > Sent: vrijdag 14 februari 2003 16:23 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re[2]: Automatic Encryption > > > Here's a simple question: Why can't VNC server and viewer just use > established SSH protocols to communicate? Incorporate > OpenSSH code into > the server and PuTTY (or whatever) code into the viewer. Isn't that > workable? The keys wouldn't be encoded in the password, they would be > handled in the way that SSH normally handles them. > > Mike > > > On Fri, 14 Feb 2003 [EMAIL PROTECTED] wrote: > > > You cannot just KISS, not with encryption, this is the point. You > > cannot just apply AES to the stream. How do you plan to agree on the > > keys used for encryption ? Use the VNC password ? I think not, you > > have not enough entropy in a normal password). How do you plan to > > exchange the keys in a safe way (remember this are the keys used to > > encrypt the AES tunnel, so you don't have encryption in place). Now > > let's assume you get one / some random 128 (or more) bits key(s) and > > manage to exchange them somehow securely (let's say you go to each > > host and remote with floppies). How do you plan to make the > > authentication ? Just encrypt the streams and leave the > remote<->host > > trying to find each other like deaf bats ? What if an > attacker records > > and plays back the stream at a later time ? And this is the simple > > part, to put all the pieces together. There are a lot of design > > problems to be solved BEFORE you start writing ONE line of code. But > > it is _very_ hard to write secure code, even if you have a very good > > and complete algorithm. Many > > trusted programs (like apache, openssh) had at least one big remote > > buffer overflow last year. And we are talking about software using > > well known algorithms, not some one week old inventions, with very > > good track record for security. It is _extremely_ unlikely > to invent and > > to implement something even remotely secure as openssh (which is not > > bulletproof) in one year, as a plugin for vnc. Sometimes it > is better > > to know that you have no security/encryption than to rely on bad > > security/encryption. And you will _not_ have good > security/encryption > > as an afterthought for vnc (not that I don't trust the vnc > > programmers). > _______________________________________________ > VNC-List mailing list > [EMAIL PROTECTED] > http://www.realvnc.com/mailman/listinfo/vnc-list _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] http://www.realvnc.com/mailman/listinfo/vnc-list
