Ian Kluft

Thanks, great question!

In short: I got obsessed by making it as fast as possible and read a ton of elliptic curve cryptography papers.

It was a journey that started from reading WireGuard kernel sources, then I was thinking about deriving IPv6 address from peer key, left a random comment on a dated gist https://gist.github.com/artizirk/c91e4f8c237dec07e3ad1b286f1855a7 from which I learned about vanity key concept.

I naturally enjoy doing performance optimization work so when I discovered incremental approach idea here https://github.com/warner/wireguard-vanity-address/pull/15 I decided to create my own tool.

I've implemented first version of https://github.com/AlexanderYastrebov/wireguard-vanity-key and then continuously profiled it to improve performance. From profiling I saw that field inversion and multiplication are the main operations.

I realized I need to reduce unnecessary computation to make it faster and for that I need to understand the underlying math which is actually quite simple.

I read RFCs for Curve25519 and papers from D. J. Bernstein who invented it.

You can see how my understanding evolved from the commit history https://github.com/AlexanderYastrebov/wireguard-vanity-key/commits/main/

Once I have the fastest algorithm to generate vanity Curve25519 keypairs I can apply it to other things that use Curve25519 (https://ianix.com/pub/curve25519-deployment.html) or Ed25519 (https://ianix.com/pub/ed25519-deployment.html) which is an equivalent…

"libsodium" is just NaCl with autoconf cruft added.

NaCl does not use autoconf nor even make.

It is not necessary but if someone really feels compelled to use it, why stop them?

I have never seen any author or end user comment that they dislike using autoconf, or write alternatives to it. Autoconf is loved by all, isn't it?

I think what you could say is that using NaCl in your own software is the only way to get good at using it. Maybe the existence of libsodium means that more developers will have a go at using NaCl? Is it easier to use than an SSL library? The only way to find out is to try both and compare.

There is no need to use autoconf to build libnacl.a. The original build system for NaCl is beautifully simple. But if someone misses autoconf and make, then libsodium has added in those dependencies.

More projects using NaCl:

http://ianix.com

As far as I can tell, the authors listed on the above site are not "rolling their own crypto" for their projects, they are using cryptography written by the author of NaCl.

Personal bias disclosure: I find NaCl easier to use than all the SSL libraries I have tried. If I am not mistaken, I believe this was a design goal by the author.

> DNSSEC does one task extremely well – but it does only this one task:

DNSSEC ensures that the information the operator of a
domain[..] put into DNS is the exact same information
that a user gets out of DNS when they request info for
a domain.

Even this is not true. DNSSEC is an abysmal protocol. To quote from [1]:

DNSSEC suggests a complicated mechanism to essentially re-create many of the
same problems with X509 and CAs in DNS itself, by providing a chain of trust
to untrustworthy entities. Its intended goal is to secure DNS and thereby
assure clients that when they ask for apple.com, they are actually visiting
apple.com. This proposal does not protect against MITM attacks [2]. It suffers
from extreme and unnecessary complexity, a systemic fault that's antithetical
to secure systems. See also this list of resources on why DNSSEC is considered
harmful [3].

[1] http://okturtles.com/#oktvs

[2] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/

[3] http://ianix.com/pub/dnssec-outages.html

This seems like a weird benchmark, reading from /dev/urandom and gzipping random data does not seem like something most folks will want to do. It even appears like /dev/urandom speeds differ greatly on various architectures [0] and there are issues with /dev/random being fundamentally slow due to the entropy pool [1] (but I guess this is why the author uses /dev/urandom).

It would be better to measure something more related to what docker users will actually do, like container build time of a common container, and/or latency of HTTP requests to native/emulated containers running on the some container.

One reason to feel positive about the virtualization issues is that Rosetta 2 provides x86->ARM translation for JITs which an ARM-based QEMU could perhaps integrate into it's own binary translation [2].

[0] https://ianix.com/pub/comparing-dev-random-speed-linux-bsd.html
[1] https://superuser.com/questions/359599/why-is-my-dev-random-so-slow-when-using-dd
[2] https://developer.apple.com/videos/play/wwdc2020/10686/

More specifically most people do not use it on the client end-point. It's used by some resolvers which could be ones ISP DNS, some rando upstream DoH/DoT DNS, or a local DNS daemon on ones home network. To your point I disable it on my network for the lack of people signing their domains. It's one less thing that goes wrong [1].

Though to donselaar's point there will be governments and I suspect eventually fin-tech that will be regulated into signing and that's great especially for B2B/Gov2B connections that could use an extra form of verification. No harm in that. Optional for me, mandatory for more sensitive things and they are powerful enough to put pressure on DNS providers to make DNSSEC less error prone with time. Maybe once it has more adoption and is less error prone I may re-enable it.

[1] - https://ianix.com/pub/dnssec-outages.html

I'm assuming you have 2FA turned on already.

It sounds from what you're saying like you (and at least a few other hacker news posters) want is an even stricter "no seriously, I promise I won't ever screw up" mode.

We try not to have those kinds of modes, because (for example):

https://ianix.com/pub/dnssec-outages.html

It turns out, black and white security models lead to massive losses of availability when people screw them up - and people do. Though I have to confess to being amazed to see Tony Finch amongst the recent "oops". NASA is maybe not so much of a surprise.

Having said that - if there's enough demand, that would be a worthwhile feature. Accounts that aren't being used are cheap for us to run, and that flag would make the security team's job really easy - just say "no, go find your own way in" without having to review anything!