AESV2Plugin001

Cobra · Post by **Cobra** » 2005-05-20 16:38

Hi Scovel,

I tried out your AES v2 Plugin on my UltraVNC Server (UltraVNC RC20.5). Unfortunately it didn't work out... It always gives me an error message from the server side. Even though I have put the files in the server directory and also in the viewer directory of UltraVNC on the other computer, it doesn't seem to work. Funny is, that I can connect to the server and enter the password (less than eight characters), but then it gives me an error message which tells me that something is wrong...

Other question which seems much more important to me. Isn't AES much more secure than RC4? I agree about what you said about the password lenght, but I'm sure that this will be solved quite soon, right? Aren't there some possible hack possiblities in RC4 - as far as I know RC4 wasn't implemented correctly in WEP for example. That's why nowadays you already can hack WEP quite fast. Don't exist the same problems here?

Thanks for your help!

Cobra

scovel · Post by **scovel** » 2005-05-20 19:39

Cobra,

First the AES V2 Plugin problem. This is the second time this has come up as not working. I know why, but haven't some up with a simple solution (yet!). The problem is that the Server isn't finding the libeay32.dll when its getting started up. The easiest way to correct that at the moment is to add the UltraVNC directory to your system path (system environment variable). Do this on both the viewer and server machines and it will work.

Other question which seems much more important to me. Isn't AES much more secure than RC4? I agree about what you said about the password lenght, but I'm sure that this will be solved quite soon, right? Aren't there some possible hack possiblities in RC4 - as far as I know RC4 wasn't implemented correctly in WEP for example. That's why nowadays you already can hack WEP quite fast. Don't exist the same problems here?

This is a complicated topic. RC4 encryption (with a 128 Bit key) has not been broken, if implemented correctly. WEP was a severly broken implementation of RC4. The authentication mechinism was easily exploited, the IV was too small, so it repeated often, and specific vendors reset the IV back to 1 after every session. The result of the flaws was that information about the KEY WAS LEAKED. Using the leaked information, the key could be guessed in a very short period of time (less than 10 min.!) RC4 is still secure, but how WEP was implemented made it insecure. RC4 wasn't broken, WEP gave the key away!

The AES encryption algorithm is currently the NIST endorsed encryption method. The NIST held a competition to produce a new encryption algorithm to replace the broken DES and 3DES (triple DES) that was the previous government standard. So, yes, I guess AES is more secure...

Its also much more CPU intensive. And since RC4 128bit hasn't been broken, is AES more secure? Not broken is not broken...

I'm releasing a new ARC4 plugin shortly that will include the same IV and SALT code that I implemented in the AES V2 plugin. At that point the only difference in security between the two will be the NIST stamp of approval.

Sean

scovel · Post by **scovel** » 2005-05-20 20:29

Cobra,

The next version of the BETA plugins that use OpenSSL won't require a seperate libeay32.dll, it will be statically linked into the DSM file. That will solve that problem.

Sean

Cobra · Post by **Cobra** » 2005-05-20 20:29

Scovel,

first of all thanks for your comprehensive explanations! They really helped me. I guess I'll wait with using the AES-Plugin until it overcomes the 8-characters password problem. I'm still very happy with your RC4-Plugin.

But indeed the AES-Plugin seems very interesting! Congratulations on that!

To RC4, yes it's still hasn't been broken so far. According to a well-known cryptographer the only danger lies in not using an initalising vector with RC4. I have to be honest with you, I'm not very into cryptography, but indeed very interested in the subject itself (even though I get always stuck on the mathematical level...

). You certainly heard about this implementation problem. How did you implement this into your plugins, if I might ask you?

Would it be possible to create a plugin where you could choose from different encryption methods (RC4, AES) and different key lengths (128bit, 256bit)? Or would this be an overkill of workload and far beyond the realms of possiblity? As an example, I'm thinking of the well know encryption tool PGP, where you can construct a specific key after your needs.

Best regards

scovel · Post by **scovel** » 2005-05-21 01:48

Cobra,

I guess I'll wait with using the AES-Plugin until it overcomes the 8-characters password problem.

Actually, since I use SALT and a hash with the password, it gets "stretched" into a much longer (128bit) password. And since the SALT is a new random number for each session, it is far more secure than even the 128bit key file that never changes.

You certainly heard about this implementation problem. How did you implement this into your plugins, if I might ask you?

I recently wrote up a paper on WEP vs. WPA/WPA2 for my company, so I'm very familiar with the problem now.

The new BETA plugins (AES V2, and ARC4 004) are using functionality from OpenSSL's crypto library. There is code in there for SALTing and IV setup. I had to add some code to the plugin to exchange the additional information to create the shared keys for each session.

The AES "V1" code is a little different. It was written by WorkSpot. I've really got to take the time to write up exactly what that one is doing. Its AES in CCM mode. No IV or SALT. The password is hashed, but not SALTed...

The MSRC4 plugin.... Well, gotta be honest. The more Microsoft does for you the more it does TO you... The password is a randomly generated 128bit key. Since I didn' have to write any additional code to support IV, I'm sure its NOT using IV. I wrote that one years ago before I started researching this encryption stuff in detail. I'll probably start to retire this one as time passes. I like the OpenSSL stuff better. Its Open Source, and cross-platform.

Would it be possible to create a plugin where you could choose from different encryption methods (RC4, AES) and different key lengths (128bit, 256bit)?

Funny you should ask that. The difference between the AES V2 plugin, and the ARC4 (beta 004) plugin is 2 lines of code. I'm not sure the users would want to have to configure the plugin for each use, but it IS possible.

Cobra · Post by **Cobra** » 2005-05-22 10:35

Hi Scovel,

scovel wrote:Actually, since I use SALT and a hash with the password, it gets "stretched" into a much longer (128bit) password. And since the SALT is a new random number for each session, it is far more secure than even the 128bit key file that never changes.

Seems convincing to me. I actually prefer AES rather than RC4. And I see that you are doing a great work!

scovel wrote:The MSRC4 plugin.... Well, gotta be honest. The more Microsoft does for you the more it does TO you... The password is a randomly generated 128bit key. Since I didn' have to write any additional code to support IV, I'm sure its NOT using IV. I wrote that one years ago before I started researching this encryption stuff in detail. I'll probably start to retire this one as time passes. I like the OpenSSL stuff better. Its Open Source, and cross-platform.

Fully agree about the OpenSSL - in my opinion Open Source is much more falsification proofed than software which comes from a company that never publishes its source code...

scovel wrote:Funny you should ask that. The difference between the AES V2 plugin, and the ARC4 (beta 004) plugin is 2 lines of code. I'm not sure the users would want to have to configure the plugin for each use, but it IS possible.

Two lines of code? And this makes the difference between the AES and RC4 encryption? Are you a magician? Actually this would be a good question for other UltraVNC users. What is their opinion about that topic? I would like to see their different opinions and views.

Is it difficult to implement a 256bit key for AES or would that be a) too much work and b) use too much CPU ressources?

Regards,

Cobra

scovel · Post by **scovel** » 2005-05-22 17:57

Cobra,

Two lines of code? And this makes the difference between the AES and RC4 encryption? Are you a magician? Actually this would be a good question for other UltraVNC users. What is their opinion about that topic? I would like to see their different opinions and views.

Two lines of MY code. The OpenSSL crypto library is really taking care of the ARC4 and AES encryption. I'm just telling it which algorithm to use. Thus the "2 lines of code."

Is it difficult to implement a 256bit key for AES or would that be a) too much work and b) use too much CPU ressources?

I don't think that it would be difficult. Not sure I'd bother though. From my research, a secret secured with 109 bits should be secure for about 20 years. If your UltraVNC session needs to be secure longer than that, than maybe you shouldn't be conducting your busines over the Internet...

I suspect that 256bit encryption is going to introduce considerable lag to your UltraVNC connection. AES already introduces 3X the latency of ARC4. I guess it comes down to how secure is secure, and how much lag you can tolerate.

Sean

Cobra · Post by **Cobra** » 2005-05-24 14:47

Hi Scovel,

scovel wrote:I don't think that it would be difficult. Not sure I'd bother though. From my research, a secret secured with 109 bits should be secure for about 20 years. If your UltraVNC session needs to be secure longer than that, than maybe you shouldn't be conducting your busines over the Internet...

I suspect that 256bit encryption is going to introduce considerable lag to your UltraVNC connection. AES already introduces 3X the latency of ARC4. I guess it comes down to how secure is secure, and how much lag you can tolerate.

O.K., that seems reasonable. Actually it was just a question of "possibility" and personal interest. I don't think I'm paranoid...

I was testing your latest plugins AESV2Plugin002 and ARC4Plugin002. It's working really fine without a big lag (well, I'm testing it on my private LAN). But I mentioned one thing: If you copy first the AESV2Plugin002 to your UltraVNC directory and then the ARC4Plugin002 and don't overwrite the three files (libeay32.dll, readme.libeay32, vssver.scc), which were already installed from the first plugin, you always connect via the AESV2Plugin-v0.0.2.0 even though you selected the ARC4Plugin. I guess it has something to do with the last mentioned file vssver.scc, which has a different size. I tried it several times after a reboot of the system and it always shows me Ultr@VNC Viewer + AESV2 Plugin-v0.0.2.0, even though I have selected the ARC4Plugin.dsm.

Any good ideas from your side?

Thanks so far!

Cobra

scovel · Post by **scovel** » 2005-05-24 15:31

Cobra,

and don't overwrite the three files (libeay32.dll, readme.libeay32, vssver.scc), which were already installed from the first plugin, you always connect via the AESV2Plugin-v0.0.2.0

libeay32.dll is no longer needed. In fact, go ahead and delete all 3 of those files.

I guess it has something to do with the last mentioned file vssver.scc, which has a different size.

HaHa! vssver.scc is created by SourceSafe to tell me if the file is "checked-in" or "checked-out." It has NOTHING to do with the plugin. (It shouldn't be in the zip file either...)

Depending on where you make the change from (local or remote) you may need to restart the service before it will change plugins.

On a complete reboot, UltraVNC looks in the registry for the name of the plugin it should be using. If its got the wrong one, that's an UltrVNC problem.

You might want to download the plugins again if you downloaded before Monday afternoon. I had a couple of "issues" with the files that got up to the website. I fixed them yesterday.

Sean

Cobra · Post by **Cobra** » 2005-05-24 16:38

Hi Scovel,

scovel wrote:Depending on where you make the change from (local or remote) you may need to restart the service before it will change plugins.

That's what I always did on my remote machine (server).

scovel wrote:You might want to download the plugins again if you downloaded before Monday afternoon. I had a couple of "issues" with the files that got up to the website. I fixed them yesterday.

I did that, but it keeps the same. The UltraVNC window tells me that I'm using Ultr@VNC Viewer + AESV2 Plugin-v0.0.2.0. even though I've selected the ARC4Plugin for the server and the client. Funny somehow...

UltraVNC Problem?

Best regards,

Cobra

scovel · Post by **scovel** » 2005-05-24 19:10

Cobra,

Sorry,

What I meant was:

If you are changing the server's settings, and you are sitting at the physical keyboard, then changes "might" be immediate.

If you are changing the server's settings inside an established VNC session, then you will have to restart the vnc server before the change takes effect.

Oh CRAP!!!! Looks like I have a cut-and-paste error. The ARC4 plugin is reporting itself to Ultra as AESV2. THAT's why you are having trouble. Doh!

I'll copy a new zip file up in a few min. It'll have the same version number though.

Sean

scovel · Post by **scovel** » 2005-05-24 19:17

Cobra,

Ok, its up there. I cleaned up the zip files too. They shouldn't have any "extras" in there anymore.

Sean

Cobra · Post by **Cobra** » 2005-05-25 14:51

Hi Scovel,

scovel wrote:Ok, its up there. I cleaned up the zip files too. They shouldn't have any "extras" in there anymore.

O.K. I downloaded the files and installed them on the machines. Now it's running fine with both encryption keys! Very smooth & nice! Great work!! I guess you reached production status now.

Best regards,

Cobra

P.S. It would be nice if you hadn't to restart the machine for a change of the encryption key. But I guess that's quite complicated isn't it? :x

scovel · Post by **scovel** » 2005-05-25 15:00

Cobra,

Thanks for the good report! My "automation" scripts are finally working correctly. I think they are near production ready too. I don't forsee any changes that will break compatibility in the near future.

As far as changing plugins. If you are sitting at the server's console, and there are no connections, you should just be able to switch plugins. Worst-case, you should have to restart the service.

Sean

Cobra · Post by **Cobra** » 2005-05-25 15:05

Sean,

scovel wrote:As far as changing plugins. If you are sitting at the server's console, and there are no connections, you should just be able to switch plugins. Worst-case, you should have to restart the service.

That's why I'm asking. My server machine doesn't have keyboard, mouse nor screen. It's just connected via a network cable. I always connect my computers like that.

Regards,

Cobra

scovel · Post by **scovel** » 2005-05-25 17:09

Ah, interesting. I have some Linux boxes like that. Actually I inherited a 16 port KVM awhile back, so all my machines have "heads" at the moment.

The issue with changing the plugin from a VNC connection is a security issue. If you were a cracker and you broke into a machine, probably the first thing you'd do is diable the encryption plugin so you could get back in more easily.

If you haved to restart the service to diable the plugin, you either have to get administrator access, or have physical access to the machine.

In your case, you could create a batch file to automate it (net stop, net start) or you could use SC to restart the service remotely.

Sean

Cobra · Post by **Cobra** » 2005-05-25 18:03

Hi Sean,

scovel wrote:Ah, interesting. I have some Linux boxes like that. Actually I inherited a 16 port KVM awhile back, so all my machines have "heads" at the moment.

I know the KVM solution, that's a nice possibility to connect to different computers and using just one screen, mouse and keyboard. But sometimes you don't even have enough space for that... It always depends on how many machines you want to connect to.

scovel wrote:The issue with changing the plugin from a VNC connection is a security issue. If you were a cracker and you broke into a machine, probably the first thing you'd do is diable the encryption plugin so you could get back in more easily.

Sounds reasonable to me, it was just a question of possibility. I think it would be very "handy" to handle it like this. Other question: Isn't it a seucrity issue if you can disable the UltraVNC icon in the icon bar... :x

scovel wrote:In your case, you could create a batch file to automate it (net stop, net start) or you could use SC to restart the service remotely.

It's quite probable that I will do something like that. But to be honest with you I absolutely love the AES encryption plugin you wrote and I'm going to use that one as standard! That one rocks!

Best regards!

Cobra