Alternative to sniffing?

[cryptorad]

Well.. I mention for three reasons.

First.. the information I have says that 'several private keys will decrypt messages for a given public key' for most implementations. This reduces the key space by a factor and helps in the required break time.

Second.. there is always a chance you will recover the key earlier then the time it takes to test all possibilities. IE.. 8 percent chance at the 8 percent tested point. For a truly random key.

Third.. I can imagine it is possible to implement a feature of ShowEQ that provided a zone packet for analysis to multiple processors that fed back a yes/no answer only for brute testing of a keyed packet. Of course.. providing the information with the successful 'yes' would be the key to being useful. And if the time frame was significantly below the reboot/recycle time that was acceptable by Verant, then it could be useful. Since they don't want to spawn TOO many Tormax's.. etc.


However.. if I am learning as I go along here.. then I think I now understand the process to be a Public/Private key pair strictly to encrypt a session (symmetrical) key which is what is USED for the communication between server and client. A key encrypted key, so to speak. This would prevent an easy recognition of the correctly decrypted key and invalidate my above point.

There are still ways to attack the above key encrypted key method.. but; the ones I am aware of are hardly considered passive.

[high_jeeves]

Who was it again that had the numbers for how long it took to break DES-56? 4 years? So, even with all of us crunching away on the key (WAY fewer users than were crunching away at a well known algorithm), it took years. And, if we find it, it will take them exactly 1 second to change their keypair...

Also, PLEASE UNDERSTAND WHAT YOU ARE TALKING ABOUT BEFORE YOU STATE FACTS.

The client DOES NOT generate the private key. It generates the shared key. These are totally different things. Please state the facts correctly.

As for the 'seed', it is generated for a fairly high entropy source (as has been mentioned in atleast 20 others threads here on this board). Predictive guessing of the key cannot be done in an even remotely accurate fasion, and even if it could, it would require a MUCH more invasive application than the keysniffers that exist now.

As for any sort of man in the middle attack (modifying entropy, or the key exchange...), they would be able to detect this in a heartbeat without any invasive attacks, and you would be banned.

Also, please read up on the forums, all of these ideas have been discussed atleast 2 or 3 times before on this forum, there is no need to rehash them.

--Jeeves

[cryptorad]

Actually.. the numbers are....

Processors required for DES 56 break...

# encrypt/sec 1yr 1mo 1wk 1dy

1mill 2,300 28,000 120,000 830,000

2mill 1,100 14,000 60,000 420,000

4mill 570 7,000 30,000 210,000

32mill 71 870 3,700 26,000

256mill 9 100 470 3,300



I can't format it pretty but, I already had this data.

[deathinc]

Originally posted by LordCrush


from *what* brute force ? the private key is *private* and not included in anything on the wire and cannot be reproduced from the public key - thats because its called *a*symetric encryption

Pick your comment:

Please leave your high horse at the door...
-or-
No shit Sherlock.

Simple mathematics... For each public key, there exists only one private key, that cannot be deduced from the public key, but that can, however, be tested mathematically with a known cyphertext/cleartext pair.

I asked about the number of times that private/public key *pair* changes... Simply put, I was just curious to know if that keypair is semi-static or completely regenerated upon zone/reboot/patch.

In other words, did VI cover _all_ their bases, no matter how impractical they are to break.

If you want to flame me, at least read the fucking message first.

[MisterSpock]

Death,

One minor point. For each public key, there *should* only be one private key. This is not always the case, however. Various mathematical weak spots will occasionally crop up in asymmetric encryption techniques that lead to key pairs that are weak (produce very little effective encrytion), or that are non-unique (>1 private key works with a given public key).

On most published algorithms, great scrutiny is given to these issues. Testing and debate takes place that often leads to adjustments to the algorithm or the implementation. Many times private algorithms, who's inner workings never see the light of day, lack this "massively parallel cryptanalysis." That doesn't necessarily mean they are weak, it just means they might have weaknesses that a limited design team didn't catch. To some extent, VI's encryption method fell in to this case. Security through obsurity is not security.

Have I given up totally on the idea of passive SEQ? Well, not exactly. I rarely ever totally give up. There are things we do know, and many we do not.
We know or can learn:
* The public key sent from a given zone server
* The algorithm that uses the public key to encrypt the session key
* The session key itself (through keysniffing)
* The algorithm used to decrypt the encrypted packets if you have a valid session key.

We do not know:
* The server's private key (duh -- that's why it is called private)
* How often this key is changed
* The exact decryption method used on the server side
* The true mathematical strength of the algorithm

The challenge is in connecting the two parts together. I think we've safely determined (beyond any doubt) that simply brute-forcing things is not feasible. If it is to be done, it must be done through other means.


At the same time, though, I think there are still some things that could be done to the GPS-mode SEQ. One that I have considered is the ability to manually color and name a spawn. Right-click on the appropriate dot on the screen, manually enter a con color and/or a name. When I get some time, I might look in to the possibility of this programmatically. Right now, I'm still fiddling with the keysniffer side of things.

[supersat]

Although this approach would be difficult to pull off and would require a system to be placed in between your EQ computer and your 'net connection, it seems like it'd be possible to intercept the symmetric key without Verant being able to detect it at all.

Here's how it works:

1. An app intercepts the zone server packet that contains the public key, records that public key, and sends out a new packet to the client with your own public key.

2. The client encrypts the symmetric key with your public key and sends it to the zone server.

3. The app intercepts the encypted symmetric key sent by the client and decrypts it with its own private key.

4. The app re-encrypts the symmetric key with the public key originally sent by the zone server and sends it to the zone server.

Thoughts on this approach?

[perlmonkey]

Ok, there are two topics in your message. I'm going to take the second one first.

I've seen that seq has access to conning information (e.g. the text sent back when I con something and the spawn ID of the mob I'm conning). So, would it not be possible to color mobs when I con them? Also, since the con message comes back with the mob's name, that too could be added to the spawn information, no?

It's perhaps not ideal, but it at least gives you an idea of what mobs you HAVEN'T conned yet, and that's useful info.

There are various other tricks that could be applied heuristically rather than algorithmically. For example, if you see that a spawn only ever moves at walk-speed rather than run speed, that increases the chance of its being an NPC. If you see a spawn appear at a zone boundary, it's probably a PC.

Ok TOPIC TWO: GETTING THE KEY

It's come to my attention that WineX now runs EQ pretty well. Windows is annoying enough to me in the first place that I'd love to be running Linux on my desktop at home, and will probably play EQ through WineX if it works well.

Given that I have source for WineX, I should be able to modify it to act as my key ripper and save the key to an NFS partition for later access by second machine that's running seq. Even better, I could just run EQ in a Wine window and run seq on the same box. EQ has no hope of ever knowing that I'm doing more than running it under WineX, and even that is not trivial or terribly reliable.

Thoughts?

[sam]

It wouldn't be very good encryption if it didnt' at least check if what you are sending back is what it was expecting.

I think the server generates its public key using its private key so that when your client generates its symmetric key and sends it back, its in a format that the server should be able to check on using its private key. Since they keep their private key private, I dont see how this one could work.

If for some reason they are not doing enough key checks along the way, then this could work... they cant be using a very good key system since half the time the first 8 bytes of their keys come out f's. So maybe if its a home grown key system they would be stupid enough to have overlooked this but that doesn't mean they would continue to overlook this in the future and could actually scan for people using this method in the future.

[sam]

Originally posted by perlmonkey
It's come to my attention that WineX now runs EQ pretty well.

Yes, EQ works under wine now but its still not to the level that most will be wanting to swap out their windows boxes for linux. Also, just running eq with wine is like saying, "Hey Verant, I dare you to ban my account!!"

If verant gets pissy about people using little things like macro programs... just think how they'll be pissin after they learn you are running under linux. I would have to say 99% of the home *nix users out there that play EQ also use SEQ, and I bet Verant is thinking the same.

There is a guy in my guild who has been boasting how he runs in linux with winex and I think he's a complete moron because he's taunting verant.

[deathinc]

Originally posted by MisterSpock
Death,

One minor point. For each public key, there *should* only be one private key. This is not always the case, however. Various mathematical weak spots will occasionally crop up in asymmetric encryption techniques that lead to key pairs that are weak (produce very little effective encrytion), or that are non-unique (>1 private key works with a given public key).

On most published algorithms, great scrutiny is given to these issues. ...

I debated the wording on that section of the post. I decided to go with the wording above for one simple reason. VI/SOE programmers aren't complete idiots. I would ASSuME that they used a reasonably reviewed protocol, that they check for weak keys, and adequately test their prime numbers.

While it is technically possible to have >1 key for any given side of a key pair, it is certanly not common, and basing any expectation of weakness on such a theoritical possibility would be unwise.

But yes, you are correct, it is possible, however exceptionally unlikely given a remotely clueful programmer using a relatively common PKI algorithim.

Again, I ask simply to provide a broader view of VI/SOE's encryption decisions. the ole pull 1 thread and, hopefully, watch the blanket unravel....

(Edit - Typos Suck)

[baelang]

Originally posted by sam
I think the server generates its public key using its private key so that when your client generates its symmetric key and sends it back, its in a format that the server should be able to check on using its private key. Since they keep their private key private, I dont see how this one could work.

If for some reason they are not doing enough key checks along the way, then this could work... they cant be using a very good key system since half the time the first 8 bytes of their keys come out f's. So maybe if its a home grown key system they would be stupid enough to have overlooked this but that doesn't mean they would continue to overlook this in the future and could actually scan for people using this method in the future.

first of all, a public key isn't generated from a private key. a public key and private key are generated TOGETHER at the same time. they are two halves of a whole, two prime factors of some very large number. showeq has never tampered with the pki key exchange. that was always secure.

the symetric key is were the weakness was. the symetric key is still weaker that it could be, as evidenced by the fact that most keys are really only 32 bits padded with f. however, even a 32 bit symetric key is strong enough to resist brute force attacks practical time frames. (perhaps we can do it in an hour or two. but what good is decryption an hour after you zone?)

before the big patch, we could break the symetric key because we could predict parts of the cleartext of some packets. Now, the packets are compressed so there is no way to predict the cleartext, so no fast breaking of the symetric key.

[deathinc]

Random thought... as I didn't see it mentioned on the other threads...

Is there any chance the compression routiene may give us an edge by not adequately compressing something, or by creating a predictable pattern?

[high_jeeves]

as I didn't see it mentioned on the other threads...

Look again, its covered more than once...

--Jeeves

[sam]

Originally posted by baelang
Now, the packets are compressed so there is no way to predict the cleartext, so no fast breaking of the symetric key.

From what I have read, the packets are compressed and its hard to uncompress them because we dont know where the compression starts and stops... is this correct? If it is, then what are the chances we may figure that out eventually?

[sam]

Originally posted by high_jeeves
Look again, its covered more than once...

I swear you are the forum nazzi... its like you sit around and do searches on everything and then yell at people who havn't spent a few days doing a search for single post buried down in the darkest spot of the forums.

When I search for something, I give it about 2 or 3 tries and if I havn't found it by then then most others probably wont, so I post my question.

NO POST FOR JOO!!