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.
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.