"Bugs", QKD, Matrix, UpCloud

1. One lovely thing about writing proper integration code is that 99% of reports that the integration isn't working correctly are false. It's either undefined case, change requirement or something else in the long processing chain failing. - This is at least something I can feel good about.

2. No, not my stuff actually, just read an long article about: Quantum Key Distribution (QKD) (@Wikipedia) over hollow-core fiber (HCF) and new nested anti-resonant nodeless hollow-core fibre (NANF).

3. Some organizations isolate people, use pseudonyms, require only on-topic discussions and any things wont ever be discussed outside the monitored official channel. - So, they don't know whom to talk about it safely outside that environment.

4. Lot's of discussion about Matrix and E2EE vulnerabilities in article - Disclosing CVE-2021-40823 and CVE-2021-40824: E2EE vulnerability in multiple Matrix clients (@ matrix.org). I personally say that the key sharing is very important feature and essential for well working multi-device, especially if some sessions are short term sessions. In theory the dehydration could help with this in future, but I still find cases where the key sharing is very beneficial. Another option of course would be forwarding the messages when requested more or less automatically. This could lead to bit smaller exposure, because currently the same key can be used to decrypt multiple messages. Yet it's not that much different, if the sharing is automatic, and happens in background in mass. Different key, same result? What's the benefit? - These were my initial thoughts before reading the article and related comments. Let's see if any of the comments does change any of my mind about the initial state. 

5. Thoughts about related comments: Most of discussion was slightly out of scope. Basic is e2ee needed and should keys be verified. Well, yeah, classic. Should servers be trusted and so on. But there was something really useful, Arathorn's comment mentioning: MSC2732: Olm fallback keys (@ GitHub) - Which is nice implementation afaik. Yet question remains, if there's been a forgotten device key for 10 years, which hasn't been online since that. Should we still encrypt everything for that device or not? Especially using the single fall back key. To me that sounds like a potential problem, which could be even worse than key sharing. Yet naturally this kind of stale device and key should be deleted as soon as possible. Ability to automatically kick out idle devices #10813 (@ GitHub ), awesome. After all the comments were worth of reading.

6. Comments about the wording of the document they were referring to: "The recommended strategy is to share the keys automatically only to verified devices of the same user. Requests coming from unverified devices should prompt a dialog, allowing the user to verify the device, share the keys without verifying, or not to share them (and ignore future requests). A client should also check whether requests coming from devices of other users are legitimate." - I actually laughed about that when I read it the first time. It's not mandatory, so we can ignore it. Should doesn't mean anything to developers. - And I did write about that a long time ago. It's kind of funny that the problem was related exactly to this part.

7. The Hitchhiker’s Guide to Online Anonymity (@ anonymousplanet.org). Very nice generic guide for your to read, privacy, pseudonyms and anonymity, and lots of related information. Don't forget to check out Privacy Guides (@ privacyguides.org).

8. UpCloud (@ upcloud.com)  bumped default password strength from well, short I would say, to much better length. Default values omitted, but this is significant improvement. I were wondering why they use so weak password. But of course the default assumption was that every sane user would immediately change the password. But as admins know, it's not going to happen. Or if they do change the password, they might even change it with much weaker one. Which luckily isn't the case with me. Also SSH keys are now used by default, unless password is especially selected by the customer. As well as naturally with "root VPS" you can change whatever you like after the setup. But as mentioned, probably 99% of users wont change anything.

2022-11-27