aesv2.key easy to create it with notepad (security hole?)

[redge]

aesv2.key easy to create it with notepad (security hole?)

1 save any previous aesv2.key

2.
open notepad
write text as example: "aesv2.key" (without quote)
save document as aesv2.key
copy the file for both vncviewer and winvnc
try to connect with uvnc 1.0.4RC16 + aesv2plugin.dsm both side between xp to xp
succes

remark:
the aesv2.key is not encrypted, this just a clear text "aesv2.key" for the example.

[krunge]

open notepad
write text as example: "aesv2.key" (without quote)
save document as aesv2.key
copy the file for both vncviewer and winvnc
try to connect with uvnc 1.0.4RC16 + aesv2plugin.dsm both side between xp to xp. succes

remark: the aesv2.key is not encrypted, this just a clear text "aesv2.key" for the example.

No one replied to your post, although perhaps you know the answer already.

There is no obscuring, encrypting, or OS shielding for the aesv2 and arc4 keyfiles. The files contain the 16 raw bytes that are the secret key.

Also for the MSRC4 plugin, the MS CryptoAPI is used, but in this case as well the raw key bytes are directly accessible in the 'rc4.key' file.

Here is the recipe for getting the 16 secret key bytes out of the MSRC4 rc4.key: go to the 23th byte and pick out the next 16 bytes (the one after the last one should be a null byte). Reverse the order of those bytes, that is the RC4 private key. SSVNC uses this recipe for the MSRC4 case.

[redge]

although perhaps you know the answer already.

No
I just experienced without know the reason why this so easy making a fake key or manual create ke
and your explanation is mathematical and i'm not very aware of mathematical (i'm poor in Mathematical exams)

[plouf]

AFAIK and to my understanding the "key" is just broadcasted in the begining of a transaction
thought ANY key you make will be consider as "the key" and both client and server will encrypt data with this key (Any key you make)

correct me if wrong thought

[krunge]

No
I just experienced without know the reason why this so easy making a fake key or manual create ke
and your explanation is mathematical and i'm not very aware of mathematical (i'm poor in Mathematical exams)

Sorry for not being clear. The key is just 128 random bits (= 16 random bytes) made when you click on 'Gen Key'. For AESV2 and ARC4 they are simply stored as-is in the key file (e.g. new_arc4.key). There is nothing hiding them. The same is true for the MSRC4 plugin (rc4.key), but the file format is a little different.

So when you edit aesv2.key in notepad and type in something else in it is as though those were the random bytes generated by 'Gen Key'.

When a DSM plugin uses the VNC password instead of the key file data, the password string simply replaces the data (I guess padded with zeros to make it 16 bytes long)

BTW, in your example "aesv2.key" that is not 16 bytes long. I think if the aesv2 or arc4 keyfile is less than 16 bytes then the dsm plugin (silently?) falls back to using the password as the key data.

[krunge]

AFAIK and to my understanding the "key" is just broadcasted in the begining of a transaction
thought ANY key you make will be consider as "the key" and both client and server will encrypt data with this key (Any key you make)

correct me if wrong thought

The keyfile data (i.e the stuff in arc4.key or aesv2.key; what was being discussed) is not broadcast at the beginning.

What is broadcast at the start is 16 fresh random bytes of 'salt' followed by 16 fresh random bytes of 'initialization vector'. The receiver then combines that with the secret keyfile data to create what should be a unique session key. The sender has created the same session key and so he encrypts with it and the receiver decrypts with it.

[redge]

thank you for the explanation, there the hole, use silently the vnc password instead the key or key not enough encrypted let another key used instead check the requirement is not enough for start encrypted connection. ie key don't have enough data .

What is broadcast at the start is 16 fresh random bytes of 'salt' followed by 16 fresh random bytes of 'initialization vector'.

How the receiver can know the vector if sender send it at random ?
I stop thinkinh about that. Mathematical make me headache. too complicate.

[krunge]

thank you for the explanation, there the hole, use silently the vnc password instead the key or key not enough encrypted let another key used instead check the requirement is not enough for start encrypted connection. ie key don't have enough data .

Yes, that does sound like undesirable app behavior. Maybe should be popup warning?

How the receiver can know the vector if sender send it at random ?
I stop thinkinh about that. Mathematical make me headache. too complicate.

Well, forgive me adding to the headache...

The first 32 bytes of the session data stream are random salt (16B) and random initialization vector (16B) the sender created on his computer for this vnc connection. Everything after these first 32 bytes is the encrypted VNC traffic from the sender.

So the receiver now has these 32 bytes. Any eavesdropper snooping the connection also has them. But that is OK, because these bytes are not the session key (i.e. the key used for this VNC connection), they are just used to be scrambled with the shared secret key (e.g. aesv2.key data) to form a unique session key for this VNC connection.

By using different session keys each time, the eavesdropper has a much harder time trying to crack the encrypted VNC traffic.

The "scrambling" is just a MD5 (MD=message digest) checksum, are you familiar with that? Headache?

[redge]

The "scrambling" is just a MD5 (MD=message digest) checksum, are you familiar with that? Headache?

less headache, but still complicate for me.
anyway, i believe the security how it work for do safety work, that all is necessary.