Re: Public-Private Keys (WireShark)
Posted: Thu Jun 03, 2010 6:55 pm
Resources & Tools for Open Source Uru
https://forums.openuru.org/
Another article points out the D-H related weaknesses in RSA encryption and how D-H is more vulnerable. (Reference)Baker – UCLA 1999 wrote:Diffie-Hellman does have a weakness: If an intruder Charlie can intercept and resend email between Alice and Bob, then the intruder can pretend to be Bob for Alice and pretend to be Alice for Bob, substituting his own yC and tricking each of Alice and Bob into having a shared secret key with him. There are ways to fix this problem. (Reference)
You may go ahead and think whatever you like. I know that what I say will not affect what you think, after these years of reading the forums. I responded to your post because I wanted other people reading the thread to have non-generic examples of what the encryption is doing for them.Nalates wrote:Ill take your laughter as conceding the point and a lack of knowledge about the weaknesses in Diffie-Hellman
This is why I provided specific examples of its use in MOUL. I guess they were not good enough reasons for you. I hope they are good enough for others.Nalates wrote:You also seem to misunderstand the focus of my point. It is not whether encryption in general is useful and secure but whether it is worthwhile as used within MOULa/Open Uru.
Yes. You seem to be arguing about key sizes without knowing what MOUL uses. If you have read the instructions for the Wireshark plugin, they tell you (indirectly).Nalates wrote:(various references)
For Diffie-Hellman to be secure large keys need to be used to force significant time consuming encryption and decryption to prevent the MITM attack or at least make such an attack detectable.
I will say it no more times after this, but my opinion is that YES it is worth the CPU cycles because obfuscation isn't the point of the encryption to begin with. I don't understand this fixation with obfuscation, but /shrug.Nalates wrote:It is better than nothing, but my point is; is it worth the CPU cycles once the server and client code is published and obfuscation is pointless?
How so? You don’t have the private key or the session key.Nalates wrote:However, anyone determined enough to hijack the data stream is going to find and easy way to monitor the conversations. Compared to hijacking a router I think reading the code to see what the server sends to the client and use it to monitor a conversation is simple.
This is true, but as has been pointed out multiple times, this is a completely separate issue from whether the connection is encrypted. Are we talking about encryption here, or are we talking about vault security?Nalates wrote:With the server code all the admin-functions are available to them. Even if Cyan keeps their admin client (if one exists) private all the server side responders are there for reverse engineering. Once we have the code we will have everything needed to know what to exploit. No key cracks needed.
Please read the code before making such claims. Uru does not use D-H in the configuration that the Wikipedia article points out as vulnerable to man-in-the-middle attacks.Nalates wrote:Also once the route is taken over a MITM attack can sit there creating spoofed key exchanges. Christian’s link is to a wiki Diffie–Hellman entry that includes an example of how D-H can be intercepted to make their point a dual system is needed.
Obviously any application of cryptography depends on strong keys, so I’m not sure what point you are trying to make. We have a lot more information than you seem to think. I lack the expertise to judge the key strength, and have not measured the performance impact, but all information about how MOUL’s connection encryption works is known. If lack of that information was the only thing keeping you from putting things in perspective, then go read that information and go ahead.Nalates wrote:So, the points made here by Christian and a'moaca' for security and the use of encryption are valid for strong keys, I’m not sure we have the information to know whether the implementation in MOULa actually provides that. I’m not sure we know how much additional calculation the system is loaded with because of the encryption. Until we do, we can’t put it in perspective.
That may be the case, but I think it only does that for people like you who know that there is encryption, but don’t understand enough of it to know what it provides and what it doesn’t. I think you are pretty unique in that regard. Most people neither know nor care, and of those that do know, most understand it.Nalates wrote:I suspect the present encryption […] engenders a false sense of security.
In the context of a MITM a cracker would have already dome some sophisticated cracking and would have demonstrated determination. If MOULa is using the D-H key exchange then one is not using the RSA type keys and block cipher, which could prevent the problem and I suspect is what most think of when private/public keys are brought up. D-H has the weakness of a MITM being able to factor smaller keys in a reasonable time and then spoof connections after that. Your example and the Baker paper both describe how it is done.Christian wrote:How so? You don’t have the private key or the session key.
Christian wrote:Are we talking about encryption here, or are we talking about vault security?
Christian wrote:Please read the code before making such claims. Uru does not use D-H in the configuration that the Wikipedia article points out as vulnerable to man-in-the-middle attacks.
I suppose since I deal with encryption on practical level and usually only have to deal with the tech sorting out how a client’s system, using their recommended process, was cracked; it is an odd mix of executive white paper and tech knowledge.Christian wrote:That may be the case, but I think it only does that for people like you who know that there is encryption, but don’t understand enough of it to know what it provides and what it doesn’t. I think you are pretty unique in that regard. Most people neither know nor care, and of those that do know, most understand it.
I’m sorry I can’t make much sense of what you are saying, in the context of Uru. I was hoping for a concrete step-by-step explanation of how you think Uru’s client-server communication can be eavesdropped on that I could try to confirm or refute. For now, I remain unconvinced that Uru’s network communication is sufficiently insecure to remove the encryption entirely.Nalates wrote:In the context of a MITM a cracker would have already dome some sophisticated cracking and would have demonstrated determination. If MOULa is using the D-H key exchange then one is not using the RSA type keys and block cipher, which could prevent the problem and I suspect is what most think of when private/public keys are brought up. D-H has the weakness of a MITM being able to factor smaller keys in a reasonable time and then spoof connections after that. Your example and the Baker paper both describe how it is done.Christian wrote:How so? You don’t have the private key or the session key.
You state the keys in MOULa are hard coded in, which means anyone will have the public key and the key generation process for some type of D-H negotiated key exchange. That puts a cracker a long way down the road. When communication is encrypted using a private key, the point is to assure the recipient it is coming form the author as claimed not to secure the communication, as anyone with the public key can decrypt it. With the D-H process added and the process known the typical MITH explained in the texts doesn’t seem more than a tedious challenge.
Right, and I think that question has been answered in the meantime, with the answer to the connection of the two issues being “because these two things have nothing to do with each other”, and the answer to “why encrypt” being “because it is necessary (even if not sufficient) for privacy and protection from malicious software”.Nalates wrote:My initial curiosity was why we would encrypt the data stream because it does not provide vault or server control security, control being whether the client can tell the AV to fly or be a bahro or stack cones, when we already have authorized access.
My knowledge in this area is sketchy, but I believe that Uru does not do that. In the examples I have seen (which are few and only cover a minority of cases, but I’m working on that), chat messages were always explicitly addressed to every recipient.Nalates wrote:I know large systems trying to reduce load on the server often leave it up to the client to filter by distance or whatever to reduce chatter, server load verses bandwidth load. If the server is shotgun’ing it means I can modify my client and never have to deal with cracking the keys because the client is already doing it for me.
This is correct. In this case, ensuring the privacy of your chat requires both an encrypted connection and a secure server (that will only grant such privileges to authenticated CCRs). I do not trust that we currently have the latter, but once the source is out we will hopefully have it soon enough. We do have the former. I don’t see how the current (assumed) lack of the latter would be a reason to drop the former as well – when you have a locked front door and a broken back door, would you say “let’s remove the lock from the front door, it’s only an annoyance and provides a false sense of security since people can get in through the back door anyway”? I would rather say “let’s fix the back door as soon as we can”. I’m skeptical about the “false sense of security” argument in particular because I suspect that few people even think about the front door lock because it’s automatic and invisible to them, while many should by now be aware of the broken back door, especially after the Bahro incidents.Nalates wrote:If I were to target someone and could use admin or modified commands from a modified client then I could see where their AV is, tell the sever I am there and listen to all the chat with a modified client.
I mean any code that is available right now that implements the MOUL encryption, such as the one from libHSPlasmaNet (recommended, very readable) or from the Wireshark plugin (or, if you are so inclined, the MOULa machine code).Nalates wrote:I assume you mean the MOULa code, I may when it is published.
That is true, strictly speaking, however there was also an implied claim that your writing was somehow relevant for Uru, and that was what I was taking issue with. At least I perceived such a claim. Now that you tell me that that perception was mistaken, I can do nothing but stand corrected, however I think other readers might have made that assumption as well, so I still think my objection was justified.Nalates wrote:There is nothing your quote of my writing that is not fact.
Asking questions doesn’t, but making assumptions does. And while you are rhetorically careful enough to state your assumptions in such a way that you can still claim that they weren’t assumptions about Uru but general unrelated remarks, I find that style of conversation hard to follow and may occasionally misinterpret.Nalates wrote:But, asking the question I asked about the worth of the encryption process in MOULa shouldn’t really require reading the code.
We know that by now. I don’t think pushing people to frustration is a very nice tactic, but we sometimes play along for a while in hopes that an insightful discussion might still develop, and to protect the public from misinformation.Nalates wrote:So, I push them to the point of frustration to find out what they do know.
I deliberately haven’t mentioned it in order to give you an incentive to look it up yourself, and maybe learn some more things in the process. It’s 512 bit.Nalates wrote:For instance you don’t know the key strength but you haven’t even mentioned key size used in MOULa.
Correct. My opinion is based on the principle of “innocent until proven guilty” in this regard, as is standard practice in software engineering to avoid premature optimization, and on the knowledge that RC4 is a quite computationally light algorithm.Nalates wrote:what kind of performance load it puts on the game and whether it is worth the cycles remains unclear and in the area of opinion
a'moaca' gave an answer:Nalates wrote:The idea of knowing which server one is connected to… I still haven’t seen one answer if that is a real concern.
“You are connected to the server that you think you are” is the same thing as “you are not being the victim of a man-in-the-middle attack”.a'moaca' wrote:Encrypting the auth connection is right now the ONLY thing protecting your computer from man-in-the-middle attacks on the Python download. I think protecting your computer counts as actual security. Man-in-the-middle attacks are real. Obviously Uru is not a big target, but if I wanted a botnet I wouldn't mind an easy target. Encryption is for THAT.
Code: Select all
Key generation (beforehand):
Choose a random 512-bit number a. This is the private key.
Choose a random 512-bit prime N.
Compute X = 4^a mod N. X and N together make up the public key.
Client side:
Choose a random 512-bit number b. Compute s = 4^b mod N and send it to the server.
Server side:
Compute c = s^a mod N.
Choose a random 7-byte number d and send it to the client.
Compute k = d xor (first 7 bytes of c) and use it as the session key for the RC4 encryption.
Client side:
Compute c = X^b mod N.
Compute k = d xor (first 7 bytes of c) and use it as the session key for the RC4 encryption.
Unless you mean to say that RSA also puts a cracker a long way down the road, which I don't think you meant to say as you held it up as a better way to do things than what you understood MOUL to be using.Nalates wrote:You state the keys in MOULa are hard coded in, which means anyone will have the public key and the key generation process for some type of D-H negotiated key exchange. That puts a cracker a long way down the road.
It does matter, because protecting the channel prevents those without special clients from reading your chat. E.g. your employer or neighbors or whatever. BUT, this mythical client that lets you listen to all conversation does not exist.Nalates wrote:But, does that matter when one can tell the client to listen to all the conversation coming from the server while logged in?