And the problem with SSH that was pointed out in the article is funny now because of cloud services where servers are constantly being destroyed, so keys are changing frequently, unless you save and persist that private key for the server in your configuration. Which I’ve realized a lot of companies are simply not doing, which leads to people straight up ignoring key verifications in their ssh config.
At AWS this meant we had to hop to a different gateway for each region, and then onto the (stateless) production host which was recreated from scratch on every deployment... There's no way a human was going to keep all those keys straight, and everyone just disabled SSH host verification.
Normally this is considered rather weak, because of the reliance on DNSSEC. However, in this case I think its a very easy to take step that'll be miles better than just trusting everything.
The stronger alternative is Certificate-based SSH, but that is a lot of hassle. As it requires setting up a CA, handling revocation, and actually distributing the certificates.
Isn't keybase just doing something similar to subkeys for devices?
Keep the master safe, if you need to revoke a subkey, no big deal.
In practice, though, as long as you protect the master key appropriately, the PGP model isn't that much worse (and possibly in some ways better — I'm not sure what happens in the keybase model when one of your devices is compromised, rather than just lost, and you don't notice for a while).
On the other hand, at the company I work for, internal machine certificates/keys are renewed without my involvement (I'm a so-called "IT-owner" of some apps and the infrastructure that the apps use), and therefore I get the warning when connecting to their Linux hosts but each time (few times every few years, but still...) I dismiss it hoping that it's because of the work of the admins renewing the certificates (clarifying who-did-what-when would be a potential major administrative undertaking) => this is absolutely a flaw of the internal processes.
Yes, it could be fixed by a more complex infrastructure, but again, if the internal processes are weak then even the more-complex-infrastructure could be compromised by side-attacks.
With cross-signing, this will get even easier because cross-signed devices will be automatically trusted.
I started testing "Matrix" using the "Riot" app on Android and the web-frontend ~4 weeks ago and so far things look good, which I think is fantastic!!!
I was especially happy to see that I could not read messages posted prior to me entering any encrypted chatrooms => gave me a real "good general feeling".
The "Riot"-app for Android (using it on SailfishOS) is so far quite intuitive and it did never crash so far. Battery consumption is relatively heavy (I used to charge my phone once per week, now it's once every ~3-4 days) but I guess that other users that have more frequently an active Internet connection (because of other apps) will be impacted less.
All in all I'm beginning to think to try to push it to my friends - I think that the first attempt might be to use an encrypted group chat for special themes (e.g. discussions about algorithms, stock market discussions, etc..., all what we do not dare to post in Whatsapp) to have a technical advantage vs. Whasapp & Co. .
It also solves a problem that Keybase has which is that all new devices are automatically trusted (so a compromised device can just register more devices to avoid being blocked). To be fair, this makes for a pretty bad UX -- and the Matrix folks are working on cross-signing to make this easier -- but it is very useful for a user to be able to detect new devices to be detected (especially their own).
because then you just end up with less people on the system, so you'll talk to them over unsafe channels.
keybase's opinion is definitely my opinion so im a little biased there, but so far i can't think of anything that's better than making the reset occurs as rarely as possible by using multiple devices for recovery.
If a new device has shown up, your messages will be blocked from being sent until you verify the new device. To be fair, it is too easy to blaze past the warning -- and it can happen often in large rooms. As a result, it's a little bit cumbersome at the moment, but with device cross-signing coming down the pipe and the new verification system (which is much better than Signal's IMHO -- you just check both devices have the same string of 7 emoji on their screen) it's getting a lot better.