I'm a different commenter but yeah, solutions exist. For example systemd-cryptenroll let's you use a FIDO token (or TPM or PKCS#11 smartcard) to unlock your encrypted disk and it's very easy to set up. Quite literally a single command.
Windows Hello serves the same purpose for Windows, though I'm sure there are caveats/differences.
If it's a fido hardware token you still need to make sure you have a backup token. It's a lot simpler on windows/macos where you can use biometrics for the same purpose.
I have used this to send signed/encrypted mail to a ProtonMail recipient. It worked, until he responded inline without encrypting it to my private key, thereby completely defeating the point.
(Later I informed him of how to automatically sign and encrypt outgoing mails to my account, as that is possible too, but not obvious at all.)
PM should make the more obvious, but in principle the interoperability is there and works.
In my personal experience, people from Latin American countries will sometimes point out that they are American because they come from North or South America.
Which is, of course, true; however, in English conversation, it's often nothing more than pedantry. In Spanish it makes more sense, since there is a separate demonym for a US person that doesn't co-opt the term "American."
Outside of Romance language speakers born on the American continents, I agree that everyone seems fine calling US-born persons "Americans" without much confusion nor gnashing of teeth.
It’s even more amusing in some ways. A common way to refer to those from the USA in Brazil, for instance (even an official one!) is ‘Norte Americano’.
Which is all kinds of weird because - what about Mexico and Canada? And what about the ‘United states’ part?
It’s just to disambiguate from ‘Americano’ as in what others in South America sometimes use to refer to latin Americans and as a little bit of a FU to the USA, hahah.
Ahh, I forgot about that...and to be transparent, I actually have no idea what French Guyana, Haiti, or Belize typically do to differentiate between people of the American continent(s) and US persons. I should have said Hispanoamerica, but oh well.
> I actually have no idea what French Guyana, Haiti, or Belize typically do to differentiate between people of the American continent(s) and US persons.
In French, people from the Americas are américains. This includes, say québecois and Brazilians. When context matters, people from the US are états-uniens.
Probably because the US are much more mentioned than other American countries. But that’s not really the point, though. People from the US are américains, they’re part of the group of people living in America (which, in French and when it is not qualified, refers to all of them, North, Central, and South).
The point is that nobody would object if you refer to someone from anywhere else in the Americas as américain. Like my lab mate from Buenos Aires or friends from Montréal. And we’re definitely not in Haiti.
I think wary would have been a better word, but I really did mean "weary", as in I would find the ordeal tiresome or bothersome? I wouldn't disagree if you said that's bad grammar still.
Hey, I recognize your username, I bought RCU this year because I wanted to encrypt my reMarkable without losing data. I could have used the cloud or whatever, but I found your software and chose it because it is local-only and FOSS. Also reasonably priced.
Thanks for your work! I have enjoyed RCU and now use it regularly for backups, file transfer, etc. I'm glad to hear that it seems to be sustainable.
The idea (outlined in the QubesOS documentation) is to clone the git repo of their website, verify the PGP commit signatures, then render the website yourself. Then you can be reasonably sure the website is legitimate, modulo a DoS attack stopping you from receiving updates to the website code, I suppose.
Getting the correct PGP public key appears to be an exercise left to the reader, but if you are already running e.g. Fedora, you can view the packaged QubesOS distro keys distributed by your current OS, cross-reference that with a second source such as a PGP keyserver, and unless you're being Mossaded upon you're probably good if they match.
No, GP is misinterpreting Windows's message. It prompts for a recovery key because the TPM is bound to, among other things, Secure Boot == enabled. When Secure Boot is disabled, the TPM notices that and refuses to release the key, that's how you know to reënable Secure Boot or throw away your device.
The fact that Windows is compromised does not make it capable of extracting secrets from the TPM, though maybe a naïve user can be convinced to enter the recovery key anyway...
> When Secure Boot is disabled, the TPM notices that and refuses to release the key, that's how you know to reënable Secure Boot or throw away your device.
But the attacker isn't trying to get the key from the TPM right now, they're trying to get the credentials from the user. It's the same thing that happens with full disk encryption and no TPM. They can't read what's on the device without the secret but they can alter it.
So they alter it to boot a compromised Windows install -- not the original one -- and prompt for your credentials, which they then capture and use to unlock the original install.
They don't need secure boot to be turned on in order to do that, the original Windows install is never booted with it turned off and they can turn it back on later after they've captured your password. Or even leave it turned on but have it boot the second, compromised Windows install to capture your credentials with secure boot enabled.
How suspicious are you going to be if you enter your credentials and the next thing that happens is that Windows reboots "for updates" (into the original install instead of the compromised one)?
So this attack is to steal my Windows password or Windows Hello credentials, but doesn't get my encryption key...? That's...not ideal, but I think you'll see it's an improvement over unencrypted disks (again, TPMs are for people who can't be bothered to set a strong password).
And again this presupposes that you can disable Secure Boot, boot a malicious OS from another drive, fool the user into entering their password, automatically reboot, enable Secure Boot, boot into the legit OS, then come back later and have the ability to boot the OS yourself and log in as the user (because again, you don't have the decryption key, you have the user's login credentials).
You are also presupposing what the TPM is bound to. I don't use Windows, but using systemd-cryptsetup I could configure a TPM to bind to the drives in the system; in this way, it will refuse to boot my legit OS while your malicious disk is installed (well, it will demand a recovery key). Again, setting off alarm bells, and if I discover the disk with my recorded credentials before you can physically access it, I can just destroy it.
> And again this presupposes that you can disable Secure Boot, boot a malicious OS from another drive, fool the user into entering their password, automatically reboot, enable Secure Boot, boot into the legit OS, then come back later and have the ability to boot the OS yourself and log in as the user (because again, you don't have the decryption key, you have the user's login credentials).
But that's the same thing that happens with full disk encryption. They come get physical access to the machine but don't have the decryption key yet so they compromise the unencrypted part of the machine which is what prompts you for it, have that capture the key when you enter it, and now they have the key when they come back to use it.
If anything allowing the short password is even worse, because if you leave your machine in suspend you expect it to prompt for your unlock password but not the full disk encryption key when you come back, so the latter would be suspicious but the former doesn't let them unlock the disk, and now you're using the short password for both.
> You are also presupposing what the TPM is bound to. I don't use Windows, but using systemd-cryptsetup I could configure a TPM to bind to the drives in the system; in this way, it will refuse to boot my legit OS while your malicious disk is installed (well, it will demand a recovery key). Again, setting off alarm bells, and if I discover the disk with my recorded credentials before you can physically access it, I can just destroy it.
Except that it doesn't need to be installed once you're at that point. By then it has already captured your credentials and stored them or sent them to the attacker over the network, so it can disable that device right before it goes to boot into the original operating system.
Also notice that the original premise was to make it easy for ordinary users and now the workaround is to install Linux and change a setting that will confuse people as soon as they leave their own USB stick plugged into their computer.
> >A server that I want to turn back on all by itself after a power outage can only be done securely with a TPM.
> Can you describe how this prevents a MITM attack? I assume you mean a remote server? I've heard of colocation setups like this, but I think they rely on a couple of unstated assumptions.
I'm not sure what you mean by prevent a MitM attack, unless you're worried about someone with probes MitM-ing your TPM-CPU connection in the DC.
You can bind a TPM to measurements on the host (let's say for argument's sake you want Secure Boot state, Option ROM state, and UEFI state), then configure the OS to ask the TPM for the (or rather, a) decryption key during boot.
The TPM will check that the state(s) you bound to is (are) the same as when you bound them, and if so it will give the OS the key. Your disk is encrypted, but the boot process is automatic/unattended, as well as completely contained within the server chassis.
There are ways to attack this hypothetical setup, buuuuut there are ways to attack remotely entering your disk password as well, and bear in mind that denial of service is a security vulnerability. Tradeoffs.
Windows Hello serves the same purpose for Windows, though I'm sure there are caveats/differences.
reply