opheliate

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.

@gavinhoward Just FYI, a couple of links in the article are broken:

* 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

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.

Much of your traffic is probably passing through Hurricane Electric servers already, given their position on the backbone (https://he.net).

An operating system from 2018 which is no longer maintained by its vendor? https://www.linuxmint.com/rel_tara_cinnamon_whatsnew.php

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

The Vercel IPv6 feature request & surrounding discussion makes for frustrating reading: https://github.com/orgs/vercel/discussions/47

Dismissing the Summa Theologica as “borderline schizophrenic nonsense” makes me believe you’re just trolling here.

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?

The author of Leptos has some great YouTube videos talking about Rust for the front-end, especially the performance aspect: https://youtube.com/@gbjxc

Ah of course, sorry, teaches me to speak without thinking.

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.

I could be totally off the mark here, though.

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.

I’m not crazy about this guide to be honest.

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.

AES-CBC with a random IV and solid HMAC should be fine, but the point is that, for a non-cryptographer, putting together an authenticated encryption construction yourself has potential footguns. Using a pre-made authenticated encryption construction like AES-GCM or Salsa20-Poly1305 avoids this.

Any platform with hardware acceleration for AES should hopefully have a carryless multiplication instruction anyway, so GCM will be fast. And if not, Poly1305 is so fast that another HMAC construction will perform worse. So there’s really no reason not to just use one of these two in 99% of cases.

Be very careful when infusing your own oil. Botulism is a real concern, it is often necessary to soak your aromatics in a citric acid solution before infusing.

It’s probably worth remembering this is a pre-print of the paper. This is the kind of thing that would be corrected when actually published.

Haha yeah, I remember a friend of mine from Seoul coming to visit me and looking with wonder at the stars in the night sky. It’s so easy to take these things for granted.

The kind of interception that is being discussed here is the interception of DNS queries which would return an NXDOMAIN result to instead point to an advertising page. This is done by a lot of ISPs.

Yep, plus I know a lot of my friends using Spotify login using Facebook, which displays their full name & profile photo. Also followers/following lists are public, so if you can find a close contact of theirs who is less serious about opsec, you're that much closer to their actual identity. This is only really relevant to the truly paranoid who try to use a different identity for every service.

This kind of thing has always seemed quite interesting (and worrying!) to me from an OSINT perspective. It seems like if you just know a couple of some anonymous person's favourite songs from various genres, you could identify possible Spotify accounts they may also own. As far as I can tell, it's basically impossible to discuss anything remotely personal online without jeopardizing pseudonymity.

You're moving the goalposts to a separate issue: The post you're reply to was specifically talking about children receiving medical treatment to address gender dysphoria, not the possibility of a child experiencing gender dysphoria in general. If a teacher feels a child could be unsafe if they expressed they were trans to their family, they might encourage them not to tell them. But the teacher would not have input on any medical decision, that's up to families and healthcare providers.

Might be worth updating this with the latest from Wikidata: It looks like Elliot Page [0] is listed under his birth name, with the wrong gender too. Just one example, but also I’m sure other things have changed :)

0: https://en.m.wikipedia.org/wiki/Elliot_Page

Amongst all the made-for-YouTube content that others have mentioned, it's also worth remembering that many universities will publish entire courses for free. Christof Paar's Introduction to Cryptography lecture series [0] comes to mind for example, as does MIT's Missing Semester [1].

Also, if you're interested in Rust at all, Jon Gjengset is great: https://www.youtube.com/c/JonGjengset

0: https://www.youtube.com/channel/UC1usFRN4LCMcfIV7UjHNuQg

1: https://www.youtube.com/c/MissingSemester