super-io

"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.

I do not use DHCP. (Nor do I use ARP.) For a small home network I do not need it.

I run a private root and a private nameserver that serves encrypted DNS packets from a datacenter. "Pseudo authoritative": the zone contains the third party addresses I need. All DNS queries are encrypted. Sent from localhost resolver to private nameserver. Nothing in the clear. That is how it works.

There will always be metadata gathering on the internet (access logs). But there does not have to be unencrypted (DNS) packets or third party DNS resolvers.

Folks in this thread claimng to be using IPv6. Anyone using cjdns? Best use of IPv6 I have heard about so far.

In hash function competitions, are the authors of the function allowed to vote for their own entry?

"... but the operator of that resolver..."

The operator of the resolver cache is supposed to be the user, not some third party (e.g., OpenDNS/Cisco, etc.).

IOW, the cache is meant to be running on the user's computer not some third party computer (e.g., OpenDNS/Cisco, etc.).

Using remote (i.e. third party) recursive resolver caches has never been recommended. If anyone is recommending that then they are ignoring the advice of the original author.

(There are other reasons to use a local cache, even if not to encrypt outgoing queries, e.g., it reduces/eliminates the risk of cache poisoning.)

If you look, you may find there are implementations that did follow the author's advice, e.g., a resolver that only accepts queries from 127.x.x.x.

What is missing to have a complete encrypted DNS solution? Authoritative nameservers that implement the system.

The recursive part of the system already works. It is controlled locally by users.

Authoritative nameservers for www sites however are run by third parties. Cooperation is needed.

As for TLS, there may be an alternative encryption solution forthcoming. Similar to encrypted DNS, it will be a small program running on the user's computer that encrypts outgoing packets. An ssl wrapper sort of like stunnel but better. It will not rely on establishing an "encrypted tunnel" like TLS. It will encrypt each packet separately.

Correction: The above draft was not the one I was thinking of. Here it is:

http://www.ietf.org/archive/id/draft-luotonen-ssl-tunneling-...

Like NetBSD but for mobile.

Easy to port.

Is it true the "Android" project rose from the ashes of an earlier company "Danger" who produced a NetBSD based mobile OS for the T-mobile Sidekick?

If true, why did founder of Android use NetBSD for the Sidekick, not Linux?

Microsoft acquired Danger.

"You know if you ever got me, you wouldn't have a clue what to do with me." - Being John Malkovich (1999)

Maybe easier just to collect on Android sales via threatened patent assertion. IDK.

"... but what about when your ISP literally edits your web traffic, inserting more ads, and possibly breaking webpages."

It is possible the ISP not only injects ads but injects unique identifiers that the user never sees. These could be used to track the user across different devices and networks. This possibilty was suggested a few years ago by a well-known cryptographer in a presentation titled "How to manipulate standards".

"First your website uses SNI..."

s/uses/may use/

Not every website uses SNI.

For example, the majority of sites linked to from HN do not use SNI.

Also, there are workarounds when SNI is not supported. Workarounds have been published by one major corporation who authors a popular web server software and runs a cloud hosting service.

Is SNI "the only way to do it"? No. There is another way to do stream encryption for mlutiple websites from one IP. It predates HTTPS. This idea goes back to one of the original authors of the world's first web server at CERN. The legacy of this idea survives today as the Websocket "Upgrade" header. Links to further reading below.

Because of groupthink dynamics among today's standards committee people and website owners who follow along, it appears that any online discussion of alternative options to SNI is met with swift dismissal.

http://www.ietf.org/rfc/rfc2817.txt

http://www.ietf.org/rfc/rfc2818.txt

The draft below refers to proxies but further searching will find papers he wrote about how to start an encrypted stream upon connecting to an HTTP server. Any service could sit behind one simple HTTP interface. This idea was revived in "Upgrade" header referred to above. Then forgotten as HTTPS became popular. Then revived again for "Websockets".

http://www.ietf.org/archive/id/draft-luotonen-web-proxy-tunn...

SNI is not the only solution, it is just one approach, and I suspect the next-generation encryption (a TLS alternative that will be readily adaptable to PQ) will not need to send domain names in the clear.

"At a minimum, my ISP can not see or tamper with DNS requests."

Are you encrypting each DNS packet at the source (e.g. your home recursor/DNS-forwwarder)?

If yes, when are your sent packets decrypted? At the authoritative nameserver, or at some intermediary recursor?

If no, how do you believe that your DNS packets are opaque and tamper resistant?

There are very few authoritative nameservers on the internet that accept and return encrypted DNS packets. Thus third party recursors must send out unencypted DNS packets. Nothing protects these unencrypted packets from being captured, viewed or tampered with.

It sounds more like you are creating a chain of recursors (that you control?) to make tracing the requests more difficult.

If you are using any third party recursors are you concerned about applications you use that implement support for ends-client-subnet extensions?

For many years BSD has allowed mounting NTFS partitions read-only.

One project even allows isolating the kernel driver in userspace.

And then there is third party software, e.g., ntfs-3g.

I sometimes see these '$'-prefixed files when I mount NTFS partitions. They never crashed BSD. But maybe it is possible.

Wondering if Windows 10 partitions still mount in BSD without any problems?

Not scared? Okay. Here's how to download...

I have had a great user experience with all his other software except one[1]. Thus I was not scared. High learning curve, but high reward.

1. A FORTH he wrote for IOCCC. Problems compiling probably due to my own stupidity.

What needs to be done?

It still works.

If it anything like his other programs I would expect it will continue to work for as long as we live.