Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[miauw62]

You shouldn't be looking at python specifically; a function will have the same complexity in any language if it's implemented in the same way (which does not mean it runs as fast, just that it slows down at the same rate with your input). Look up the specific algorithm or data structure instead.

[RoguelikeRazuka]

You shouldn't be looking at python specifically; a function will have the same complexity in any language if it's implemented in the same way (which does not mean it runs as fast, just that it slows down at the same rate with your input). Look up the specific algorithm or data structure instead.

Yes I understand what you are pointing at, but I don't even know anything about, for example, how dictionaries in python are implemented, which data stuctures they are based on etc.

[Shadowlord]

If you can't find documentation on it, you can run a test comparing how long it takes to Do A Lot Of Work using their dictionary compared to other approaches, for example.

[Orange Wizard]

Dictionaries are very well-engineered in Python. Most of the language (modules, functions, classes, etc.) is built on dictionaries.

[itisnotlogical]

Had an idea for a decentralized email system. Each member of the network acts as a message server. There is no central routing point that all messages go through, each person using the network is also a volunteer that carries messages between destinations. I imagine there would have to be some kind of central program noting active users, since a person can't send messages if their computer is shut off. But the idea is that, kind of like Tor, a message goes through multiple points before it reaches its destination; unlike traditional email, where a central database can be searched and archived and analyzed by Shady Corporations And The NSA^tm, this network would be more like SMS where each message is disposable and only stored by the recipient and the sender. However it would not be like SMS in that there would be no "owner" of the network; just volunteers that have nothing to do with the messages they pass along.

I can't even write a chat client, I'm under no delusion that I could pull something like this off. But thoughts on general feasibility? Does something like this already exist?

[Skyrunner]

Sounds like a meshnet.

Problem 1: In this case, every single volunteer knows who is sending a message to whom. They can't see the contents, but they can see the sender and receiver... Though I guess the sender can be encrypted, too.

Problem 2: How do you know who to send a message to? If you a receive a message bound for John Doe, how do you know whom to send it to if you don't personally know where John Doe's computer is?

Problem 3: It's possible for a malicious intercepter Eve to receive a message for John Doe, then not pass it on.

[i2amroy]

Yeah, the big problem with the idea is a security one. In general your security issues are not the NSA or whatever searching and archiving your giant server; it's people not updating their software or small bugs like that that allow access to problems on the smaller/client side of things. Consolidating your data into a single location means that you can layer level after level of security on it and if any holes are patched you simply need to update it in a single location (plus it makes it easy to keep physical access secure as well). Having a distributed network means that you where before you had only a single server you needed to make secure, you now have dozens or hundreds of machines you have to make sure are all running the absolute latest security code, a fact that anyone who has worked IT before will tell you is a technical impossibility in the vast majority of situations.

We can even draw some parallels to real life situations. Many people might remember the recent "apple store infected apps" debacle. In this case this was only possible in the first place because the people causing the problem were circumventing the control that apple has over the downloading of Xcode. However looking past that point, because all of the distribution was controlled by a single point, Apple was able to quickly "patch" the problem once it was discovered, by purging the apps from the app store. In a worst case scenario apple could even purge them from your phones, because at the time they had that capability. The end result? Vulnerability found and covered, problem solved and done within a few weeks. On the other hand take a look at the very famous Heartbleed Exploit that was announced back in early 2014. Because every single company was responsible for it's own usage of the old framework, (a more "distributed" usage), there was no easy "patch" that could be done. Sure OpenSSL could issue out a patch, but it would still be up to every single company that was using the system to manually update to the latest version. The result? After the course of a year some 74% or so of large companies that had code that were vulnerable had still failed to patch the problem. I have little doubt that if you went digging even today you could probably still find some fairly popular websites that were still vulnerable to the problem; after all, updating to newer versions of software takes time and development effort that could be better spent elsewhere in the eyes of the business oriented.

In short, while for things like physical protection you definitely want a backup in a physically distant location in case of disaster, in terms of electronic security your best bet is often to consolidate as much as you can to allow for better consolidated security (within reason; there is, of course, a point where consolidation begins to be harmful as you fall prey to the "keeping all your eggs in one basket" problem).

And making it a volunteer status simply makes the problem worse, since now anybody who actually wants to steal data simply has to volunteer and the largest security barrier that they have to overcome, that of actually getting their hands on the protected data in the first place, is automatically overcome as the data passes through their computer.

[Antsan]

Problem 3: It's possible for a malicious intercepter Eve to receive a message for John Doe, then not pass it on.

I think that can be circumvented by the clients sending random messages interspersed with the actual message that require an automated answer by the receiver. If a certain node doesn't forward these messages, he'll be marked as untrusted and cut off from the network.
Of course that means additional load.

I just realized that these return messages might be intercepted by someone else, so that's not going to work.

[Orange Wizard]

I started using git over a year ago, and apparently my commit messages have never become much more informative that "changed some stuff", or... "hnngnaafh".

[i2amroy]

I think that can be circumvented by the clients sending random messages interspersed with the actual message that require an automated answer by the receiver. If a certain node doesn't forward these messages, he'll be marked as untrusted and cut off from the network.
Of course that means additional load.

I just realized that these return messages might be intercepted by someone else, so that's not going to work.

Just because a message is intercepted doesn't mean it can't also be forwarded on. Just copy the message and forward on the original, no problem. (Which is generally how intercepted messages work in the world of computers).

[itisnotlogical]

Thing is though it wouldn't be something the volunteer is in control of. If the client is open (or more likely if the background service is running) then it happens without them even knowing.

[Antsan]

I think that can be circumvented by the clients sending random messages interspersed with the actual message that require an automated answer by the receiver. If a certain node doesn't forward these messages, he'll be marked as untrusted and cut off from the network.
Of course that means additional load.

I just realized that these return messages might be intercepted by someone else, so that's not going to work.

Just because a message is intercepted doesn't mean it can't also be forwarded on. Just copy the message and forward on the original, no problem. (Which is generally how intercepted messages work in the world of computers).

The original scenario was

receive a message for John Doe, then not pass it on.

Interceptors need to be met with encryption, I assume. As you always do it, no matter whether in a distributed or centralized network.

[i2amroy]

Thing is though it wouldn't be something the volunteer is in control of. If the client is open (or more likely if the background service is running) then it happens without them even knowing.

That's exactly the definition of "volunteer", i.e. that by making the choice to open the client (whether or not I'm actually sending any messages), I'm deciding to act as a server for other people's messages.

The original scenario was

receive a message for John Doe, then not pass it on.

Ah, fair enough, though I'd see the problem of copying a vast number of messages as a much bigger problem than not passing messages on. A noncompliant node can, as noted earlier, simply be identified relatively quickly and removed from the network. A stealth node, on the other hand, is incredibly difficult to detect and as such can cause much larger problems, as we saw with the semi-recent attack on Tor where hundreds of potential stealth nodes were set up, allowing the attacking organization to track network traffic, if still not quite have direct access to the data itself yet.

[breadman]

Email was originally designed as a distributed system.  You're allowed to set up your own server with its own domain name, and any email sent to that domain name will get pushed to your server.  Granted, the NSA might still be involved on the recipient's side, and the ISP can listen in if no encryption is used, but you can at least deny them access to your server until they get a warrant.  We've ended up consolidating on a few systems for convenience, not due to anything in the email protocol.

Meanwhile, I've been wondering whether encryption can be automatically applied at the transport layer by changing how we use DNS.  Imagine a world where a (name, service) pair resolve to a set of (address, port, encryption scheme, public key) tuples.  As long as you trust the DNS resolution, that renders HTTPS and similar protocols entirely obsolete.  Servers can decide which encryption schemes they'll support, perhaps including plaintext for performance, and clients can use the best encryption they speak without requiring an extra round trip for negotiation.  Including the port in the resolution allows the server to host several thousand domain names without requiring the protocol to specify which one they're using, and means the ISP can't identify a protocol based on information in the packet alone.

[i2amroy]

Email was originally designed as a distributed system.  You're allowed to set up your own server with its own domain name, and any email sent to that domain name will get pushed to your server.  Granted, the NSA might still be involved on the recipient's side, and the ISP can listen in if no encryption is used, but you can at least deny them access to your server until they get a warrant.  We've ended up consolidating on a few systems for convenience, not due to anything in the email protocol.

And to this day you still fairly regularly find cases of email servers being captured and cracked through methods that we've already known about for years, while cases of tech company servers being cracked are few and far between, and only very very rarely do they exploit the same vulnerability twice.

Meanwhile, I've been wondering whether encryption can be automatically applied at the transport layer by changing how we use DNS.  Imagine a world where a (name, service) pair resolve to a set of (address, port, encryption scheme, public key) tuples.  As long as you trust the DNS resolution, that renders HTTPS and similar protocols entirely obsolete.  Servers can decide which encryption schemes they'll support, perhaps including plaintext for performance, and clients can use the best encryption they speak without requiring an extra round trip for negotiation.  Including the port in the resolution allows the server to host several thousand domain names without requiring the protocol to specify which one they're using, and means the ISP can't identify a protocol based on information in the packet alone.

Definitely a cool idea, now we just need to come up with a plan to somehow rewrite it while still maintaining backwards compatibility with every other server ever for the next 40 years (the eternal bane of any change you need to make to the underlying structure of the internet ).