Cult of the Dead Cow unveils Veilid peer-to-peer project
www.theregister.com
‘It’s like Tor and IPFS had sex and produced this thing’

cross-posted from: https://feddit.uk/post/1248314

DEF CON Infosec super-band the Cult of the Dead Cow has released Veilid (pronounced vay-lid), an open source project applications can use to connect up clients and transfer information in a peer-to-peer decentralized manner.

The idea being here that apps – mobile, desktop, web, and headless – can find and talk to each other across the internet privately and securely without having to go through centralized and often corporate-owned systems. Veilid provides code for app developers to drop into their software so that their clients can join and communicate in a peer-to-peer community.

In a DEF CON presentation today, Katelyn “medus4” Bowden and Christien “DilDog” Rioux ran through the technical details of the project, which has apparently taken three years to develop.

The system, written primarily in Rust with some Dart and Python, takes aspects of the Tor anonymizing service and the peer-to-peer InterPlanetary File System (IPFS). If an app on one device connects to an app on another via Veilid, it shouldn’t be possible for either client to know the other’s IP address or location from that connectivity, which is good for privacy, for instance. The app makers can’t get that info, either.

Veilid’s design is documented here, and its source code is here, available under the Mozilla Public License Version 2.0.

“IPFS was not designed with privacy in mind,” Rioux told the DEF CON crowd. “Tor was, but it wasn’t built with performance in mind. And when the NSA runs 100 [Tor] exit nodes, it can fail.”

Unlike Tor, Veilid doesn’t run exit nodes. Each node in the Veilid network is equal, and if the NSA wanted to snoop on Veilid users like it does on Tor users, the Feds would have to monitor the entire network, which hopefully won’t be feasible, even for the No Such Agency. Rioux described it as “like Tor and IPFS had sex and produced this thing.”

“The possibilities here are endless,” added Bowden. “All apps are equal, we’re only as strong as the weakest node and every node is equal. We hope everyone will build on it.”

Each copy of an app using the core Veilid library acts as a network node, it can communicate with other nodes, and uses a 256-bit public key as an ID number. There are no special nodes, and there’s no single point of failure. The project supports Linux, macOS, Windows, Android, iOS, and web apps.

Veilid can talk over UDP and TCP, and connections are authenticated, timestamped, strongly end-to-end encrypted, and digitally signed to prevent eavesdropping, tampering, and impersonation. The cryptography involved has been dubbed VLD0, and uses established algorithms since the project didn’t want to risk introducing weaknesses from “rolling its own,” Rioux said.

This means XChaCha20-Poly1305 for encryption, Elliptic curve25519 for public-private-key authentication and signing, x25519 for DH key exchange, BLAKE3 for cryptographic hashing, and Argon2 for password hash generation. These could be switched out for stronger mechanisms if necessary in future.

Files written to local storage by Veilid are fully encrypted, and encrypted table store APIs are available for developers. Keys for encrypting device data can be password protected.

“The system means there’s no IP address, no tracking, no data collection, and no tracking – that’s the biggest way that people are monetizing your internet use,” Bowden said.

“Billionaires are trying to monetize those connections, and a lot of people are falling for that. We have to make sure this is available,” Bowden continued. The hope is that applications will include Veilid and use it to communicate, so that users can benefit from the network without knowing all the above technical stuff: it should just work for them.

To demonstrate the capabilities of the system, the team built a Veilid-based secure instant-messaging app along the lines of Signal called VeilidChat, using the Flutter framework. Many more apps are needed.

If it takes off in a big way, Veilid could put a big hole in the surveillance capitalism economy. It’s been tried before with mixed or poor results, though the Cult has a reputation for getting stuff done right. ®

  • perestroika@slrpnk.net
    39·
    1 year ago

    More information can be found here: https://veilid.com/framework

    I read it, haven’t tested it - commentary below.

    Before I go into commentary, I will summarize: my background is from I2P - I helped build bits and pieces of that network a decade ago. As far as I can tell, Veilid deals in concepts that are considerably similar to I2P. If the makers have implemented things well, it could be a capable tool for many occasions. :) My own interest in recent years has shifted towards things like Briar. With that project, there is less common ground. Veilid is when you use public infrastructure to communicate securely, with anonymity. Briar is when you bring your own infrastructure.

    • Networking

    Looks like I2P, but I2P is coded in Java only. Veilid seems to have newer and more diverse languages (more capability, but likely more maintenance needs in future). I2P has a lot of legacy attached by now, and is not known for achieving great performance. A superficial reading of the network protocol doesn’t enable me to tell if Veilid will do better - I can only tell that they have thought of the same problems and found their own solutions. I would hope that when measured in a realistic situation, Veilid would exceed the performance of I2P. How to find out? By trying, in masses and droves…

    • Cryptography

    Impressive list of ciphers. Times have changed, I’m not qualified to say anything about any of them. It leaves the appearance that these people know what they are doing, and are familiar with recent developments in cryptography. They also seem to know that times will change (“Veilid has ensured that upgrading to newer cryptosystems is streamlined and minimally invasive to app developers, and handled transparently at the node level.”), which is good. Keeping local storage encrypted is an improvement over I2P - last time I worked with I2P, an I2P router required external protection (e.g. Linux disk encryption) against seizing the hardware. With mobile devices ever-present everywhere, storage encryption is a reasonable addition. I notice that the BlockStore functionality is not implemented yet. If they intend to get it working, storage encryption is a must, of course.

    • RPC (remote procedure calls)

    Their choice of a procedure call system is unfamiliar to me, but I read about it. I didn’t find anything to complain about.

    • DHT (distributed hash table)

    Looks somewhat like I2P.

    • Private routing

    Looks very much like I2P.

  • fartsparkles@sh.itjust.works
    31·
    1 year ago

    Very funky and a really cool solution regardless of the privacy benefits (a simple library to enable networked applications is genuinely tasty). Looking forward to some audits to see how safe and stable this project is.

  • lingh0e@lemmy.filmEnglish
    31·
    1 year ago

    Holy fuck. CotDC gives me pretty intense flashbacks to the late 90’s. If those guys are still fucking shit up, more power to them.

  • 🌞 Arlo@sh.itjust.works
    14·
    1 year ago

    I’ve built and run it with minimal fuss, but am trying to find a good small app to really wrap my head around how to work in a wildly decentralized space. Anyone got a good idea for a particularly useful app with a solarpunk lean? I was thinking of something like local mutual aid, but am open to all kinds of wild ideas.

  • Nix@merv.news
    12·
    1 year ago

    Sounds great although the name is going to make it difficult for it to become mainstream and the more people using it the stronger it would be

    • BR0QM@sh.itjust.works
      26·
      1 year ago

      I think the intent is that no end user will even need to know of it. As long as it gets built into applications it can still be widely adopted.

      • Nix@merv.news
        10·
        1 year ago

        ohh nice i didnt realize it was supposed to be more of a backend thing

        • wahming@lemmy.world
          13·
          1 year ago

          Yeah it’s like ActivityPub, the average new lemmy user will have no idea what it is, nor will it matter

          • XTL@sopuli.xyz
            1·
            1 year ago

            But what will the apps or websites etc name? New users seem to like being pointed at a particular product and shown how to use and get around problems they may have with it.

            This sort of completely free distributed stuff is technically great, but a bit challenging for wide adoption.

    • Andy@slrpnk.netOP
      16·
      1 year ago

      It’s hard for me to say. I think a presentation at a conference is a major milestone in a project’s deployment. I’m sure there are far more projects that don’t go further than those that do, but it sounds useful, so if it doesn’t in its present form, it might still be an early tech demonstration of something that becomes commonplace in the coming years.

      Basically, I don’t know, but I wouldn’t say it’s unlikely to have an impact.

  • sznio@lemmy.world
    9·
    1 year ago

    I’ve been thinking of something like this since 2018. Great someone finally made it.

  • silence7@slrpnk.net
    6·
    1 year ago

    I worry that systems like this will make it impossible to boot trolls and other bad actors

      • perestroika@slrpnk.net
        8·
        1 year ago

        To address both of your points.

        To my understanding, Veilid is a piece of network infrastructure. It is not a singular end-user app, but an app for other apps to communicate over. Just like TOR, just like I2P, just like (RIP) Entropy and (maybe it still has a pulse) Freenet.

        How to make a convenient environment for users, is not within the task scope of network infrastructure.

        However, I can tell about a decentralized messaging app (probably RIP) that exists / existed on I2P. It was named Syndie, and it was a very ambitious goal (which failed). It had 3 levels of access controls: a node operator could refuse to serve certain (cryptographically identified) channels from their node. A channel creator could protect their channels from reading and posting in various ways (pre-shared key, passphrase-derived key, a key encrypted to a user identity, maybe more). Finally, a user could block any other (cryptographically identified) user from interacting with them. Identity was cheap, but since there were many countermeasures, environment was manageable.

        Example actions might be:

        • being the node operator, I designate that channel AAA won’t be served from here
        • being the channel operator of channel AAA, I designate that users A, B, C and D get keys to read and post
        • being the user A, I block user D from my view
  • lariedos@slrpnk.net
    6·
    1 year ago

    This reminds me about how network traffic worked in a book called “The Diamond Age” by Neal Stephenson (author of Cryptonomicon, and Snow Crash). In the book they described every device or application being a node and packets were routed through random nodes until they were pieced back together at their destination. That there was no central routing in these cases. It was a plot point because it’s noted how difficult it is to track messages in this kind of networking. I’m not sure I’m remembering it correctly but it’s a neat idea.

  • 👁️👄👁️@lemm.eeEnglish
    5·
    1 year ago

    Cool but let me know when it’s downloadable. I know it’s coming soon, but I’d rather not promote vaporware until it’s usable.