Developers interested in helping with light built-in encryption project

Jonathan Morton chromi "at" cyberspace.org
Wed, 27 Jun 2001 13:45:13 +0000


>Some of you may remember me as one of those who started one of the periodic
>"we should add encryption" discussions a few months ago.
>
>Anyway, I'm back. And, having finished school, I finally have some time to
>experiment more directly with the code. I'd like to find any other
>developers or security specialists out there who would be interested in
>helping in the design, testing, and security strength evaluation process of
>adding a light encryption layer (ie, probably not doing PKI, or relying
>heavily on the pipe-dream of protected storage at a typical server) to VNC.
>
>Please e-mail me directly, off-list. I will gauge interest, and figure out
>which direction to go from there.

I've already got lots of ideas bouncing around in my head about this, 
and some of them have been bounced off other people as well.  At some 
point I need to get them down on (virtual) paper and see if it still 
makes sense as a whole...

The scheme I'm thinking of essentially encapsulates RFB in "packets" 
of arbitrary length, but with each packet containing an integral 
number of RFB messages.  This adds robustness to VNC, even if no 
encryption or compression is done within this format.  I have a 
protocol for initial key/scheme negotiation, some ideas on stream 
format, and some justification for why things are so.

Yes, it's loosely based on ideas found in the SSH (v1 and v2) 
protocol.  AFAICT, SSH v2 is the Right Thing in many ways, but a 
little over-complicated in some other ways.  I've also seen some 
examples of What To Avoid in the SSH v1 protocol, and duly attempted 
to avoid them.  Security is probably slightly weaker than SSH v2, but 
I'm making workarounds and fixes for everything that people can 
convince me is a problem, and I think it should actually be stronger 
than SSH v1 (which most people are still using today!).

Note that SSH v1 suffers from the same "man in the middle" 
challenge-swapping attack that VNC was shown vulnerable to, last year 
- my scheme is not, except in well-defined, less common, and 
user-avoidable circumstances.

Give me a little time (I'm moving out of university residence, bleh) 
and I'll start work on documenting my extensions (and proposed 
extensions, such as this one) to VNC.  I think it'd also be a good 
idea if I re-documented RFB itself, along with the various Tridia 
extensions and Tight encoding - that way, eventually, we have all the 
(technical) RFB documentation you could ever want, in one place. 
Documentation on the "hows and whys" of ChromiVNC's performance 
enhancements would also go there, to give people a chance to 
incorporate them into other servers and improve VNC overall.

It looks a lot as though I'll have the whole summer to work on this, 
and you can probably expect me to make the most of it.
-- 
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi "at" cyberspace.org  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
           V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------