It's only partially open source. Some server-side code remains proprietary, and the client-side will depend on proprietary code of Google and Apple and they do not plan to support platforms that are actually Free Software. The law overall is badly written. For example, articles 12 and 26 effectively say that "The source is shared with public, except if it is proprietary or insecure." Or take Article 4: "The government may operate systems that protect the privacy of the identity subjects."
The Swiyu team dropped the Play Integrity requirement on Android: https://github.com/swiyu-admin-ch/eidch-android-wallet/issue... This means that the E-ID will be officially supported on AOSP based secure ROMs like GrapheneOS, without any requirement for Google services.
GNU Taler (https://taler.net/); privacy-preserving payment system. Written in C/Java/TypeScript/Kotlin/Rust/Postgresql/etc.; needs include coding (especially integration into other applications) documentation (review, proof-reading), testing (incl. benchmark, UX), packaging, translation (Weblate/gettext); any help welcome ;-).
We do need to expire cryptographic keys eventually, there is no sane alternative to this. Now, note that "regularly online" here could mean once every X years depending on how the system is configured.
Yes, the random walk relates to the "NAT problem". Basically, due to NAT, peers may not succeed when trying to connect to arbitrary other peers (especially if you assume no TURN servers or other infrastructure to facilitate). The same situation may also arise in mobile ad-hoc networks, where your wireless signals simply don't get everywhere. As a result, the usual greedy routing will get stuck in a local minimal. By prefixing the greedy routing with a random walk, you basically randomize the starting position, and then end up at a random local minima. Replicate at enough local minima (O(sqrt(n)) and do enough (O(sqrt(n)) lookups and the birthday paradox will make it increasingly likely for you to succeed. Without the random walk, both the putter and the getter would greedily route always to their local minimum, and if they differ, never find each other's data.
Where does sqrt come from? Shouldn't it be log? I don't know much about DHTs, but Kademila (BitTorrent's DHT) has query complexity of around O(log n), with n being the total number of nodes in the network. Kademila also uses random node IDs and XOR disrance metric.
BitTorrent's mainline DHT is O(log n). Base 2. However you can usually skip 2-3 bits per round of queries. This means you can locate any of the 20 million nodes in BitTorrent in about 7 hops. In practice it's about 20 queries and takes about 3-5s. No persistent connections. Barely a few KB of memory for every client. No other real world implementation is that good.
Co-author here. If you look into the R5N paper (link in draft), you can find this term. If you assume a routing performance of O(log n) and O(sqrt (n)) number of lookups to find the value, you get O (sqrt (n) * log n) as overall complexity (last section in paper).
For the argument of the sqrt (n) itself, see the paper.
Edit 1: Quote: "Assuming that T [random path length] is chosen large enough to achieve perfect mixing, sqrt (n / (c−1)) replicas would need to be created in order for a GET request to succeed with about 50% probability according
to the birthday paradox."
Edit 2: In a world without local minima the term itself will be 1 (you only need a single lookup and will find the value with 100% probability.
In the restricted route scenario you will have to so O(sqrt(n)) lookups.
Aha, thanks for that, the paper seems to reason better at first glance, I'll read it.
You mention sybil attacks on Kademlia, especially those that arise because nodes may set their ID and "camp around" some known key in the hash table. How is this addressed here? By glancing over the standard draft, I see the identifier is just a SHA-512 of the pubkey. Wouldn't it be feasible to bruteforce the first some bits of the key and "camp around" some keys a malicious sybil actor wants to deny service to?
On this Internet if you don't trust third parties to route all of your traffic through and peers are behind NAT or CGNATs. Or imagine a mixed network with some peers on https://en.wikipedia.org/wiki/Wireless_ad_hoc_network (s), possibly with some connected to the Internet. The key assumption we have (for the random walk to work) is that it must be a small-world network (https://en.wikipedia.org/wiki/Small-world_network) and network topologies surprisingly often are.
What are the plans with GNUnet development? Some years ago there was an active p2p network, but it seems there have been multiple backward incompatible changes. I don't know it the network is still active now.
I'm personally primarily busy with GNU Taler, but still in touch with the more active developers. Major work is still happening on the transport subsystem with the goal of improving NAT traversal. Some work is being done to make the code run on Android. A messenger application (incl. text and voice) works --- if your network/NAT are happy, which most of the time they are not (see my first point). There is also fun cryptographic work happening on Reclaim:ID (SSI), and improvements to the GNU Name System (registrar implementation, automatic scalable import of large DNS zones). Plus some work on automatically testing the system using Linux network namespaces. But yes, quite regular breaking changes and still too frequent breakage on the transport layer means that the active network is tiny. OTOH, until NAT traversal reliably works (incl. our self-imposed restriction to not simply assume that Google runs a TURN server/ICE environment to relay our for us), GNUnet is really only suitable for developers anyway. So normal users sadly still cannot use it. But, development is still quite active.
Thank you for the detailed explanation. I'm glad to hear that gnunet is still slowly but actively developed. Recently I saw that the gnunet package in Debian is orphaned and will be removed by the end of month [1]. But if the network is currently not really usable, except for developers, then that is probably not a big deal.
NGI funded us to work on the GNU Name System (https://www.rfc-editor.org/rfc/rfc9498.html), that includes the Go implementation, updates to the C implementation, and the specification. Plus NGI funds work on https://taler.net/. Another example for a project they funded is https://cryptpad.fr/. https://nlnet.nl/project/ has an extensive list. If you actually care about privacy on the Internet and FLOSS, I'd be surprised if you did not find some project there that you know or use.
If you are working on improving privacy on the Internet with FLOSS, you can still apply for funding at https://nlnet.nl/propose.
Not quite. GNU Taler's reference implementation requires explicit user consent for payment. But as GNU Taler is Free Software, you are free to modify the code on your system (and share your with others) to not require an explicit confirmation if you prefer that. Or even better, to add an option to do that on some "trusted" sites which you make configurable for each user via settings. I don't know if the risk is worth the UX improvement, but a key contribution of GNU Taler is that it is a Free Software payment system where you actually have the full four freedoms. Use them!
While what you say is completely valid, that doesn't save the original argument by pcj50 which was made up claims about the ability for scammer to drain your wallet. Of course you could build your own implementation that allows for such an attack, it is not a valid criticism of the project.
Indeed, I just wanted to point out that the "game changing" desire of entropyie to fully automate payments can still be done with GNU Taler. So you are right that the scammer in the default deployment won't succeed, but additionally entropyie could still totally get what entropyie wants as a feature on their own system (and conceivably make this reasonably secure, too).
Eh, you realize that this very work on the GNU Name System prompted IETF to create the ".alt" zone for this purpose already, minus the $200k fee? Registration is open at https://gana.gnunet.org/dot-alt/dot_alt.html
