* The "incomplete list" of C UB currently points to the Rust spec vision

* The link labelled "unreasonable programming language" currently points to the Gentoo Wikipedia page

* The "Starship" link points to the House Wiki page on Vicodin

I think it's somewhat unreasonable to expect software released today will necessarily work on your environment without some legwork.

Comments URL: https://news.ycombinator.com/item?id=38934701

Points: 2

# Comments: 0

You are expected to complete the project in steps they define (so for their Redis project, step 1 is to bind to a port, step 2 is to respond to a PING command, etc). If you choose not to pay, you can only complete one step per day, even if you submit code which would pass future steps.

This can be quite frustrating, since each step is often very simple, and IMO discourages producing a well-architected solution which anticipates future requirements, as you're left waiting 24 hours to press the submit button for code you've already written.

Still: It's free, and the restricted progress forced me to not use it for procrastination purposes, so there's that.

I think the point is still relevant though: if these are the ASNs connected to a server which you know has 10 active users, for example, then there is still a potential privacy concern.

If you’re from a small town with a local ISP, associating that town with your first name could be enough to specifically identify you, with the help of yellow-pages directory sites. Even just knowing someone’s state or country is a data point that can be used to narrow down their identity. For the privacy minded, this could be very unfortunate.

I’m not sure why you would be publicly posting the ASN from which a user is connecting anyway? Could you explain the context a bit more here?

If a network implements DNS-based content filtering and blocks DOH requests, not responding to a query for this domain could allow an application to know to not bother trying DOH, since it will definitely fail every time.

I could be totally off the mark here, though.

Of course, this doesn’t incorporate any forward secrecy, which is a key benefit of using something like TLS or Noise rather than rolling your own custom protocol.

For symmetric encryption, if you’re recommending Salsa20/ChaCha20, it is absolutely necessary to discuss nonce management, since this is a major footgun people coming from AES may not be familiar with. You should always use the extended nonce variants of these algorithms (XSalsa20/XChaCha20) if possible, with a random nonce for every message. If not, you will have to be certain that nonces are never reused with the same key, possibly through some counter construction. The real solution to symmetric encryption for most people is to use something like Sodium‘s `crypto_secretstream`, which smooths out all the rough edges.

“Use ECC” is too generic as advice for asymmetric encryption. Use Elliptic-Curve Diffie-Hellman for key exchange (X25519 ideally), and then use a symmetric AEAD construction (XChaCha20-Poly1305 or AES-GCM) to actually encrypt messages. For people familiar with RSA, in which the asymmetric construction is actually used to encrypt messages, this is unfamiliar, so explanation is necessary.

I would not recommend just “SHA-2” as the first choice for generic hash algorithms anymore, due to length extension attacks. Use BLAKE2b, SHA-3, or one of the well-studied truncated variants of SHA-2.

Also, I think monocypher was written independently of NaCl, it’s not a fork.