Comment on Is there a precedent for a really delay-tolerant command line interface? (A bit off-topic)
CanadaPlus@lemmy.sdf.org 2 months agoYeah, that’s probably worth a look. Good suggestion. There’s also delay-tolerant protocols for space and similar, but I don’t know if any of them define an endpoint, as opposed to just a transport layer.
nickwitha_k@lemmy.sdf.org 2 months ago
Indeed. I’d really suggest going for something based upon Internet Protocol, with any software that you need at endpoints to read and/or transmit. I might poke about at some ideas on the weekend (long holiday). What languages are you thinking to use?
CanadaPlus@lemmy.sdf.org 2 months ago
Probably Rust, although I’m not married to it. I’m just at the planning stage right now, though.
One open question is if you can use a fairly standard transceiver like a Bluetooth chip, or if you need an SDR. Obviously they weren’t designed with this in mind, by maybe there’s a profile that’s close enough.
Packets should have a few kilobytes of payload so you can fit a postquantum cryptographic artifact. Thankfully, even with a BCH code, it seems doable to fit in a 1-second burst in a standard amateur radio voice channel, for testing. (In actual clandestine use I’d expect you’d want to go as wide as the hardware can support)
As envisioned there would be someone operating a hub, which might have actual network access through some means, and on which the containers run. They would send out runners to collect traffic from busy public spaces which might serve as hubs for burst activity, and dump outgoing packets, all without giving up any locations.
Accounts with their own small container would be opened by sending in a public key, and then further communication would be by standard symmetric algorithm. I have a lightweight hash scheme in mind that would allow awarding of credit for retransmitting packets in a way that couldn’t be cheated.
You’d want to have some ability to detect and move around jamming, or just other people’s bursts. That’s more hardware research, basically.
nickwitha_k@lemmy.sdf.org 2 months ago
I’ve got a few things that I need to get done in the next few days (hopefully mostly sorted today) but you’ve got me rather intrigued with this as a puzzle. I’ll see if I can get some time to sketch some thoughts out and maybe some high-level implementation of some bits in Python (it’s faster to POC things).
A few quick thoughts:
I think that an existing or novel protocol built on top of the Internet Protocol is likely the way to go. Following the OSI model, you can target Layer 4, with some simple stuff for higher layers. Client/Server (possibly the same binary) and associated automation should handle Layers 1-3 (translating between different carriers for Layers 1 and 2, and handling routing of data packets in Layer 3).
Message routing strategies and their impact on OpSec is worth consideration. By this I mean: broadcast-only vs targeted-only vs both vs hybrid. All three have trade-offs.
Broadcast-only: Makes it harder to know the intended destination of the message. Conversely, by being routed to either all known addresses or all approved addresses, it can be more vulnerable to interception by a compromised endpoint.
Targeted-only: May be harder to intercept as the path that a packet takes should result in it hitting fewer potential endpoints. Conversely, some form of addressing is necessary to know, at the least, the next hop in transit. This makes tracing the intended endpoint, as well as network hops much easier (ex. running a traceroute).
Both: Gains the advantages and disadvantages of both approaches, depending on the which mode the data is transmitted in. Ensuring that data is transmitted correctly becomes important and has implications on the requirement of maintaining known good versions of the client/server software to avoid unintentional or malicious improper routing.
Hybrid: Could take many forms but the one that comes to my mind is a multilevel hub and spoke architecture (I’ll draw this out). Basically, you end up having 2-3 “modes” for a client/server: hub, spoke, and endpoint. One or more client/servers operating in a hub “mode” act like traditional servers, kinda like a bulletin board, holding packets for local delivery or transmission to another hub. Client/servers in the spoke mode act as hops between hubs. Client/servers in the endpoint mode are the actual intended destination (this could be combined with the spoke mode). To protect endpoint identity, the destination could be part of the encrypted data packet allowing an endpoint to attempt to decrypt packets received from a hub locally, making it harder to know which endpoint a message is intended for. This does still require greater visibility of hub addresses for routing.
Encryption of packets is vital. Supporting some modularity might be of value so as to allow use of simpler cryptography for PoC but, the protocol should ensure that it is possible to break reverse compatibility (normally NOT what you want to do for networking protocols but avoiding an “it’s an old code but still checks out” situation would be more important).
Amateur radio should be avoided both in PoC and hypothetical “production” use cases. The ban on encryption is insurmountable there and illegal use of encryption could lead to hightened visibility because the FCC, historically, does not fuck around with illegal radio signals. This means all wireless should be below 1W in the US, in bands that are legal for unlicensed use.
Any physical layer that supports arbitrary data transfers should be possible. The implementation to support it would be part of the client/server. So, Bluetooth, 802.11, LORA, sneakernet, and many others could be hypothetically supported. Again, though, this relies on the protocol’s stack to be and to understand it, either directly, or translated by another component.
A web of trust may be a good approach for authentication and identity.
CanadaPlus@lemmy.sdf.org 2 months ago
Darn, I have to go now. Apologies for the considerable latency there might be getting back to you on this, haha!
CanadaPlus@lemmy.sdf.org 2 months ago
Alright, I’m back.
I was talking about amateur radio as a physical layer because I’m totally familiar with it, and know it can support short, wide-enough bursts with total radio silence in between. That’s an important requirement because if you’re loud continuously, in the “prod” case, jackboots with a yagi will show up and arrest you. Spies use fast, wide digital radio transmissions a bit like this in really locked-down countries, just not networked together in any way.
If more standard hardware - or even a non-RF medium - would work, great, no issue. Like you said, there’s no way to support too many assuming they’re safe.
For routing, I would suggest no incoming transmission (or “transmission” if it’s really a hardwire connection) is ignored, but when to rebroadcast is left flexible for the user, who will be able to assess risk and likelihood of success getting closer to the destination in a way no reasonable software could.
Yeah, so a hub just makes good sense - with such a modest network capacity relative to hardware capabilities, why not gather as much in one place as possible? Because one hub might get busted or just fall to some version of enshittification, it should be easy enough for a user to switch, but I think it’s the best choice of central organising principle.
Other than anonymity, is there a reason to separate out spokes from endpoints? One thing I already have worked out is a system where the hub can keep track of who has helped transmit things (in a cheat proof way), and could simply give credit for traffic moved, offsetting whatever cost there is to use it (ISPs aren’t usually free to start with, and this one is a safety risk to operate). The bandwidth overhead is literally just a key ID (address) and a hash per hop.
I figured switching keys frequently would be enough to ensure a degree of anonymity, since it’s completely pseudonymous. We don’t have a guarantee packets will arrive in order or in any reasonable timeframe, but if we did I’d suggest rolling through keys by count or timestamp.
I don’t really have anything to add there. Proving identity beyond just “I hold this key” is out of the scope of what I was considering. I’d probably go about it the same way I would over a more traditional network, if it came up.