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' » Thu Jun 03, 2010 6:55 pm

:shock:

:lol: :lol: :lol:

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

Re: Public-Private Keys (WireShark)

Post by Nalates » Fri Jun 04, 2010 4:37 pm

I’ll take your laughter as conceding the point and a lack of knowledge about the weaknesses in Diffie-Hellman, even while the weakness is alluded to in Christian’s reference. While I was surprised that you chose to use the greatest weakness in Diffie-Hellman system to illustrate the strength of the system, I did avoid laughing at, insulting, or making fun of you.

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. Encryption has many uses and does provide security when used correctly. But it has a computational cost and weaknesses. Specifically in regard to MOULa your use of MITM:
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)
Another article points out the D-H related weaknesses in RSA encryption and how D-H is more vulnerable. (Reference)

Current cracking of fast (synonymous w/simple) 128 bit key systems is no longer uncommon. (Reference) While the linked references are typically passive key cracks the methods of accumulating packets to implement reduce factoring effort is common.

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.

While most of the math is in the initial exchange there is a significant ongoing computational cost. For speed smaller keys are used. Prime numbers are used for better security. With small keys the number of primes is reduced and factoring shortcuts are possible. When primes are not used other vulnerabilities open up reducing a crackers challenge. With quad core 5 processors and the ability to use GPU in new graphics cards for math; factoring time is reduced.

Knowing that secure key calc’s are time consuming (Reference) at this level I wondered what MOULa is using and how much overhead it was adding. In 2003 128 key was apparently still a big deal. After all, heavy SSL users were/are using dedicated SSL accelerators to reduce their server load. (Reference) If MOULa uses a small key for speed and obfuscation, I don’t see that as ‘real’ security for MOULa. (Adequate is another matter.) 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?

While several of you want to keep the current encryption in MOULa I am skeptical that it is providing the benefits you seem to be expecting. Whether it should be kept or removed at some future point is not decidable at this point. Would the effort to remove it and use it only for login and vault provide enough speed up to justify the work? We apparently do not know.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah

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

Re: Public-Private Keys (WireShark)

Post by a'moaca' » Fri Jun 04, 2010 7:29 pm

Nalates wrote:Ill take your laughter as conceding the point and a lack of knowledge about the weaknesses in Diffie-Hellman
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.

In any case, people who have a good understanding of how network encryption systems work and what security they provide will probably understand what I found funny.
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.
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:(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.
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).

Now you seem to be advocating replacing the D-H exchange (and they are actually using only half of D-H) with something more secure. This is a long way from ripping it out entirely. Or are you saying that because the cryptosystem could be better we might as well have none?
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?
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.

Now, if you were advocating removing the encryption of files stored on my hard drive, where the sole purpose is indeed obfuscation, I'd completely agree.

But no worries. I will not use your server when you turn off everything protecting me, problem solved. There isn't actually anything to debate -- people who understand the value of encryption won't turn it off and people who don't will, to get all those extra frames. We all get our way.

- a'moaca'

Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

Re: Public-Private Keys (WireShark)

Post by Christian Walther » Fri Jun 04, 2010 8:46 pm

a'moaca', good point about the Python download – I hadn’t thought of that.
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.
How so? You don’t have the private key or the session key.
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.
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: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.
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: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.
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:I suspect the present encryption […] engenders a false sense of security.
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.

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

Re: Public-Private Keys (WireShark)

Post by Nalates » Sun Jun 06, 2010 11:14 pm

Christian wrote:How so? You don’t have the private key or the session key.
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.

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.
Christian wrote:Are we talking about encryption here, or are we talking about vault security?

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. Is it serving a worthwhile purpose to continue using encryption for the entire data stream?

The idea that chat in MOULa is more secure with encryption doesn’t seem to fit with the scenario as I understand it. The encryption does add security for packets crossing the net. But, does that matter when one can tell the client to listen to all the conversation coming from the server while logged in? The server may be doing the work to send chat to only the people that need to hear it. Not having dug into MOULa I don’t know. 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.

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.
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 assume you mean the MOULa code, I may when it is published. MITM was used after D-H was brought up as a reason to encrypt. It has weaknesses. I quoted the section pointing that out and that those can be mitigated. I did not intend to imply MOULa had not implemented them. I did not claim that would work for MOULa MITM attacks. While the conversation is a bit fuzzy at that point, I was claiming D-H has susceptiblity to it, as is shown in the Wikipedia article you quote and the Baker paper I quote. There is nothing your quote of my writing that is not fact. But, asking the question I asked about the worth of the encryption process in MOULa shouldn’t really require reading the code. If I wanted to do the analysis myself I would have. I thought someone would already know. Telling me to stop challenging what I’m told and go read the code just sounds a bit rude.
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 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.

My experience is encryption does very little until the keys are good sized and then there is performance hit. I’ve also learned there are many ways to avoid having to crack the encryption because people rely on it and leave other doors open, in which case it is obfuscating to both sides for little reason.

Mostly I’ve learned to never trust a tech that tells me all will be ok because I just don’t know what I’m talking about. So, I push them to the point of frustration to find out what they do know. For instance you don’t know the key strength but you haven’t even mentioned key size used in MOULa. You imply a lot is known about MOULa and how it does things. I can believe that. We will know even more when the code is published. I suspect with that additional information we’ll be able to do all sorts of things that will make folks happy and unhappy and surprise them too, think OHBot. I suspect encryption will have little, if anything, to do with that.

Also, you haven’t actually tested the keys and performance yet. So, whether MOULa encryption is only for obfuscation or is a real security measure and 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. Regardless of how little or much I know my original question of whether MOULa encryption is worth it, will serve a purpose, seems to remain unanswered beyond the comments that some think it is a good idea. The idea of knowing which server one is connected to… I still haven’t seen one answer if that is a real concern. So, I still question the reasons given for continuing to encrypt, other than it is easier than removing it, which while a practical reason doesn’t really answer the question.
Nalates
GoW, GoMa and GoA apprentice - Guildmaster GoC - SL = Nalates Urriah

User avatar
Mac_Fife
Member
Posts: 1227
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Public-Private Keys (WireShark)

Post by Mac_Fife » Wed Jun 09, 2010 5:53 pm

I don't profess to be an expert in network security, or even particularly knowledgable on the subject (I do deal with Protectively Marked matter on a routine basis and have learned that security is best left to security experts ;) ), so I'm inclined to turn the question around:

Given that it seems to be a no-brainer that leaving the encryption in place is less "work" than stripping it out and setting aside any question of the efficacy of the encryption, what is expected to be gained by removing the encryption?

I'm one of those people who persists in running MOUL on a low spec. machine: It's fundamentally the same beast I used during GameTap and it was "old hat" then - Athlon XP2000+ (1.67GHz), 1.5GB RAM, Win XP, nVidia GeForce 6200 (256MB). That's still quite a bit above the Uru/MOUL minimum spec. of 800MHz PIII and MOUL runs perfectly OK for me. I know a bit more horsepower will give me a little less lag, and that might be nice, but it's perfectly playable as is. The point being that I don't see a driving need for recovering the CPU cycles used by the encryption.
Last edited by Mac_Fife on Wed Jun 09, 2010 5:57 pm, edited 1 time in total.
Reason: Fix typo
Mac_Fife
OpenUru.org wiki wrangler

User avatar
Mac_Fife
Member
Posts: 1227
Joined: Fri Dec 19, 2008 12:38 am
Location: Scotland
Contact:

Re: Public-Private Keys (WireShark)

Post by Mac_Fife » Thu Jun 10, 2010 9:14 pm

As something of an aside, I've just been sent my copy of the 2010 IEEE Awards Program and I see that Whitfield Diffie, Martin Hellman and Ralph Merkle have been awarded the Richard W. Hamming medal "For the invention of public key cryptography and its application to secure communications".
Mac_Fife
OpenUru.org wiki wrangler

Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

Re: Public-Private Keys (WireShark)

Post by Christian Walther » Sat Jun 12, 2010 1:35 pm

Nice find, Mac! :)

Dealing with Nalates requires a bit more space… :shock: I’ll try to keep it shorter next time!
Nalates wrote:
Christian wrote:How so? You don’t have the private key or the session key.
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.

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.
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: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.
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: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.
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: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.
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:I assume you mean the MOULa code, I may when it is published.
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:There is nothing your quote of my writing that is not fact.
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:But, asking the question I asked about the worth of the encryption process in MOULa shouldn’t really require reading the code.
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:So, I push them to the point of frustration to find out what they do know.
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:For instance you don’t know the key strength but you haven’t even mentioned key size used in MOULa.
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: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
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:The idea of knowing which server one is connected to… I still haven’t seen one answer if that is a real concern.
a'moaca' gave an answer:
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.
“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”.


Wait, let’s try an experiment. Let’s forget that I ever mentioned the term “Diffie-Hellman”. That over-simplified statement was a mistake, seeing as it led you completely astray. Instead of trying to put a label on it, I’ll just tell you what the software actually does, according to my understanding (client side from libHSPlasmaNet, server side inferred). Plasma experts (if any are still reading), correct me if I’m wrong. This is specifically for the gatekeeper connection, the others use different bases but otherwise do the same thing.

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.
If you think this is vulnerable to a man-in-the-middle attack or otherwise insecure, please explain how. I can’t prove that it isn’t, but I tend to believe the cryptography experts when they say that computing discrete logarithms is conjectured to be hard, so “compute log4(X) mod N to recover the private key” doesn’t count. (By the way, you have used the word “factoring” a few times, can you explain how factoring is useful here? I’m not familiar enough with the matter to know whether it is or not, but I think you may be confusing this with RSA, where factoring is the conjectured-to-be-hard problem the system is based on.)

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

Re: Public-Private Keys (WireShark)

Post by a'moaca' » Sat Jun 12, 2010 7:34 pm

It is a basic network security 101 kind of thing to understand the difference between authentication and encryption and what each does for you. Plain D-H used alone is vulnerable to MITM attacks because it has no authentication. The attacker negotiates two perfectly valid keys undetected because Alice and Bob are not authenticated. D-H is a key exchange algorithm, not an authentication algorithm. To be secure it must be combined with authentication.

The modified form of D-H described accurately by Christian has different properties than plain D-H. The fact that the server's random number a is precomputed and g^a is in the client means that an attacker cannot substitute his own a. g^a is not transmitted for him to replace. Any attempts at substitution would result in garbage upon decryption with the wrong key. This provides a form of authentication that is not present in ordinary D-H. If client receives valid non-garbage data from the server after the connection encryption has started, then the server is authenticated to the client. (There is no authentication of the client to the server. Your username/password is authentication of you. The client is not authenticated.) Whether this authentication could be better or not is another conversation, but there IS authentication here.

This means that the key exchange used by the MOUL protocol is protected from MITM on the encryption so long as the private key remains confidential. So it is better than D-H already in the same exact way that using RSA instead would have been better than D-H. I also avoided giving out the key size in hopes that wanting to know would engender thought, but it will be interesting to see the argument about why 512 bits is not enough any more. Because really, my life would be a lot more convenient if you would go through that trivial exercise of working out the private key. Additionally, as Christian pointed out, it is utterly not a factoring problem but the discrete logarithm problem.

As this is a public/private key system kind of like RSA, this is really not true:
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.
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.

I also wish to point out to careful readers that a MITM attack on the Python is not at all the same thing as a MITM attack on D-H. Even if MOUL used plain D-H it would be said that D-H is protecting you (via the key it negotiates) from a MITM attack on the Python. Then you would need authentication to protect you from a MITM attack on the D-H. The ISO layer model for network communications is imperfect but a good way to think about things like this: the Python download is at a higher layer than the encryption, thus encryption protects the Python but you still need something else to protect the encryption from attacks on it.

Finally, regarding using a CCR/modified client to snoop on people, Nalates asks:
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?
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.

The server does NOT broadcast everything. It only broadcasts what needs to be broadcast to maintain a consistent view of the world. Your avatar movements are broadcast (setting aside technical points like relevance regions) within the age for that reason. When you use /shout it is broadcast because that is what shout is defined to do. If you send a private message, or even talk without shouting, that goes to specific recipients only. If you send a KI image to someone, that information is not broadcast. If you link around, the fact your avatar is in a new place is known only to those who have you on their list. There are indeed ways to subscribe to vault-related changes with a modified client, which must be fixed server-side and this is unrelated to the network encryption. But there is no stupid broadcasting going on. Do not forget that the original protocol design was done by people who believed it would work on dialup. Broadcasting and filtering client side is a design done by people who believe they have huge bandwidth.

And you can't say "we don't really know" because I do know. I wrote the Wireshark plugin you are unable to use. I believe I have spent more time looking at the reality of Uru network traffic than anyone else on the planet, and it is not broadcasting things it shouldn't. There are weird bugs, but it's not leaking data it shouldn't.

- a'moaca'

Christian Walther
Member
Posts: 294
Joined: Sat Dec 13, 2008 10:54 am

Re: Public-Private Keys (WireShark)

Post by Christian Walther » Sat Jun 12, 2010 10:08 pm

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… :)

Post Reply

Return to “Wireshark Plugin For Uru Client Protocol”

Who is online

Users browsing this forum: No registered users and 1 guest