Governments could bribe or steal from certificate authorities (CAs) to host a copy of the website while your device still says it’s encrypted and secured. Then they can change that key (random looking characters) on the website, which is used for encrypting information so that only the journalists can decrypt what you sent for confidentiality, but if the government changes it to their own key then they can decrypt it and catch you. Having it physically printed means now they’d have to change that too somehow, which is much harder and especially hard to target only to specific people so nobody finds out they were trying to spy.
That is not a viable attack. You can verify keys. Modern encryption is robust. A modified key would not be able to decrypt anything encrypted by the publisher. The key would be obviously fake to anyone who tried to verify it. And if the publisher found out about this, they have the means to get the word out they’re literally a news organization.
Governments are probably tracking the downloads of keys. That’s the much more reasonable threat from keyservers. If they can prove you had access to sensitive information, and downloaded the public key of the journal that published it, they’ve got you. Printing the key mitigates that risk.
I’m pretty sure that’s a key for encrypting a message to the publisher, not decrypting a message from the publisher, so you can’t verify via decryption. However, you can verify the key via the physical print, which is the point of it.
Both keys can be used to encrypt files that only the other key can read. When sending encrypted messages you generally encrypt with both the sender’s private key, and the recipients public key, so that the recipient can decrypt the document, but they can also know it was sent from who they expect.
You verify the public key by decrypting something encrypted by the private key.
So the government MitMing you can know it’s from you? I don’t think that changes anything. There’s still nothing stopping a MitM from just changing the key shown at the bottom of the page and then reading whatever you send.
You <-cert for x sign by ca (fake, gov control)-> gov.spy <-cert for x sign by ca-> x (optional)
To x look like gov.spy is you, gov.spy like proxy. And gov.spy can try force your device connect to gov.spy instead x (dns poison, isp force ip redirect, …). Will look like x (domain resolve to gov.spy ip, but cannot know), have valid cert for x, trusted.
For that, the government needs to be in the middle of the communication channel. That would take a lot more than just replacing the key on the keyserver.
Governments could bribe or steal from certificate authorities (CAs) to host a copy of the website while your device still says it’s encrypted and secured. Then they can change that key (random looking characters) on the website, which is used for encrypting information so that only the journalists can decrypt what you sent for confidentiality, but if the government changes it to their own key then they can decrypt it and catch you. Having it physically printed means now they’d have to change that too somehow, which is much harder and especially hard to target only to specific people so nobody finds out they were trying to spy.
That is not a viable attack. You can verify keys. Modern encryption is robust. A modified key would not be able to decrypt anything encrypted by the publisher. The key would be obviously fake to anyone who tried to verify it. And if the publisher found out about this, they have the means to get the word out they’re literally a news organization.
Governments are probably tracking the downloads of keys. That’s the much more reasonable threat from keyservers. If they can prove you had access to sensitive information, and downloaded the public key of the journal that published it, they’ve got you. Printing the key mitigates that risk.
I’m pretty sure that’s a key for encrypting a message to the publisher, not decrypting a message from the publisher, so you can’t verify via decryption. However, you can verify the key via the physical print, which is the point of it.
Both keys can be used to encrypt files that only the other key can read. When sending encrypted messages you generally encrypt with both the sender’s private key, and the recipients public key, so that the recipient can decrypt the document, but they can also know it was sent from who they expect.
You verify the public key by decrypting something encrypted by the private key.
So the government MitMing you can know it’s from you? I don’t think that changes anything. There’s still nothing stopping a MitM from just changing the key shown at the bottom of the page and then reading whatever you send.
Man in the middle:
You <-cert for x sign by ca-> x
You <-cert for x sign by ca (fake, gov control)-> gov.spy <-cert for x sign by ca-> x (optional)
To x look like gov.spy is you, gov.spy like proxy. And gov.spy can try force your device connect to gov.spy instead x (dns poison, isp force ip redirect, …). Will look like x (domain resolve to gov.spy ip, but cannot know), have valid cert for x, trusted.
For that, the government needs to be in the middle of the communication channel. That would take a lot more than just replacing the key on the keyserver.
Internet rely on dns and ip. CA only relevant for internet communication. Take more, but not much more.