Their Linux CDs proved essential in a time where bandwidth was scarce and expensive with home users on dialup and only universities having a few megabits of bandwidth.
> the root is the node with the lowest ed25519 public key, rather than the highest sha512sum hash of the public key
With this scheme, could a bad actor decide to choose a poor key just to be the neighbor of a target in (edit) keyspace? Ordering by the hash of a public key means that the order is protected by the hash function's preimage resistance; does the generation of a ed25519 key have a similar protection?
Can someone explain, why it has end-to-end encryption by default on this level, and why it is good? Isn't this project more about host discovery and routing. Is it providing more performance compared to encryption on other layers, or just for "easy automatic" data encryption?
Based on documentation, it sounds that they have some kind of own crypto implementation in the end.
I found the whitepaper describing used algorithms, but I would need to know more how exactly they are applied and why they are selected, before I could trust the encryption.
This allows us to focus our investment on one layer and have it apply to all applications on top "for free". I'm not saying this specific implementation is the right one, but having it below the app layer makes a ton of sense.
Yggdrasil builds a multi-hop IPv6 overlay network using peer-to-peer connections. You can string a whole bunch of nodes together using whatever means (cables, wireless or TCP peerings over the internet or any other network) and you get a full-mesh network where everyone can reach everyone else.
It's designed to be as minimal-configuration as possible and scalable in a way that many other mesh routing protocols aren't.
One thing that wasn't clear to me from the documentation: What's the typical latency you observe with this network? Does the routing take physical distance/observed delays into account in some way, or could you wind up with short (in network space) paths that in reality bounce a packet back and forth between the US and New Zealand repeatedly?
Latency is dependent on the underlying peering connections. Yggdrasil will try wherever possible to take the shortest paths in network space, but yes, it's possible those could be physically indirect if the underlying peerings are indirect. Generally on the public network (which is probably a couple thousand nodes in number, where people have contributed a number of public nodes and have interconnected them) we see very reasonable latencies.
How does Yggdrasil compare to Wireguard? A github search shows that yggrasil-go uses wireguard-tun project as the tun driver; does it relate in any other way? The main problem/use case is different of course (Wireguard is a manually configured point-to-point vpn with e2ee, where yggdrasil is an internet-scale overlay network with e2ee.), but I mean at a low level, protocol, encryption, etc.
At low level is not related to WireGuard in any way.
The wintun project only exposes a virtual network interface to Windows systems, a clean and proper signed windows driver. That side project to Wireguard was created because the native windows virtual interface is too basic for "advanced vpns" and the former windows TUN driver (OpenVPN side project TUN driver for windows) used by everyone was clunky and old.
YG uses it own crypto and routing, wintun is used here only to expose the virtual network interface on Windows.
I’d also be curious about this. Say for the use case of running a small private chat server hosted on a home network; does either of these seem better suited, or are they just different architectures that can handle mostly similar things?
I have two devices split by VNET and not routed out to the internet. I connect those two and a VPS to create a small Yggdrasil network. This allows me to access all three devices from “anywhere”. Would use again.
It works pretty similar to cjdns, but implementation is not as crashy in my experience, also some transport protocol differences (ygg uses tcp while cjdns does udp), also DHT routing instead of cjdns supernode stuff.
So while usability is pretty similar, they're pretty different underneath.
I haven't checked, but this may be due to the restriction in CCM/GCM.
Here is the relevant comment/code from Samba.
* CCM and GCM algorithms must never have their
* nonce wrap, or the security of the whole
* communication and the keys is destroyed.
* We must drop the connection once we have
* transfered too much data.
*
* NOTE: We assume nonces greater than 8 bytes.
*/
Nope, is more like a "Vitual public network" maker.
Peer links are encrypted, each peer has its own key, but DHT and routing is not obfuscated. It exposes virtual network interfaces with an IPV6 address per node. You can use common software on it.
"Magic VPN" or "Magic E2EE LAN" kinda IPSEC for commoners, depends on how you config it.
the name reminds me of a paper came across my desk couple of months back: https://arxiv.org/abs/2007.11403 - "Yggdrasil: Privacy-aware Dual Deduplication in Multi Client Settings"
[+] [-] rwmj|4 years ago|reply
[+] [-] WalterGR|4 years ago|reply
https://en.wikipedia.org/wiki/Yggdrasil_(disambiguation)
[+] [-] Tepix|4 years ago|reply
[+] [-] edwintorok|4 years ago|reply
[+] [-] doctor_eval|4 years ago|reply
[+] [-] foobarbazetc|4 years ago|reply
Those were the days.
[+] [-] ddoolin|4 years ago|reply
[+] [-] iou|4 years ago|reply
[+] [-] neilalexander|4 years ago|reply
[+] [-] infogulch|4 years ago|reply
> the root is the node with the lowest ed25519 public key, rather than the highest sha512sum hash of the public key
With this scheme, could a bad actor decide to choose a poor key just to be the neighbor of a target in (edit) keyspace? Ordering by the hash of a public key means that the order is protected by the hash function's preimage resistance; does the generation of a ed25519 key have a similar protection?
[+] [-] habibur|4 years ago|reply
[+] [-] heythere22|4 years ago|reply
[+] [-] nicce|4 years ago|reply
Based on documentation, it sounds that they have some kind of own crypto implementation in the end. I found the whitepaper describing used algorithms, but I would need to know more how exactly they are applied and why they are selected, before I could trust the encryption.
[+] [-] jdsully|4 years ago|reply
[+] [-] foxpurple|4 years ago|reply
[+] [-] neilalexander|4 years ago|reply
It's designed to be as minimal-configuration as possible and scalable in a way that many other mesh routing protocols aren't.
[+] [-] nickik|4 years ago|reply
[+] [-] adamcstephens|4 years ago|reply
[+] [-] Hbruz0|4 years ago|reply
[+] [-] 4bpp|4 years ago|reply
[+] [-] neilalexander|4 years ago|reply
[+] [-] infogulch|4 years ago|reply
[+] [-] rjmalagon|4 years ago|reply
YG uses it own crypto and routing, wintun is used here only to expose the virtual network interface on Windows.
[+] [-] natural219|4 years ago|reply
[+] [-] aleken|4 years ago|reply
[+] [-] boardwaalk|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] musicale|4 years ago|reply
- bandwidth bottleneck at the root
- single point of failure at the root
- any node failure partitions its subtrees
- slow, complicated reconfiguration after node or link failure
[+] [-] wiml|4 years ago|reply
[+] [-] andrius4669|4 years ago|reply
So while usability is pretty similar, they're pretty different underneath.
[+] [-] some_furry|4 years ago|reply
I've never seen anyone need to check the top byte of a nonce before. This looks very odd to me.
[+] [-] jra_samba|4 years ago|reply
Here is the relevant comment/code from Samba.
... switch (xconn->smb2.server.cipher) { case SMB2_ENCRYPTION_AES128_CCM: nonce_size = SMB2_AES_128_CCM_NONCE_SIZE; break; case SMB2_ENCRYPTION_AES128_GCM: nonce_size = gnutls_cipher_get_iv_size(GNUTLS_CIPHER_AES_128_GCM); break; default: nonce_size = 0; break; } x->nonce_high_max = SMB2_NONCE_HIGH_MAX(nonce_size); x->nonce_high = 0; x->nonce_low = 0;Where the definition of SMB2_NONCE_HIGH_MAX is:
#define SMB2_NONCE_HIGH_MAX(nonce_len_bytes) ((uint64_t)(\ ((nonce_len_bytes) >= 16) ? UINT64_MAX : \ ((nonce_len_bytes) <= 8) ? 0 : \ (((uint64_t)1 << (((nonce_len_bytes) - 8)*8)) - 1) \ ))
[+] [-] alophawen|4 years ago|reply
https://en.wikipedia.org/wiki/List_of_names_of_Odin
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] maz1b|4 years ago|reply
What commercial application will this have for an average consumer that isn't tech-savvy?
[+] [-] commandlinefan|4 years ago|reply
[+] [-] rjmalagon|4 years ago|reply
"Magic VPN" or "Magic E2EE LAN" kinda IPSEC for commoners, depends on how you config it.
[+] [-] qxfys|4 years ago|reply
[+] [-] crad|4 years ago|reply
(asking with tongue in cheek)
[+] [-] pharmakom|4 years ago|reply