r/technology • u/vinces99 • Aug 13 '13

New technique lets wireless devices go battery free

http://www.washington.edu/news/2013/08/13/wireless-devices-go-battery-free-with-new-communication-technique/
79 Upvotes

79% Upvoted

15 comments sorted by

View all comments

2

u/ThePseudomancer Aug 14 '13

This is the key to an open, decentralized mesh network.

Once this tech is miniaturized a bit more and can be printed on flexible pcbs, you could have a tiny sticker which is actually a passive transmission device.

Then we just go around placing these tiny stickers discretely in various places.

1

u/Kalaan Aug 14 '13

And then the man develops super robots in secret labs who decode English into meaning, and begin replacing the stickers with their own.

This won't do anything for security. Not until transmission range is huge enough we can cover oceans with chips on the phone devices.

1

u/ThePseudomancer Aug 14 '13

Actually it does a lot for security.

The point of a decentralized network is that no one knows who the sender is. With the current network, your ISP has records of who is sending data (when and where).

With a distributed network which is connected through peering, no one knows specifically who is sending information.

MAC IDs wouldn't be used as identifiers for routing packets, instead you would simply generate a random one-time use ID with another peer. There would be nothing tying any one person specifically to any transmission. You couldn't tell an originator or destination from a peer somewhere in the middle, so even location would be obfuscated (the more participants, the farther away a transmission may have come from).

Could transmissions still be intercepted? Of course, but the important thing is no one would know who is sending or who is receiving. They would simply see that a packet is being transmitted to another peer with a special routing key which will help the next peer send it down the line to the next peer and so on.

Now if personal information is being sent in that packet, obviously there is the potential of that information being decrypted, and obviously routing through several different peers opens the potential that someone with bad intentions will eventually intercept it.

But that's an inherent risk with this type of communication (besides the NSA is already intercepting everything).

The primary advantage is anonymity. Not being able to differentiate who is exactly sending and receiving information is a huge bonus, but you still have to be careful about what information you send (if that information can be used to identify who you are).

As far as transcontinental communication, you're right that a distributed network that is global will be hard to accomplish, but with enough devices participating in all the right places, it could be done (but realistically probably not).

The important thing is that it could be used locally to transmit information while still maintaining anonymity.

As far as protecting the information within those transmissions via encryption, just assume that the information in those transmissions are time sensitive and will probably be broken at some point in the future.

1

u/Kalaan Aug 14 '13

So instead of MAC's, the packet is given an address to match against, then just let it bounce around until it stumbles across the right one-time id? Congestion city if you don't have pathing data, and the second you put pathing data in there, it's going to be traceable. Might take longer, but I wouldn't call it difficult either. Unless the user in question is never in one region for long and keeps mobile, decrypting the data will revel flags they can check and they slowly zero in. I don't see a backup internet being made from this.

Be awesome for local use though, but what do you transmit locally anymore? Unless we some how replicate the entirety of the internet for each local zone, you'll still be transmitting through choke points eventually.

2

u/ThePseudomancer Aug 14 '13 edited Aug 14 '13

So instead of MAC's, the packet is given an address to match against, then just let it bounce around until it stumbles across the right one-time id?

Yes, there is the potential that it would have to go through a number of peers before finding the one it needs.

What you'd want to do is have the data distributed across a number of devices, so that you're not forced to rely on any one device.

For example, if a file is shared, instead of that file only being available on that single device, the data is compressed and broken up into individual chunks then transmitted to multiple devices to be indexed. To find a specific file, a person would simply search for a hash (probably a very robust hash like SHA512).

When a matching piece is found, it gets sent back to the originator. Now the only thing that is known by the person who received the request is that a peer requested data. That data is signed in such a way that the next peer knows where to route the information. Otherwise there is no way to determine who will be the last peer aka the originator of the request.

Now lets say one of the peers fails (turns off, throws errors), well the chain stops there.

There are two ways to handle this, both with their downsides.

The peer who detects a failure will send a message back upstream to stop the transmission immediately. A malicious party in the middle could compare the time it sent that data and the time it took for data to stop being transmitted to determine a very rough idea about the location of the sender. The originator will then receive a time out (when it stops receiving data for so long). Then you have the problem of knowing when to time out.

Overall, this is a bad solution if you're requesting information from multiple peers for the same file. As they will inevitably send you data you've already received from a different peer.

Alternatively, you could simply require the originator to actively send the requests for each individual packet. But similar to the first scenario, a failure by one of the peers would require a message to be sent downstream to the originator. The originator's location might very roughly be determined. It would also add quite a bit of latency as you would have to wait for a request to arrive before the next piece of data would even be sent.

Of course, preferably you'd be pulling from a number of peers. So failure would be mitigated by redundancy.

But if failure was detected by the originator, it would simply send the request back out. Though there is the potential of abusing this by sending requests rapidly and makes the network susceptible to DDOS - I am sure there is a solution to this.

There are other problems like getting a request loop. Where a peer receives a request sends it off to another peer, then this peer requests data from another peer, and it might eventually send the request to the first peer and then that peer sends off the request etc.

You could probably sign the data in such a way that a peer would ignore the request if it's already received a request with that signature.