Gate Address are invertible

[somanayr]

Gate addresses are invertible and predictable. It looks like this is done for performance reasons, but it's also a security issue, since a player who knows your gate address can discover your location, even if you have an iris.

I put together a webapp to showcase the issue here: https://sgcraft-scanner-web.herokuapp.com/

A fix would be to encrypt the addresses with the world seed as the secret key. If you'd like, I'm happy to submit a PR for this.

[somanayr]

I've looked into this a little more. Format-preserving encryption, with a key derived from the world seed, appears to be the way to go. Of course, that assumes the world seed is secret.

Let me know if you want me to put this together.

[Nex4rius]

But this is exactly canon. In the series they could use the gate address to calculate the position of the planet/stargate .

[Dockter]

Having an iris prevents the security issue though so how is this an issue?

[somanayr]

Even with an iris, someone can approach by foot. Suppose you have a secret base with a Stargate. You are now vulnerable to two risks: 1) If you dial out, your address can be recorded by the destination gate. Likewise if you dial to your secret base, even if you are not followed through. 2) In a limited sized world, sequential dialing may be feasible. One could use ComputerCraft or similar to enumerate all possible gates over the course of a few days or weeks (since the search space can be reduced to the limited world). In a 20k square world, there are only 1.5m addresses. So if you test one gate per second, that's 18 days. Difficult but feasible. In either of these cases, your adversary learns your gate address, thereby revealing the physical address, and so can then approach by foot, bypassing any iris protections. In other words, the iris doesn't do much good if a gate address is enough to find your gate's location.

[Dockter]

Hm. Valid points. I would review PR to your suggestion of encoding it.

[Sarous]

I have personally written programs using computercraft to map all gate locations. While it is THEORETICALLY possible, it is impractical. At a dialing rate of one address per 30 seconds, it would take YEARS to map even a fraction of the addresses.

edit: Maths, there are 525,600 minutes in a year. At 2 addresses per minute, you can test 1,051,200 per year. There are a 3 quadrillion chunks (3,515,625,000,000) in a standard 30 million x 30 million block world. It would take 3,344,392 years to map every chunk at a dialing rate of 2 addresses per minute.

[somanayr]

Is it really 30 seconds per dial? As I recall, my initial tests seemed to be able to identify a failed dial very quickly, though I never timed it. A successful dial, of course, takes longer. It's been a few months since I was working on this, however, so my memory may be foggy. Either way, the first concern (spying on a traveler) does not require mass dialing.

[Nex4rius]

lol You don't need to dial to find out if a gate exists at an address.
You can check about 1 address per second with the energyToDial() function

[Sarous]

thats still a hundred thousand years.. (111,479)

[somanayr]

A 20,000 x 20,000 block search area has a 1,250 x 1,250 chunk grid, or 1,562,500 chunks. At 1 dial per second, this is 1,562,500 seconds (since the address is based on the chunk X and Z). With 86,400 seconds per day, this gives 18.08 days.

[Sarous]

Overworld is 30,000,000^2, not 20,000^2. Thus throwing off your figures.

[Dockter]

Thus hurting your case more not less.

[somanayr]

@Sarous yes, the whole overworld is that size. Many server operators choose to restrict world size for performance reasons. (I offered 20kx20k because that was restriction for the server I was playing on)

[Sarous]

I confess I went at my math incorrectly on one point. Instead of counting chunks, I should have counted addressable gates, which is 38^7 for intra-dimensional gates, or 38^9 for all gates. There are two primary ways to design such a dialing program.

Incremental dialing would lead to having to test the entire system, regardless of world size, necessitating all intradimentional gate addresses (114,415,582,592 addresses; 3,628 years of dailling at 1/second).

Selective dialing would require you to produce a list, via some method like the above app, which would lead to a dialing program in excess of 16mb. Last I knew, ComputerCraft has a maximum program size of 2mb, though there is no technical limit on the number of separate programs it can store.

Needless to say, this is an extreme amount of effort to put into a project to locate a single needle in a very large haystack. If it ever became a mainstream problem, it would also be easy to overcome by simply dismantling a gate when not in use, and using proxy-bases.

[Dockter]

So get started now is what you're saying...

[Nex4rius]

Or you make it easier and just code the address logic into your minecraft computer and it just converts the coords to addresses which means you don't have to store 16mb.

[somanayr]

Nexarius is correct -- you compute the addresses on-the-fly, or you can chunk the dialing list into multiple files. I agree that for a full-sized world, sequential dialing is not a concern. But that was never my claim. The claim is that for a restricted world, sequential dialing is a legitimate concern.

[LemADEC]

It's actually a concern since you don't need to dial to know if a gate is at the location, you just need to check for energy cost. Since there's no cooldown on such check, you scan excessively fast and can kill the server along the way.

[GHXX]

Something to add, and connect to this (even though this is a pretty old issue-thread), stargates actually only function within x= -2239472 to +2239472, and same for z, which is limiting for sure.
What i suggest is generating addresses on the fly. When a new gate is placed, the address is randomly generated and put into a cache, optionally along with the position of the stargate base, to allow for easier looking up of addresses.
Not only would this make it impossible to link addresses to coordinates via math, it also allows more than one stargate per chunk if anyone wants that, and it allows people to place stargates where ever they want, even if its at x:20 million and z:20 million.
Not sure what to do about the Dimension-digits, i guess they could also be randomly assigned as soon as the first gate is placed in that dimension.

[LemADEC]

The base game starts glitching around 220k away from 0, as such the 2239472 range is way higher than actually needed and shouldn't be a concern.

[GHXX]

I have not been experiencing any issues playing about 2.2 million blocks away from 0,0 for both x and z, so 3 million blocks away from 0,0 in total.
Additionally, this limit removal is just an added benefit ontop of solving the problem of the addresses being reversible. Effectively solving two issues in one go; i dont see whats wrong with that.