Public-Private Keys (WireShark)

Wireshark Plugin For Uru Client Protocol

Moderator: Wireshark Plugin Managers

a'moaca'
Member
Posts: 163
Joined: Sat Dec 13, 2008 11:22 pm

Re: Public-Private Keys (WireShark)

Post by a'moaca' »

Christian Walther wrote:Good explanation, a'moaca', thanks!

While I have your attention, do you know what the purpose of the extra 7 bytes I called “d” is that are xored to the negotiated key? I could perhaps work it out by thinking about it hard enough, but asking is quicker… :)
Hmm? The negotiated key is the result of the xor. d is just random.

I assume the question is why we bother xoring d instead of just using c as the RC4 key. I do not know what Cyan really had in mind, but the effect of d is to prevent replay attacks. Without both sides of the key exchange contributing to the final key, your system is vulnerable to replay attacks. Without the "d" step, I can snoop your traffic and even though I can't modify it, I can replay it, as you of course, since your password is encrypted into the stream. Admittedly it would be a bit weird to replay a whole Uru session, and the encryption would go wonky if your vault had changed, but that's a higher-layer concern than making sure your system isn't vulnerable to the attack itself.

- a'moaca'
User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Public-Private Keys (WireShark)

Post by Nalates »

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…
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
Christian Walther
Member
Posts: 317
Joined: Sat Dec 13, 2008 10:54 am

Re: Public-Private Keys (WireShark)

Post by Christian Walther »

a'moaca' wrote:I do not know what Cyan really had in mind, but the effect of d is to prevent replay attacks.
Right, that’s the conclusion I have arrived at as well in the meantime. (Isn’t it interesting how asking a question spurs one’s own thinking about it?) I haven’t come up with an example of how a replay would be of practical use to an attacker yet, but it certainly can’t hurt to prevent it. In the case of the auth connection, in addition, the replay would stop at the login authentication, since there’s another server nonce involved there.


Nalates, I won’t answer point-by-point this time, that would take far too much time and I have no indication that it would take us any further. You insist that your questions haven’t been answered, I think we have answered them as well as we can, rephrasing our answers once more is unlikely to help. Just a few of the more important comments:
  • I again can’t make any sense of several of your statements. I don’t know if that’s due to unclear writing or thinking on your part or due to ineptitude on my part.
  • I do not think encryption is invincible. Any practical encryption can be broken by brute force, which is why this is not an interesting question and is left aside. I’m talking about attacks apart from brute force. I am not really interested in how much time it takes to crack MOULa keys by brute force. If it turns out it takes too little time, you just up the key size. That is not an interesting problem. (That doesn’t mean it’s irrelevant, of course, it will have to be considered in any serious security assessment, I just see no contribution to an interesting discussion here in it.)
  • You still seem to mix up the two unrelated kinds of man-in-the-middle attacks that have been mentioned in this thread: The one possible on a classical D-H key exchange (which I believe is irrelevant in our context since Uru does not use classical D-H, a belief that you seem to continue to disagree with but have not shown proof), and the one that would be possible on the Python download to inject malicious code if there were no encryption and server authentication (which is successfully prevented by the current presence of encryption and authentication).
  • I did not expand on the question of the probability of attacks because I don’t know and on whether privacy is an important concern in Uru because that is a matter of opinion, with my opinion being that while it’s probably not important, it’s still a desirable thing and if it comes at little additional cost we might as well have it.
  • All your talk about RSA and factoring is irrelevant since there is no RSA involved.
  • Regarding step-by-step instructions, you continue to cite references but don’t show how they apply to the situation at hand. Until you do, I’ll stick to my understanding that they do not. Reasons have been detailed in a'moaca's next-to-last post.
  • Regarding “light weight SSL”, we’re back at the topic that you seem to assume that what Uru does is somehow non-light-weight, while I see no reason for such an assumption.
  • Regarding “Code please”, I’m unsure what kind of code you refer to. Assuming you mean server and client code with network encryption removed, I don’t think anyone is asking “code please” because we see no reason why we would want to use your code. Assuming you mean code that does a man-in-the-middle attack on the key exchange, yes, I am asking “code please” because until someone shows it to me I don’t believe that such code exists (again, apart from brute-force cracking the private key, which is always possible and thus not interesting).
  • If the goal is to identify possible attack scenarios, a question to be considered would be whether the RC4 might be an easier target than the key exchange.
a'moaca'
Member
Posts: 163
Joined: Sat Dec 13, 2008 11:22 pm

Re: Public-Private Keys (WireShark)

Post by a'moaca' »

Christian Walther wrote:In the case of the auth connection, in addition, the replay would stop at the login authentication, since there’s another server nonce involved there.
Ah, yes, I had forgotten that. In GameTap MOUL that nonce wasn't used! You're right; the current state of affairs is better.


I also have much better things to do in my life than to attempt to correct all the technical errors in Nalates' posts. At no time when she says "we" something, do I agree. I am emphatically not a part of whatever "we" she refers to. The most egregious example:
Nalates wrote: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.
There is no agreement. In particular, the server is not shotgunning the chat, and we do know. Or at least, I do. Nalates, however, appears to continue to not know, despite the fact I explicitly mentioned why she cannot say we don't know.

My observation is that this is the general pattern of attempts at technical conversations with Nalates. I do not intend to continue this useless "discussion". The reason you drive your techs to frustration is quite clear: if you treat them at all like you treat us, they are frustrated because you refuse to listen to their answers if they do not agree with what you wanted to hear. I feel for them, and I figure they must be paid very well, because I would find a better job and move on.

Fortunately you appear to do this to everyone so I am not taking it personally, but obviously my time on this thread would be past useless from now on.

- a'moaca'

P.S.: The RC4 key is clearly the easiest attack vector.
User avatar
Mac_Fife
Member
Posts: 1239
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Public-Private Keys (WireShark)

Post by Mac_Fife »

Nalates wrote: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.
OK, this is a bit of a digression, but since the OP is mentioned: I don't quite follow why Wireshark is mentioned in the thread title, as really we're just talking about the Uru protocols, and Wireshark is completely irrelevant to any of the discussion here, other than the occasional reference to a'moaca's plug-in.
Nalates wrote:a'moaca' uses the word ‘encryption’ for server identification when I think he means a key exchange [...]
No, I don't think that's a mistake, since I think this thread has established that Uru uses a pre-shared key therefore the conventional D-H key exchange doesn't actually take place. At least, not in my reading of things. This is what makes a lot of the debate over the potential vulnerabilities to MITM attacks seem somewhat irrelevant to me. In any case, what I do know is that a'moaca' probably knows more about Uru networking than anyone outside (and maybe even inside) Cyan (well, she and cjkelly1), and she is highly trusted by Cyan. I'll take her opinion over anyone else's in these kind of matters. Blind trust? Maybe, but with justification.
Nalates wrote: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.
Sure. There's a fairly recent article in one of the IEEE journals (I don't have it handy to cite as it's probably lying in my office) which walked through the practical process of breaking into a typical wireless network from scratch using some readily available sofware and a typical laptop. This relied on the supplementary statistical methods referenced later in Nalates post. The problem the author encountered was that in a typical domestic wireless network there is an insufficient volume of traffic created to provide the necessary statistics in less than 24-48 hours (I may have the numbers wrong but it was that kind of timeframe).

But I don't think anyone is claiming that encryption, and especially that used in Uru, can't be broken. The bigger question for me is in the quote above - "is it worth it?" I suspect, but don't know, that the encrypted data exchange may have served a purpose in validating the server and that was possibly originally part of a scheme to deter people from setting up their own servers to avoid paying Ubi subscriptions. Anyway, to me, breaking the Uru encryption doesn't generally seem "worth it", so the corollary is that the encryption is "worth it", because no matter how limited the protection it offers may be, it does something. In a previous post I got things the wrong way round, by suggesting that the encryption offered a means to validate the client to the server, while in fact it validates the server to the client. But the priciple of the example I gave still stands, I think, so I'll have another go at it:
Let's say a branch of Open Source Uru develops a Ki enhancement feature for multiple buddy lists (like the "Parties" that were mentioned in the Ki Overhaul suggestion thread). This means the vault has to store some additional elements not present in other branches, meaning that the client and server need to be married. So you change the server and client keys to give you a verification that the client "matches" the server. Or is my penchant for simplifying things taking me down a wrong path?
Mac_Fife
OpenUru.org wiki wrangler
User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Public-Private Keys (WireShark)

Post by Nalates »

Christian wrote:I again can’t make any sense of several of your statements.
You can assume it’s my writing. I generally think it is a loss of context in each individuals thinking. Whatever, thanks for taking the time to think about it.
Christian wrote:Any practical encryption can be broken by brute force, which is why this is not an interesting question and is left aside. […] you just up the key size.

Well, that was the point… if the key is small and the system is fast is it worth the cycles and is it really secure or just false sense of security, especially if there are other ways to get to the chat and game play? If security is outdated and a bigger key is needed then what does that bigger key add to the overhead? Your answer appears to be you think it worthwhile, which is opinion and ok. It’s an answer of sorts, it’s just an answer that doesn’t go beyond opinion.

If one thinks of their forum, blog, email, cell phone, and other basic communications people use daily for conversation, which I assume have greater significance than anything going through MOULa, and the massive majority of those are not protected by encryption, even for logon in many cases, one has to wonder why we are spending CPU cycles encrypting a no-economy game logon and chat?

Also, to assume that one can just plug in a larger key and start doing math with huge numbers brings up a whole other set of questions. Since it appears MOULa uses OpenSSL it can handle larger keys. Performance however remains a question. Also the use of software that can handle large keys brings up the issue of import/export restrictions.
Christian wrote:You still seem to mix up the two unrelated kinds of man-in-the-middle attacks […]
I may. But, it is so hard to get in the middle of a network stream whether one is trying to intercept initial negotiations or ongoing communications it seems to make little difference the probability of an attack.
Since neither you, Christian, or a'moaca' seem to have hard information on the probability of a MITM attack, which would provide a basis for deciding whether it’s worth it to protect against, I looked it up. Hijacking network streams using Autonomous System advertisements had apparently never been quantified until Ballani, Francis, and Zhang of Cornell University looked at it in 2007. Fake AS ads are about the easiest way to get in the middle. If one can successfully fake being a tier 1 router something like 75% of the routes around the router can be hijacked and forwarded, creating a MITM. As that drops to tier 3 routers only 13% or so can be hijacked. Empirical data suggested that 50+% of routes could be hijacked in 2007 via an AS attack. The Cornell paper “A Study of Prefix Hijacking and Interception in the Internet” points out many of the problems in such attacks that reduce the probability of success. Their detection processes did not find any evidence of actual attacks, which while not ‘proof’ does indicate a very low probability. So, while they could quantify the possibility they did not quantify the probability. The lack of hard data made it unrealistic to put a number on probability. The work was partially funded by Intel and the purpose of the paper was to figure out if something actually needed to be done.

To make the point on possible vs probable, another paper “Honeybot…” points out another attack which is more devious and would be easier to run in MOULa and encryption and authentication won’t stop it, Automated Social Engineering. One has to consider how probable that is because the possibility is 100%.
Christian wrote: […] if it comes at little additional cost we might as well have it.

I agree. Since we have it, use it. I know that 90+% of the CPU cycles for encryption get spent in the initial handshakes and key negotiation for SSL/TLS. That up front effort is spent if encryption is used for any part of the process. The remaining effort to bulk encrypt the rest of the transferring data is then relatively cheap. But what percent that remaining 10% is of the whole game application server and client side remains unanswered.

Since you guys don’t know, as I dig through the white papers I see where more encryption related processes are being built into CPU’s and GPU’s are being commandeered to help out too. So, while the CPU cycle cost would increase the elapsed time could come way down… large keys would be practical to use.
Christian wrote:All your talk about RSA and factoring is irrelevant since there is no RSA involved.

Both RSA and whatever it is MOUL uses which no one seems to want to label, use asymmetric and symmetric key processing for negotiation and bulk encryption in their processes. So, I think the logic applies. That the equations are slightly different does not make any of them impervious.

OpenSSL is used in libhsplasma. I haven’t dug far enough to see which style authorization and encryption is used. I see RC4 and AES parts in use. I don’t see the client side key, yet. It appears the server is handing out the public key at connect time, which would make sense and is typical in several authentication algorithms. But, it may be the key is built into the client.
Christian wrote:Regarding step-by-step instructions, you continue to cite references but don’t show how they apply to the situation at hand.

I’m looking through the code… But I’ll have to sort through it so I can see it and then write the interception in diagram form or we’ll continue in circles.
Christian wrote: […] that you seem to assume that what Uru does is somehow non-light-weight, […]

No you are making a bad assumption about my thinking. I did not assume MOUL was light weight, actually the opposite, which is why I was initially asking the cost of the encryption. However my use of light-weight and SSL together is apparently confusing. In web apps I think of SSL as light-weight because it makes little if any foot print on the web app code as the browser and web server handle it outside the apps code, which thinking is missing from what I wrote. A stand alone app, like MOULa, running outside a browser/web server environment would have to include the SSL code, which I tend to think of as being there like air. No wonder you’re confused.

Code Please… No I was thinking meta-code for how a 3rd person sees the process.
Mac_Fife wrote:But I don't think anyone is claiming that encryption, and especially […] Anyway, to me, breaking the Uru encryption doesn't generally seem "worth it", so the corollary is that the encryption is "worth it", because no matter how limited the protection it offers may be, it does something.
My reason for asking the question is in regard to the ‘limited protection’ and the apparent lack of it doing much past login that appears worthwhile.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
User avatar
Nalates
Member
Posts: 437
Joined: Mon Dec 22, 2008 7:50 pm

Re: Public-Private Keys (WireShark)

Post by Nalates »

I’ve been looking through more of the issues with using security… as of 2006 there was still a problem with servers overloading from SSL processing. (Reference) The article points out the challenge of servers using SSL with several users, which points out another problem with using a SSL style handshake, which means a high computational load incurred and that SSL can be as a tool in mounting a DoS attack. The DoS attacks are 100% possible, script kiddy level, more common and much easier to mount and are therefore way more probable. Not that we have anyone in the community that would do that…

Additionally the MD5 and certificate authorities have been shown, 2009, to have a weakness that will allow a MITM to impersonate an authority and create a fake SSL type certificate. (Reference - Reference) Good practices can resolve the issue but the systems have known exploits, more on that below.

Also in 2009 it was shown users SSL sessions were being hijacked and that included 2-factor authentication token and third party certificate schemes. (Reference) The novelty of the attacks was finding ways to circumvent all the security and steal or fake keys and avoid having to crunch the math to retrieve the real key.
A more pertinent penetration involving OpenSSL is: New Tricks for Defeating SSL

Not having needed to use SSL/TLS libraries I did not know that benchmarking is built into the library. One can use the built-in functions to do quick comparisons on any machine. (Reference)

MITM Interception for MOULa
I started writing the math and flow for hacking a MOULa type two key system with one key and both algorithms known. Then I came across a link into YouTube, which I had not thought of as a hacking resource reference, and gave it up as pointless as they make all this seem trivial.
http://www.youtube.com/watch?v=Aak6-B3JORE – 2008
Or for 2010:
Hacking Videos

It is easier to get in the middle of the network routes around a location than I thought. But, one is still pretty restricted as to how many routes one can intercept until they can capture a tier 1 router. As the previously quoted paper shows, even then one has limits.

http://www.youtube.com/watch?v=XHSO8-zTNeA – 2010
As you can see there are ready made tools for the interception process. There are other tools for grinding on a private keys. Once the grind is complete the MITM for MOULa spoof is no more difficult than any other certificate spoof. The spoof’er then has both keys.

To put your earlier question on specific math in perspective…

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.

In this series of exchanges quoted here, both the server and client have to independently come up with ‘C’. Since N and D are known client side, by any one, as is the algorithm; the number of possible combinations is reduced by about 90%, which quantifies why the addition of open source may negate much of the reason for encryption outside the authenticating process. While still having to deal with a quadrillion (72,057,594,037,927,936 – 17 digit) possible combinations sounds reassuring, the algorithms and even packaged programs that I’m finding to deal with the something like a quinquagintillion (label for a 155 digit number) possibilities and to walk through 1k and 2k keys in near useful real time; spending CPU cycles on encryption seems even more wasteful.

To increase the key size provides some additional security and if increased enough does provide adequate security. The cost to double the key size from 512 to 1024 adds about 50% more processing in OpenSSL. As key size increases the percent-of-increase declines, so there is some key size and performance cost balance. However increased key size consumes more memory, CPU, and time.

One can get an idea of processing cost from OpenWrt for hardware using SSL/TLS and presumably optimized for big number math in the first reference. (Reference, Reference, Reference) The other references are more toward server and desktop performance. One problem with these numbers is not many include CPU usage while calculating. Also there is a multiplier for each user and the overhead and ram use is not quantified beyond single user cases, at least anywhere in a benchmark I can find. So, I don’t see encrypting all the data streams as trivial overhead and especially if key sizes are increased.

The idea that encryption makes chat more private than without is true. But there is a cost and cheap (CPU, time, performance-wise) encryption I see as false security. I don’t see the worth or need for chat and game play encryption.

As to avoiding black hat Python code… or other poisoned downloads… verification of the server ID and user ID are important. I suspect that CPU intense encryption and key exchange work will be done on the login server not the game server. Increased security there to keep up with the times seems reasonable.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah
Post Reply

Return to “Wireshark Plugin For Uru Client Protocol”