I’m shocked to hear that I am apparently living under totalitarianism, and would love to see some concrete examples of this dramatic shift in Labour party policy, rather than vague gesturing.
That isn’t the premise of the article, that is the “common wisdom” the author corrects as the article goes on. The author goes on to list video games as an example of where UDP makes sense, as well as live video.
Was this its raw response to the same query as in the OP? It seems odd it would provide a response using variables named with underscores, rather than using spaces, or more traditional algebraic notation (x/y/z).
Having done a couple of their courses without paying:
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.
Being a current user of Migadu: I’m not sure what they’ve written there is actually correct. When I’ve gone over the outgoing message limit, I’ve received no warning, no 25% margin, and the messages were just dropped, not deferred. I just received an email telling me I had exceeded my account limits.
Good point, I think I misinterpreted the conversation in the second screenshot.
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.
I agree it’s not a TOS violation, but I do think it could potentially be a shitty move to post the ASN from which a specific user is connecting to your service, if they’ve not said it’s okay for you to do so.
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?
Not entirely certain, but I think to some degree this is a way for the network to say, “I will not respect your privacy, so don’t try”.
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.
This kind of attitude strikes me as an excellent way to avoid ever pursuing introspection or self-improvement. Do you have any examples of criticism you’ve received in the past which you would deem worthwhile?
I probably should have said “can be”. The way RSA is often explained just details the mathematics, and explains how a message could be encrypted directly using RSA. It’s then not an unreasonable assumption for a complete beginner that this is how RSA works in practice, even though this is not the case.
The author definitely should have clarified this. The standard is to use ECC for key exchange only. This can be done entirely offline - each party chooses a random secret scalar, and multiplies the base point of the curve by that scalar to produce a public point. You publish your public point in advance of communication. When you want to send a message, you multiply the other party’s public point by your secret scalar to obtain a shared key. Then, just use a well-studied symmetric AEAD construction to encrypt messages.
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.
I think this was copied from Latacora’s cryptographic right answers without some of the necessary context. It’s specifically talking about the KMS offerings from AWS/Google Cloud, which provide trusted hardware implementations of not just key management, but also symmetric/asymmetric encryption, HMAC, etc. All the symmetric constructions provided by these platforms are AEADs, so the point is, if you’re using AWS’s KMS, don’t think about it, just use the default. Which is fairly sensible advice.