[HN Gopher] Nomad, communicate off-grid mesh, forward secrecy an...
___________________________________________________________________
Nomad, communicate off-grid mesh, forward secrecy and extreme
privacy
Author : pyinstallwoes
Score : 286 points
Date : 2024-08-15 07:54 UTC (15 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fullspectrumdev wrote:
| The underlying Reticulum network this uses is really quite
| interesting given how many transport media it offers (packet
| radio, etc).
| mcshicks wrote:
| Oh that's so funny that is a real thing I thought it was a joke
| about the fictional reticulum computer network from the Neal
| Stephenson novel Anathem.
| nexus_six wrote:
| Reticulum is incredibly versatile and has an entire ecosystem
| of tools under development. NomadNet is just one of the
| messengers. There is Sideband, a mobile app client
| (https://github.com/markqvist/Sideband), and Reticulum
| MeshChat, developed by Liam Cottle which is a browser based
| client https://github.com/liamcottle/reticulum-meshchat.
|
| Reticulum can work over anything that has a throughput greater
| than 5 bits a second (yes, bits) and a MDU of 500 bytes. Not
| only can it work over hundreds of different carriers (LoRa,
| BLE, Packet Radio, overlay networks like Tor and I2P) but each
| of these carriers can be apart of the same network.
|
| I threw together a quick proof of concept of it working over HF
| radio. I setup two nodes about 144 km (90 miles) separate. Both
| were ICOM-7300's with a Raspberry Pi 5 driving the software
| modem that would take packets from Reticulum and send them over
| the air. https://www.youtube.com/watch?v=blwNVumLujc
|
| Node 1 was out in the field while Node 2 was back at my house.
| Node 2 had two interfaces setup, one for the HF modem and
| another connected to the TCP testnet. This means that Node 1
| could access any peer that was over on the TCP testnet.
|
| Here is a quick primer on Reticulum that explains some of the
| basic concepts: https://www.youtube.com/watch?v=q8ltLt5SK6A
| kragen wrote:
| is there maybe an explanation of how the network works that
| isn't a video? is chapter 4 of the manual the best
| explanation? i admit i'm spoiled by the great explanations
| provided by academic projects, and i don't know where to look
| for, say, how it defends against traffic analysis attacks to
| statistically deanonymize speakers, or whether that's outside
| of its threat model
|
| if it were a mechanical device or a graphics rendering
| algorithm i would think a video would be better, but it's a
| peer-to-peer networking protocol, and the video just looks
| like distracting eye candy
| nexus_six wrote:
| It's meant to just be a quick explanation of some of the
| very basic concepts. But if you want to understand the
| network stack in-depth the manual is the best resource:
| https://reticulum.network/manual/index.html
| generalizations wrote:
| Is there a more formal description of the algorithm? I'd
| be interested in understanding not the implementation,
| but how the algo has been constructed, to understand its
| strengths and weaknesses.
| franek wrote:
| > chapter 4 of the manual
|
| To me that chapter ("Understanding Reticulum") was a very
| pleasant read a few weeks ago, and inspiring too. I would
| love to get some HN expert opinions on it, especially about
| routing, so I posted it separately:
|
| https://news.ycombinator.com/item?id=41257619
| cyberax wrote:
| How does Reticulum solve the fundamental issue of mesh
| networks: either you have to have a central controlling
| authority for addressing, or an adversary can just flood your
| network?
|
| Does it have some kind of blockchain crap tie-in?
| dicknuckle wrote:
| blockchain can be cheap (power, compute etc) and not crap.
| Doesn't mean every project that builds with it takes that
| into consideration.
| cyberax wrote:
| > blockchain can be cheap (power, compute etc) and not
| crap.
|
| No. All blockchain is crap, no exceptions are
| fundamentally possible. The reality reflects that rather
| starkly.
|
| By "blockchain" I mean a system with a distributed
| consesus via proof-of-work or proof-of-stake.
| __MatrixMan__ wrote:
| So it stops being a blockchain if the criteria for adding
| a block is based on something else? Or do you intend to
| update your definition to incorporate other consensus
| mechanisms as they emerge?
|
| Seems to me that a more useful definition would abstract
| out the consensus model such that a blockchain is
| essentially a merkle-linked-list together with some
| function for determining which of two candidate next-
| blocks will be the actual one, but without getting too
| specific for what that function is... just because
| there's so much potential for variation there.
| jazzyjackson wrote:
| > just because there's so much potential for variation
| there.
|
| There really isn't. Either you expend some resource to
| make it expensive to attack or you stake some resource so
| you have something to lose to prove you're not a bad
| actor. I've never seen anything more creative than this.
| EGreg wrote:
| There are lots of other approaches - IOTA DAG, HashGraph,
| Ripple Consensus Process etc.
|
| I am not a fan of blockchains, though. They are overkill
| for most uses. But here is an example of a non-blockchain
| system that doesn't even require global consensus:
|
| http://intercoin.org/technology.pdf
|
| Also check out the Autonomi network
| cyberax wrote:
| It's not really going to work. Without a centralizing
| consensus, any such scheme is vulnerable to be drowned in
| forks.
|
| A malicious notary network can simply flood the ledger
| with conflicting views. So clients will have to somehow
| find a set of notaries that is the "best".
|
| Proof-of-stake means that there's effectively a vote on
| the set of "reliable" agents, and proof-of-work works
| because the malicious notaries can't outrace everyone
| else.
| EGreg wrote:
| Sorry, but you're not exactly an expert on this. There is
| a huge body of literature that says otherwise, and
| reference implementations.
|
| You don't NEED "a centralizing consensus". IOTA did have
| one, called a "governor". And now they also did away with
| it.
|
| I had a discussion with the CTO of Ripple (back then
| their chief cryptographer) David Schwartz about this
| exact issue in 2018, when I was also connecting with
| Leslie Lamport and others in the industry to discuss why
| and how global consensus was even needed
|
| https://community.intercoin.app/t/intercoin-technology-
| conse...
|
| You can also read this post here:
| https://community.intercoin.app/t/intercoin-technology-
| recov...
|
| At the end of the post, it links to the mathematical
| results on arxiv if you're interested:
| https://arxiv.org/pdf/0802.0832v1
| cyberax wrote:
| > Sorry, but you're not exactly an expert on this. There
| is a huge body of literature that says otherwise, and
| reference implementations.
|
| Yep, and none of them managed to solve the issue of
| resiliency without some kind of a stake.
|
| From your own link:
|
| > Intercoin's ledger technology requires the sender to
| endorse a transaction after a supermajority of validators
| have approved it.
|
| > Validators periodically check one another with "proof
| of resource" techniques.
|
| Basically, it just moves the problem of validating
| individual transactions to validating the set of trusted
| notaries via proof-of-stake.
|
| Just another rehash of crapcoin bullshit.
| K0balt wrote:
| POW doesn't have to be useless work. It can be useful
| work, so that mining actually creates a value tied to off
| chain economic systems. Then you have something that
| actually has value, and you can then use POS to give
| validators both a correct incentive alignment and a way
| to get paid for their work. Hybrid value backed POW for
| token creation with POS for validation creates a really
| good system for digital assets.
|
| Sadly, extant systems for this are few because generating
| real value is actually challenging.
| cyberax wrote:
| > It can be useful work
|
| It can be in theory, but in practice there are no tasks
| that fit the definition. All attempts to use something
| like protein folding ended up in failure.
| acaloiar wrote:
| I'm afraid you're redefining what a blockchain is. A
| blockchain is a distributed ledger. Distributed ledgers
| are an application of distributed conensus, which is a
| truly interesting field within computer science.
| EGreg wrote:
| You're being downvoted because you're making sweeping
| unsupported assertions, likely based on an ideological
| opposition to blockhain.
|
| I am guessing it has to do with anger at FTX and other
| negligent participants in the wider "crypto" ecosystem
| that has very little to do with blockchains. But that is
| a "non sequitur" (Latin for "it does not follow).
|
| If I am wrong in my assumptions and you have an actual
| argument supporting your assertions about "all
| blockchains" being crap, please do elaborate on the
| substance.
| cyberax wrote:
| The reality is: blockchain has failed in EVERY area it's
| been tried, except for illegal/unregulated payments.
|
| Assets tracking? Failed. Interbank settlements? Failed.
| NFT and art? Spectacularly failed (wanna an NFT for that
| spectacle?).
| __MatrixMan__ wrote:
| If you've picked mesh networking, then you care about
| partition tolerance. But blockchains prioritize
| consistency. So I think using blockchains on mesh
| networks puts you in a disadvantaged situation re: the
| CAP theorem. There's got to be a way which better aligns
| the application layer with the constraints of the
| physical layer.
| __MatrixMan__ wrote:
| I can't comment on Reticulum, but I think there are
| solutions to that problem re: content-addressing rather
| than node-addressing.
|
| If you replicate a piece of data based on whether you or
| your (explicitly trusted) peers are interested in it, then
| the only way to flood the network is to convince all of the
| users to become interested in it, which is likely difficult
| enough to discourage misbehavior.
|
| pub/sub, not request/response.
| cyberax wrote:
| Sigh. The problem is not the content. It's the
| addressing.
|
| For the content-based addressing to work, you need to
| flood the network with the reachability information ("how
| can I get to this block?"), and it's trivially easy to
| just generate enough of it to overwhelm the routing
| nodes.
| icepat wrote:
| No, Reticulum does not require a blockchain. My
| understanding is that Reticulum solves this by allowing
| network redundancy.
| cyberax wrote:
| So what happens if I create a node, then create 10
| trillion addresses and send a message to every one of
| them?
| AyyEye wrote:
| > either you have to have a central controlling authority
| for addressing, or an adversary can just flood your network
|
| False dichotomy. IIRC reticulum does something like an
| inverse TTL, so packets have priority based on how local
| they are.
| cyberax wrote:
| Nope. It's fundamental.
|
| The problem is in the _addressing_. How do you find the
| packet's next hop?
| bigallen wrote:
| Are you in USA? I'm seeing words like "private" and
| "cryptographic" in the github. What's the interaction with
| ham radio rules about no encryption?
| jvanderbot wrote:
| Lora and wifi are not ham radio networks. I imagine that
| kind of multi-channel use is just fine.
| linsomniac wrote:
| I believe the question you are replying to is directly in
| response to:
|
| >I threw together a quick proof of concept of it working
| over HF radio
|
| Which I assume was amateur band rather than commercial
| (in the 3-30MHz range). I don't believe LoRa and WiFi
| operate in that band.
| jvanderbot wrote:
| Correct: I misread the thread. Thanks!
| exe34 wrote:
| would you be able to transmit under the noisefloor and
| integrate on the other side? i imagine it would still break
| the law, but you wouldn't be likely to get caught?
| Dylan16807 wrote:
| Under the noise floor at what distance? If you don't want
| to be a bright beacon at a mile, then you're not going to
| have a lot of signal at a hundred miles.
| crest wrote:
| You can still use ham packet radio protocols over ISM bands
| not held back by those stupid historical limitations and
| stay within the law.
| anamexis wrote:
| Parent is responding to this:
|
| > I threw together a quick proof of concept of it working
| over HF radio.
|
| I'm not aware of any HF bands you can use in the US
| without a license. And it is prohibited to use any kind
| of secret encryption on amateur bands.
| franek wrote:
| Does Reticulum routing always prefer the path with the fewest
| hops, even if a path with more hops might have higher
| throughput or lower latency?
|
| That's how I understand the manual
| (https://reticulum.network/manual/understanding.html):
|
| > Once an announce has reached a node in the network, any
| other node in direct contact with that node will be able to
| reach the destination the announce originated from, simply by
| sending a packet addressed to that destination. Any node with
| knowledge of the announce will be able to direct the packet
| towards the destination by looking up the next node with the
| shortest amount of hops to the destination.
| Aerbil313 wrote:
| Why is the lower limit on bps? If there is interference for 5
| seconds and my hardware can't get signal, will it drop the
| packet? Ideally it wouldn't.
| Rhapso wrote:
| I'm starting to look at the latency tolerance components of the
| protocol, once it supports sneakernet as a transport, it will
| be perfect.
|
| edit: nvmd, looks like it is set at a global level not a link
| level
| nexus_six wrote:
| > once it supports sneakernet as a transport, it will be
| perfect.
|
| Sneakernet transport has a wide array of definitions, but my
| favorite part about NomadNet and Sideband is the fact you can
| _print_ paper QR code messages and have a recipient or LXMF
| propagation node scan them and have your message delivered. I
| have a $13 thermal printer I was able to get messages printed
| with.
| tazu wrote:
| I searched around and couldn't find anything, has this been
| audited?
| macintux wrote:
| > Nomad Network is beta software, and should be considered as
| such. While it has been built with cryptography best-practices
| very foremost in mind, it has not been externally security
| audited, and there could very well be privacy-breaking bugs. If
| you want to help out, or help sponsor an audit, please do get
| in touch.
| Rhapso wrote:
| At this point, unless you want to pay for it or drive the
| fundraiser, I don't think it is reasonable to expect non-
| commercial products to be audited formally.
| 1oooqooq wrote:
| uses https://github.com/markqvist/Reticulum
|
| > Coordination-less globally unique addressing and identification
|
| > Fully self-configuring multi-hop routing
|
| > Unforgeable packet delivery confirmations
|
| > Initiator anonymity
|
| So the noisiest protocol ever with zero flood protection? Anyone
| knows better than my superficial hot take? But I doubt they
| solved those problems for real, that would be real news _and_
| academic progress.
| kragen wrote:
| generally speaking, networks that support anonymity have much
| better flood protection than things like tcp/ip. ccn routers
| won't send you any data packets you haven't sent an interest
| packet for; i'm guessing reticulum works similarly
| AnIrishDuck wrote:
| What prevents an adversary from flooding the network with
| interest packets?
| kragen wrote:
| that's an obviously good question to ask, and i'm not sure
| what the answer is. the original ccn work by van jacobson
| et al. doesn't really attempt any security. one obvious
| thing to try is for a router to rate-limit its forwarding
| of the interest packets coming in on any one port,
| especially if it has a lot of active interest packets from
| that port already (in ndn systems the router has to
| remember where interest packets came from so that it can
| forward any answering data packets out the right port, so
| this doesn't require maintaining any extra data.) but i
| don't know if existing ndn work tackles this problem or
| what approaches have been found to work
| nexus_six wrote:
| https://reticulum.network/manual/interfaces.html#announce
| -ra... The manual has some documentation on some of the
| rate limiting features built into RNS
| kragen wrote:
| thanks!
|
| fwiw, those seem to apply to only a single destination,
| and any node can sybil up as many destinations as it
| wants, right? `announce_cap` seems more relevant
|
| is there a place where you've written down the threat
| model reticulum is intended to defend against? it's hard
| for me to evaluate its security measures without that
| context
| nexus_six wrote:
| I'm not sure there is a formal threat model yet (I'm not
| a maintainer), but there has been discussion regarding
| this topic. You can checkout the Github forum page
| (https://github.com/markqvist/Reticulum/discussions) and
| there is also an Element channel at #reticulum:matrix.org
|
| The threat model would be highly dependent on the carrier
| used. For example, if you're using LoRa an adversary
| would be using far different methods of disruption when
| compared to a traditional overlay network.
| kragen wrote:
| thank you very much!
|
| i think physical-layer disruption like lora jamming is
| kind of a separate consideration, but physical-layer
| traffic analysis might not be
|
| i had misunderstood you to be saying that the second
| reticulum node ever was at your house, so i had assumed
| you were the author
| 1oooqooq wrote:
| how do you rate_limit with "anonymous initiation"?
|
| one malicious peer can have as many sources as they want.
| don't even need a botnet of IPs.
|
| The link you posted seem to guard against flood of sinks
| on the distributed routing, but there's no mention of
| source flooding.
| AnIrishDuck wrote:
| Sure; but distributed mesh networks feel like another
| area where Sybil Attacks [1] can rear their ugly heads.
| This is a fundamentally hard problem to solve in all
| distributed systems without a coordinating authority.
|
| The blockchain approach basically bootstraps said
| authority, and comes with tons of additional baggage.
| It's the only one I'm aware of that has real
| countermeasures to Sybil attacks though (in a sense; 51%
| attacks can also look a lot like a Sybil attack with the
| right glasses on)
|
| 1. https://en.wikipedia.org/wiki/Sybil_attack
| kragen wrote:
| i agree about the blockchain, though now possibly there
| are multiple viable approaches under that rubric now that
| ethereum has abandoned pow
|
| there are a lot of possible approaches to the problem,
| though
|
| hashcash for announcing new destinations is one possible
| measure
|
| reserving most of the bandwidth for established
| connections to which both parties are indicating their
| continuing enthusiastic consent is another, and one which
| the circuit-switched pstn does implicitly, which is why
| your phone calls wouldn't drop or skip when there was a
| commercial break in prime-time tv. reticulum seems to do
| this by reserving 97% of bandwidth for non-announcement
| traffic, though i might be misunderstanding
|
| the agorics 'digital silk road' paper from 01995
| (unrelated to the later darknet market) describes another
| approach: include a source route and postage on every
| packet, with each network provider deducting however much
| postage it feels like deducting, and keeping track of
| bilateral account balances with each peer network
| (postage sent minus postage received). if the postage
| runs out, your packet gets lost, and the sender can
| choose to try resending it over the same route with more
| postage or routing it over a less expensive network.
| periodic cash settlement between network service
| providers zeroes out any persistent imbalance in cash
| sent and received: http://www.cap-
| lore.com/Agorics/Library/dsr.html. i don't think this has
| ever been implemented, though current nsp peering
| agreements do resemble it to some degree. the original
| paper suggested using eft for the periodic settlements,
| but nowadays you could very reasonably do it with
| something like ether
|
| you can supplement the established-connection-
| prioritizing mechanism with a granovetter-diagram
| introducer mechanism: if alice has an established
| connection to bob, and bob has an established connection
| to carol, bob can dedicate some of his bandwidth on those
| two connections to passing messages between alice and
| carol. he can do this either completely at the
| application layer, with no support from lower layers of
| the network, like an irc server or turn server, or
| potentially _with_ support from the network layer to find
| a more efficient and reliable route. (reticulum seems to
| support this; bob can pass alice 's destination to carol
| or vice versa, which the manual seems to say eliminates
| the need for the announce mechanism, though i don't yet
| understand how the protocol works.) this allows bob to
| prioritize such connection requests using information
| that isn't available at the network layer, such as
| whether alice and/or carol have passed a captcha and/or
| are paying him, who they were introduced to him by, who
| they've introduced him to in the past, and what valuable
| data they've sent him. if bob repeatedly introduces alice
| to people she doesn't like talking to, she might cut off
| contact with bob, or at least look on his future
| introductions with a jaundiced eye and not allocate them
| much bandwidth
| Aerbil313 wrote:
| Check out the newly released Freenet feature
| https://freenet.org/news/introducing-ghost-keys/ anc
| Proof of Trust system:
| https://freenet.org/news/799-proof-of-trust-a-wealth-
| unbiase...
| kragen wrote:
| thanks!
| 1oooqooq wrote:
| how do you get routing then? what you described is p2p or
| opt-in routing, which doesn't align with the features i
| quoted there.
| derelicta wrote:
| I wouldnt be surprised if in a few years such project would get
| criminalised
| giantg2 wrote:
| More likely to end up compromised but available - like Tor,
| where the NSA just runs a sufficient number of nodes to
| compromise the network.
| hedvig23 wrote:
| Doesn't Firechat fit in this conversation, possibly some vague
| event behind the scenes that shuts anything like this down
| Nifty3929 wrote:
| Only if it can't be infiltrated, which is usually the preferred
| option.
| Borg3 wrote:
| Hmm looks interesting. Too bad it is written in Python. So, few
| questions then. Can it be bootstraped completly offline? Also,
| what are node requirement for this? I mean, CPU and MEM. Can my
| P150 with 16MB RAM run it?
| nexus_six wrote:
| There is a work in progress C++ port called microReticulum that
| can run on hardware such as the ESP32
| https://github.com/attermann/microReticulum
| winrid wrote:
| You mean like a cyrex 6x86? 0.0
| AyyEye wrote:
| You can run a node on an esp32
| https://markqvist.github.io/Reticulum/manual/hardware.html
| dang wrote:
| Related ongoing thread:
|
| _Private, Secure and Uncensorable Messaging over a LoRa Mesh
| (2022)_ - https://news.ycombinator.com/item?id=41256623 - Aug
| 2024 (21 comments)
| evbogue wrote:
| How does Nomadnet/Reticulum compare to yggdrasil, ipfs, nostr, or
| even scuttlebot?
| goodpoint wrote:
| How is this better than Briar? https://briarproject.org/ comes
| with quite a pedigree
| nexus_six wrote:
| Briar is a standalone messaging application while NomadNet is
| designed to work with the Reticulum Network Stack
| (https://reticulum.network), which is a complete alternative to
| TCP/IP
| sitkack wrote:
| Not if NextNav https://news.ycombinator.com/item?id=41226802 gets
| a huge chunk of 900Mhz ISM band.
|
| https://en.wikipedia.org/wiki/ISM_radio_band
|
| Register your feedback here
| https://www.fcc.gov/ecfs/search/docket-detail/24-240
| allknowingfrog wrote:
| I don't see an obvious mechanism for leaving said feedback. If
| I'm dumb enough to miss it, maybe others are too. Could you
| point us in the right direction?
| lfmunoz4 wrote:
| You click the huge button that says express filing and simply
| put name address and type your comment that is it. I just
| filed a comment.
| K0balt wrote:
| Can't find a comment area here? I'm old and blind, but I don't
| see it and my agent also cannot find a link.
| hypercube33 wrote:
| LoraWAN Wifi sits as part of wifi 6 or 7, I forget on the
| 900mhz band so this hopefully gets made an exception at the
| worst.
| Jaauthor wrote:
| Super exciting to read about this! Building an off-grid mesh is
| the central premise of my scifi novel 'Mesh.'
| https://inkican.com/mesh-middle-grade-scifi-thriller/
| tlhunter wrote:
| This reminds me of Meshtastic, but I suppose Nomad is for PCs
| while Meshtastic is for microcontrollers.
|
| https://meshtastic.org/
| AyyEye wrote:
| Reticulum works on microcontrollers. The rnode firmware that
| works on meshtastic boards
| https://markqvist.github.io/Reticulum/manual/hardware.html
| Aerbil313 wrote:
| Such a thing is my dream for a long time now. A new type of
| "phone" that is charged via sun/hand crank, communicating
| entirely over radio, running a distributed mesh network.
| Applications and data are both decentralized, in the same way as
| Freenet. 30-year nominal lifespan. Perfect post-Collapse personal
| communications and compute device for masses. Seems they figured
| out the communication protocol part.
| K0balt wrote:
| MFW people somehow feel like there is any guarantee of privacy
| when typing on a touchscreen keyboard on an android or IOS
| device...
|
| If you want actual privacy you need to run a keyboard/ terminal
| running bare-metal code for capturing and displaying text,
| encryption, and sending the encrypted packet over your reticulum
| client as an encrypted blob.
|
| This could be a hardwired serial or Bluetooth, for example. Or
| you could run a separate MCU to handle networking and protocols.
| The important thing is to run verified code on bare metal with no
| binary blobs, and that the encrypted payload should be the only
| thing sent to the network node, preferably over a TTL serial link
| between the terminal controller and the network controller.
| upofadown wrote:
| Just some quick, possibly uninformed, usability comments based on
| a quick glance...
|
| Puts the number used as identity (address) up front in a way that
| the user can understand what it means. So better than most.
| Combining that identity with trust in a dialog seems to be
| relatively understandable. Having a category other than trusted
| and untrusted (unknown) is a good idea but is not immediately
| understandable. The user of course would have to be instructed to
| know exactly what "trust" means in this context.
|
| The user doesn't need to know that they are using Curve25519.
| Just that some sort of encryption has been achieved.
|
| Hex for the identity number is the worst possible choice of base.
| Either decimal which is quite familiar for identifying things or
| base32 for shorter numbers. The identity number should be
| consistently displayed in some helpful grouping (4 groups of 5?).
___________________________________________________________________
(page generated 2024-08-15 23:00 UTC)