The mix of emphasis and shifts in thinking do get fuzzy from lack of care in our writing. The shift from; is it worth encrypting MOULa/Open Uru, to whether D-H could prevent a MITM scenario as justification for continuing encryption, as an aside, is ambiguously mixed in. I see where it could be confusing.
When I asked about the ‘worth’ of continuing encryption I was thinking reading code would require disassembly, which I find tedious. I will have to look up the libraries source and read through it, as I didn’t think of that. But, I asked because I hoped someone had already considered my question and had an answer. It seems that is not the case.
a'moaca' inferred I am advocating an opinion to remove or replace encryption. I thought I was clear that I don’t see the worth of encrypting beyond logon and was asking about that. No advocating. I conceded that justification for removal is a valid consideration and that I have no such justification for removal at this point. Again, yes, leave it in place until we have actual information.
a'moaca's inference is I don’t understand the purpose of encryption but then never picks up the objective in the OP question of actual worth and level of security. I just think he missed my point. I point out there are other ways to listen to the chat and infiltrate the server without cracking encryption and asked why are we encrypting.
a'moaca' uses the word ‘encryption’ for server identification when I think he means a key exchange and uses MITM as a mistaken reason to use encryption. The use of server certificates does not even require encryption of the exchange. With Christian putting forth the idea D-H key negotiation is used in OU and a'moaca' offering the MITM attack as a reason to encrypt, it seemed more an effort to claim encryption is the solution to the problem by proclaiming its weakness. I think Christian has it right that real security is in how the server and database are secured via authentication and input screening. I don’t see encryption helping in that regard and serves only as obfuscation.
While both a'moaca' and Christian comment about writing to keep people clear on facts and a need for forum members to be provided accurate information as the purpose. However, the issues of probability and worth of encryption in this application that would put things in perspective for non-tech’s is skipped over and omitted. So, is this thread more about shaping what others think about encryption or answering the question of is it worth the CPU cycles in Open Uru?
My thinking is that anyone that can pull off a MITM attack will be determined and knowledgeable enough to factor the 512-bit encryption, which I think I have shown is feasible. But, does it matter when the scenario is so improbable? …which is my point about worth of encryption in the OU app.
I do note the question about how real is the probability of some type of MITM attack for delivering bogus code is repeatedly ignored and whether I know how to crack a D-H algorithm is returned to, which has me questioning the purposes of the responses. I have quoted two papers that have step-by-step examples of how MITM attacks run and negotiate an intercepted exchange.
It seems Cyan’s private key is considered to provide identification beyond any question. I just don’t accept that. I think there is enough information in this post to show why. I personally would prefer a server cert for that task.
We seem stuck on whether it is possible to break the encryption. Whether MOULa uses a pure D-H scheme or not, does not matter if the question is whether the MOULa encryption can be broken or if it is invincible. I’ll shift the question and see if it moves us. Are you (Christian) coming to a determination of whether encryption is worth the cycles from the point of view
MOULa/Open Uru encryption cannot be broken? Or just not in the time available?
My experience is and everything I’ve read and know about security says all encryption can be broken. It is just a matter of time and whether the protected information is worth the effort. In Baker’s 1999 paper in section ‘C’ he describes how D-H can be spoofed for MITM. I could repeat his meta-coding here, similar to yours, to answer your question. But, he is showing the cracking process step by step and illustrating why key size counters it. What more did you want to know?
If the reason for encrypting is to protect login credentials, positive server ID, and provide ongoing privacy… then I previously agreed that login protection part is worthwhile. But, I think the server ID is already pretty well secured and spoofing of the servers is such a low probability it doesn’t provide a reason to spend those cpu cycles. I also think it has been generally agreed that there are several ways to eavesdrop on OU chat without cracking the encryption. If the server is not shotguning the chat, which neither of us knows, that still leaves admin controls. If it is, a WhoM type program built as a chat listener seems feasible and encryption is not a problem.
I don’t believe it is encryption that will keep people away from admin controls, but authorization and ID’ing the user that will. So, there is an imagined level of privacy and a real level of privacy, or its lack.
a'moaca's suggestion that those who like the idea of encrypted chat will be able to turn it on others off ignores that the server has to encrypt its side of the conversation in OU. So, we all experience some degradation in performance. But, that has yet to be quantified so we have no data to decide either way.
In that regard we have ignored voice chat. Is it encrypted?
Several posts ago I conceded that OU encryption (without regard to level or key size) would stop outside eavesdroppers and the network tube was protected from casual eavesdroppers. But that could be accomplished with a light weight SSL connection to the server which would use highly optimized systems already in place.
In regard to ‘worth’ and justification… Is OU chat worth encrypting? If one thinks so, what is there that people may want to get from the chat and what it is worth? Are you contending Open Uru chat justifiably needs to be secure or just that you prefer that? If its preference, it negates the questions and moves us on to whether the induced lag is worth your privacy. I think we are decided that cannot be quantified at this time.
If you are trying to politely ask ‘Code please’, thanks for the politeness. Before writing code I want a justification, which I currently don’t see. In any event I would not write the code, I would use an open source product, buy one, or hire a company to provide it. I know enough to see and understand the problems, in spite of what others think, but not enough to think I could write impervious security code.
In regard to how and whether the D-H and an RSA key exchange can be cracked so you won’t think I’m side stepping the issue… In a 1995 paper by M. Robshaw (
rsa.com) the time needed to factor 512-bit keys was described. He uses the term MIP-years as a combined measure of time and equipment (based on a megahertz machine operating for a year). In his tables from 1995 he is assuming computing power will double every 18 months and implies the factoring time is halved. He also includes cost of the computer as a factor. Using the $1,000 price criteria and the 2000 year figure of < 0.2 MIP-years or 1,750 hours we can project to today’s time needed, about 18 hours on a single core machine similar to those in use at the time of his writing. Even using a quad-core we are at 4 hours. This assumes no improvement in the number sieve algorithm, factoring algorithm, which has definitely improved over the last 15 years. It also omits a statistical analysis of collected data, reductions in time from knowing the random number generator process, or that the message structure is known and repetitive. It also assumes several of these factors are more or less linear.
Is a 4 hour frame useful? Probably not. My point is encryption and keys can be broken. The type of crack most likely would be ideal for a MITM, if diverting or spoofing the route was not so difficult. The RSA people point out in all their writing past and present the keys can be cracked. Key cracking is just a matter of time, resources, and will. That is why a 512-bit or 64 character keys are not considered overly secure, a real problem for wireless.
A more specific answer to how one would to do a MITM attack… Knowing the client side key and algorithm on both sides one could factor both the client and server in something less than the Robshaw estimates. That is a known and quantified possibility.
To reduce work required, one only need read the server code, login and receive a handshake packet from the Cyan server and go to work factoring the server side key. Eventually that 512 bit key will crack. I could be wrong about the time, but a week seems conservative. Once factored the MITM attack can start. Any new incoming connections rerouted by a DNS/router hijack can be spoofed using the cracked server side key. I think I have repeatedly shown MITM effort is unlikely and if mounted the encryption and key is not invincible thus I see a low value to encrypting game moves and chat.
What the rest of the world does seems a good predictor of the actual risks. In regard to whether encryption of game play and chat needs to be encrypted… The answer in SL and OpenSim has been no, encryption adds too much overhead. Only third party viewers for those worlds provide OTR chat (encrypted Off The Record chat) for those that feel they need to encrypt business discussions. The cost of encryption is carried only by those needing it. The servers are not loaded with the task.
WoW and GW seem to have built in communication and logon encryption. Both fan groups have people talking about breaking the encryption in 1 to 2 months, logon and chat. I won’t link to it but I can get you a WoW password stealer…