ARC4/RC4 is significantly faster (hundreds of times) than AES, but CPU speed is not much of a factor for newer computers. Still, this should be considered when dealing with large terminal server environments or low-spec machines

The Microsoft Crypto API provides a slightly faster implementation of ARC4 as compared to OpenSSL, although the difference is negligible

ARC4 is a stream cipher, and AES emulates that behavior via OFB mode. This allows the encrypted data to remain the same size as the original data

ARC4 == Alleged RC4, since the official RC4 algorithm is secret

All plugins assume Windows 2000 at minimum

Although all plugins are Windows-only, the OpenSSL implementations should be relatively simple to be implemented on other platforms

32-bit Windows only (64-bit may be created by merging changes from SecureVNC if enough interest, but developer recommends SecureVNC instead. If you have tried SecureVNC but still want this 64-bit, please let me know via PM)

32-bit Windows only (64-bit may be created by merging changes from SecureVNC if enough interest, but developer recommends SecureVNC instead. If you have tried SecureVNC but still want this 64-bit, please let me know via PM)

32-bit Windows only (64-bit may be in beta but not publicly available (?))

Not threadsafe (only one viewer on a server)

40-, 56-, or 128-bit (depends on OS and patch level) ARC4 symmetric key encryption, supposedly with unique IV (uncertain if mscrypto actually uses the IV; in OpenSSL, it is ignored.) Salt was removed due to issues with Windows 2000 compatibilty.

Beginning of keystream is not discarded; theoretically, this can leak information regarding the key

Known to work properly, although sometimes runs into issues due to Microsoft Crypto API issues

itsmee and other paranoid fellows may be interested in the upcoming version of SecureVNC, which is almost complete. The only real change is the addition of an optional 'pass-phrase' or supplemental password. In previous incarnations of the DSM plugins, the keyfile was hashed into a key rather than being used as a key itself, and the same process with the keyfile+password. Therefore the keyfile was, effectively, a 16-byte password.

However, the problem with this was that if you were elsewhere, you cannot access your secured VNC server without this keyfile, unless you are the kind of person who can easily remember 16 random bytes.

The new SecureVNC plugin allows the server to require a supplemental key as well. The user is prompted for a passphrase, which is hashed to create the supplemental key. The advantage is that it can be as long or complex as you desire, hence the 'passphrase' term. This is a lot easier to remember!

The proof-of-concept has already been created, but the usual delays include figuring out the user interface, configuration, backwards compatibility, and testing. But you'll know when it is out!