
Snow – A layer 3 virtual network that uses public keys instead of IP addresses - fiatjaf
https://github.com/zrm/snow
======
purp
A sweet hack, and full marks for humor in the FAQ.[1]

    
    
      Q: Is it secure? 
      A: Security is not binary.
    
      Q: OK, how secure is it? 
      A: It seems like you just asked that question.
    
      Q: No, the first question was if it's secure, 
         the second question was how secure is it. 
      A: Well now that wasn't even a question at all. 
         Tell you what, if you find an unreported security 
         vulnerability I'll buy you a beer.
    

[1]
[http://trustiosity.com/snow/faq.html](http://trustiosity.com/snow/faq.html)

~~~
fallat
Personally I find this really unsettling for non-technical users. Almost
asshole-ish. It's funny to us...but _seriously_ providing a real answer after
all that would even be sufficient. Not just answering with a "yes", but with a
little blurb on how it is secure.

~~~
noja
Non-technical users are not reading github pages.

~~~
bitcoinbelle
Well that's not true at all.

~~~
0xdeadbeefbabe
Yes it is; non-technical users can't read. How mean of you to suggest
otherwise.

------
AaronFriel
This is similar to what I thought IPv6 IPsec should have been, auto-generated
addresses: where address generation uses the hash of a public key. Sure, the
addresses would have to be longer (in a /48, you only have 80 bits of choice),
but if IPv6 were longer to accommodate strong hashes, it would solve much of
the problem of secure computer-to-computer communication in a decentralized
way.

Right now, IPsec practically requires PKI. But at Google or Amazon's scale,
PKI is far from an easy problem, distributing keys to millions of nodes must
be painful. And auditing the system must be its own level of hell, as I doubt
many internal PKI systems attempt to manage devices at that scale. Unlike a
smartphone or a laptop, where you can rely on 2-factor authentication, a
server must be single-factor authenticated. The server is the server, and that
places a huge burden on correctly allocating certificates.

And then there's the chicken and the egg problem: if you want to deploy PKI to
millions of existing servers, how do you do that and ensure every server is
what it says it is? There's too many shaky links of trust involved for a
system like that to stand up.

I really like this idea, it's in many ways better than the idea I had about
IPv6, because it uses the DNS layer to advertise public keys. It's inarguably
more extensible, to boot. My idea would fix IPv6 into a single standard for
IPsec, this is much more flexible.

~~~
derefr
I'm pretty sure this is already in IPv6:
[https://en.wikipedia.org/wiki/Secure_Neighbor_Discovery](https://en.wikipedia.org/wiki/Secure_Neighbor_Discovery)

~~~
AaronFriel
Hey that's pretty cool! I wasn't aware of this.

------
SomeoneWeird
This seems very similar to cjdns[1]

[1] [https://github.com/cjdelisle/cjdns](https://github.com/cjdelisle/cjdns)

~~~
joeyh
Not realy. cjdns seems to need an invite to get onto its network.

Not saying that's necessarily a bad idea; cjdns seems to be useful to the
people that use it. But if I want to build an app that communicates P2P over
such a network, a manual step to join the network won't fly.

~~~
kpcyrd
cjdns dev here, the network has been opened a while ago. There are some public
peers floating around.

There's nightfall[0] to find/announce public peers, but I consider it very
beta (quickly hacked together on a bus trip).

[0]:
[https://github.com/kpcyrd/nightfall](https://github.com/kpcyrd/nightfall)

------
zrm
I can answer more questions later today.

The project is in the middle of a partial rewrite. The existing DHT has
several issues and I'm replacing it.

The change is going to break compatibility, which made it into a much bigger
change because it provided an opportunity to make several other compatibility-
breaking changes. So I haven't been promoting the project recently and the DHT
bootstrap node is currently offline.

There should be new code some time around the end of summer.

------
joeyh
I gave this a quick try, as I've been looking for something like this that
works for several years.

Looks like the DHT used for NAT and resolving .key addresses is not currently
online, at least my (very well connected) test machine wasn't able to connect
to the 1 pre-seeded DHT peer.

Anyone gotten it to work outside of a single machine and ideally thru NAT?

------
caffeineninja
Interesting, but I can't immediately think of any real-world use cases that
this solves that aren't already solved with existing technology. The docs
don't really describe anything beyond "automatic NAT traversal and end-to-end
encryption with no configuration". No configuration? Not entirely true. :)

What are some use cases this can be applied to?

~~~
lucb1e
Connecting two computers.

IP addresses (normal, unicast ones) like 1.2.3.4 and a9c::890 are meant to
reach a computer somewhere on the Internet, through any number of routers.
Routers are meant to forward IP packets until they reach their goal.

Try it with your neighbor's computer, it's not going to work. Did he enable
DMZ or port forwarding? Alright, that works when your neighbor is home. Now
try it when your neighbor is at work. His IP address changed, so there goes
the reachability. This seems like "duh, obviously," and you're right. But I
just want to perform the fundamental action of connecting two computers.

I personally used Tor to solve this problem: run a hidden service on one,
connect to the .onion address on the other (you can configure ssh to work with
.onion addresses).

This public key system would solve the problem in a much better way, without
going through Tor. Not that Tor is bad, it's just not meant for this.
Connecting the two machines directly without thinking about the intermediary
network is what I wanted.

~~~
alistproducer2
im still wondering how a intermediary dns-like server is not needed to perform
the public key to ip address translation?

------
gruez
Wouldn't it be better if the address was the hash of the public key? That
would significantly reduce the size of each address (great for UX).

~~~
y0ghur7_xxx
> Wouldn't it be better if the address was the hash of the public key?

It IS the hash of the public key...

\-----[snipsnip]-----

This is a public key hash:

aaaac6rxjmmenb7m5txgpe3nmmrrh4z4ohcr7sxqkrvbk4csbrrorpw7.key

Snow lets you use it like an address...

\-----[snipsnip]-----

~~~
kalmi10
Yeah, no.. Gruez meant the actual IP(v6) address.

@gruez, The length of an IPv4 address would not allow for a future-proof-
enough address length. IPv6 might just do it, I can't say.

@y0ghur7_xxx, Let's say I want to expose some snow-unaware service via snow to
only a single host. I have no way to set up an iptables rule to do that atm.
"When you resolve a key name an address is assigned to that key. The address
remains assigned to the key as long as there is traffic, but never for less
time than the TTL on the DNS record and never for less than 5 minutes (and
generally for much longer than that)."

------
jokoon
So it's a DHT, so it's decentralized, pretty nice, but I still don't
understand the purpose of this. Is this trying to improve security ? If so,
how ?

What I'm more interested in, is a protocol that can let people share data on a
DHT, which is resistant to denial of service and other security issues. I
guess freenet is that already (somehow), but it's really not usable.

There are so many things in bitcoin I'd love to see in other standards,
especially for messaging and forums. It would make things so much harder for
the NSA and advertisers.

~~~
lucb1e
> but I still don't understand the purpose of this. Is this trying to improve
> security ? If so, how ?

For my answer to this, see my comment elsewhere in this thread:
[https://news.ycombinator.com/item?id=9844987](https://news.ycombinator.com/item?id=9844987)

------
cordite
Is there a paper or something that describes how this works?

As fun as trudging through supposedly secure C++ code is, I'd rather have an
understanding derived from the principles.

------
Hyperborian
Interesting. Reminds me of CJDNS:

[https://en.wikipedia.org/wiki/Cjdns](https://en.wikipedia.org/wiki/Cjdns)

------
lewisl9029
Does this or CJDNS have any mechanisms in place to limit metadata exposure?

From what I could gather, both use public DHTs for routing, and AFAIK public
DHTs in general can be rather trivially crawled for metadata.

The current generation Internet already offers plenty of methods to protect
message contents, but very few can also obfuscate metadata, which can be just
as revealing, but almost always much more readily accessible.

~~~
mirimir
You can run this through a VPN with a port forwarded for UDP. And that VPN can
be tunneled through a nested chain of VPNs. That provides some metadata
obfuscation.

------
misterdata
Interesting, and similar to Telehash [1]. Main benefit over Telehash seems to
be that it can 'just work' with existing applications.

[1] [http://telehash.org](http://telehash.org)

------
qimfgh8ny7w
Snow's author is also the user "zrm" here on HN.

[https://news.ycombinator.com/item?id=8231026](https://news.ycombinator.com/item?id=8231026)

------
rakoo
The main problem with using a public key as your identity is that once it is
leaked, you no longer have an "identity" (or more exactly, it's not uniquely
you). There is no way you can change your identification without changing your
identity.

~~~
zrm
> The main problem with using a public key as your identity is that once it is
> leaked, you no longer have an "identity" (or more exactly, it's not uniquely
> you). There is no way you can change your identification without changing
> your identity.

The main problem with using a public key as your identity is that it's a
horrible string of gibberish that people can't remember. What you want is some
way of mapping some friendly name to your key.

But you can resolve friendly names to keys however you like. You can update
that mapping however you like. That is orthogonal to what snow does.

~~~
rakoo
True, you could have a bunch of SRVs in your DNS that redirects from
_snow._tcp.my.best.friend.snow to aaa<..>.key or bbb<...>.key. You can even
expire your keys after any amount of time for free thanks to DNS. Hey, that
actually looks like a nice thing to add to snow !

~~~
zrm
It already supports CNAME. You can do example.com CNAME aaa<..>.key. SRV is on
the todo list, not least because it also lets you look up the IP address and
port in DNS as an alternative to the DHT.

------
exabrial
Basically someone did what IPV6 should have.... Congrats!

------
nly
So if i'm following this right, querying the builtin DNS server for a .key
actually triggers DHT lookup and NAT setup? That's a cunning hack.

How are NAT entries recycled? Also couldn't SNI be used here to do this via a
single IP?

~~~
zrm
> So if i'm following this right, querying the builtin DNS server for a .key
> actually triggers DHT lookup and NAT setup?

That's the idea.

> How are NAT entries recycled?

DNS responses have a TTL. The mappings last at least as long as the TTL and
get extended if any traffic is sent to the address or there is another name
lookup. After there is no traffic for a period of time the address goes back
into the pool.

> Also couldn't SNI be used here to do this via a single IP?

SNI is HTTP. Doing it this way works with other protocols too.

~~~
nly
SNI isn't just for HTTP. It's basically just a field in the TLS handshake that
tells the server what name the client is interested in.

I can't think of a way to make this compatible with the DNS method you're
using now though... you'd need a new address class that only ever returns a
fixed IP by DNS, which was used exclusively for alternative determinations of
the .key name requested. You could do this for TCP/80 with the HTTP Host
header and TCP/443 with SNI, for instance. I'm wondering if one way to do it
would be with haproxy to avoid having to implement this yourself.

Since a lot of connections going over Snow are going to be HTTP or HTTPS, this
might make sense, at least for IPv4 where you IP space is limited.

~~~
zrm
You're right that SNI is part of TLS rather than HTTP. It's the same trouble
though. Most applications don't support TLS+SNI.

The way Tor does it is to use a SOCKS proxy. Then you don't need an IP address
and it's protocol-agnostic but the client application has to support SOCKS.

I'm not sure address space limitations are even a major problem. Address
assignments are local, not global, and there are millions of RFC1918
addresses.

For HTTP you have to solve it from the other side anyway. An HTTP server would
be more likely to run out of addresses than a client would. But running out of
IPv4 addresses is what IPv6 is for. We could even return both IPv4 and IPv6
addresses until the IPv4 addresses run out. Then if you want to burn through
millions of peers you just have to support IPv6.

------
gesman
ARP slow-ish?

But idea is well welcome. Key based address resolution has potential of
obsoleting many types of current DNS attacks.

~~~
api
No ARP. It's L3.

------
hyperion2010
This is amazing. The ability to create private networks from arbitrary subsets
of networked machines without any (serious) restrictions opens up all sorts of
new possibilities. For some reason though the first use case that comes to
mind for me is operating botnets.

------
sudioStudio64
Wow. That's a really cool idea. I'm really interested in where this goes from
a networking nerd point of view.

------
higherpurpose
Cool. Wouldn't it have been better to use Libsodium instead of OpenSSL,
though?

Also a Rust version of this would be nice.

~~~
zrm
I'm very strongly considering replacing OpenSSL with NaCl/libsodium. OpenSSL
is a nightmare.

------
jfischl
I think this is super cool but kinda bummed it is licensed under AGPL.

------
alistproducer2
maybe im missing something, but what is the point of using the public keys if
they need to be mapped to ip? dont u still need dns servers to resolve the ip
addresses?

~~~
purp
You get full encryption end to end, transparent to any app or program on the
box, with next to zero config.

See [http://trustiosity.com/snow/how-it-
works.html](http://trustiosity.com/snow/how-it-works.html)

------
Merkur
seems cool, but what is it good for?

