If you didn't cancel the credit card you used for linode.com, now is the time

Okay, say you have the following scenario:

1) super secure server which handles only the processing of credit cards, handed off to it through a carefully specified API

2) webserver which talks to that server

Obviously, the webserver needs the public key. There's no reason to delete the public key from the private server, but not really any reason not to.

Now, let's say that, under certain circumstances, system 1 itself needs to add encrypted records. Now you need the key there too. You could 1) generate a different key-pair and track which key touches which, but for records generated by system 1 you're generating a keypair that might as well be a symmetric key, which you've objected to; or 2) you could encrypt those records with a symmetric key, but now you've got additional code paths to audit and maintain; or 3 you could send off a request to an external server but that seems to add more complexity and vulnerability not less. Just using the existing public key to encrypt those records doesn't seem like a bad idea - it's a message to the server in the future from the server now, and messages to someone get encrypted with their public key.

Now, you've got a system where you have the public and private key sitting on the same server (and being used on the same server), and if someone does manage to get into that secure server (never impossible) the description I initially complained about would be equally applicable to this setup as to the setup Linode had.

And the problem was the private key being on the server running the web front-end, and that's what should be criticized. Presence of a public key does not a webserver make.

> I disagree. An application server is, by nature, running a lot of untrusted and unaudited code exposed to a (semi-)public network. It should not be considered trusted, because it will probably be the first system to be compromised in any attack.

And I agree with you for things are are truly high-security, but there are tons of people using PKI in this context 2, because it is not worth it to them to invest in dedicated crypto hardware. I would argue most webservers are in this category. When you spin up a virtual machine in the cloud to be your web server, do you also put together an HSM in your private data center (because you can't really trust a co-location center either) to house the SSL keys? For most people the answer is no. Most web setups have their SSL private key on the same box as their application code, because the web server will need to have access to the private key in order to serve HTTPS traffic.

> you don't want someone with access to the public key to also have access to the private key,

This is false. Specifically, the key pair owner will have access to both by virtue of the fact that they are generated together. So the key owner is a "someone with access to the public key [who also has] access to the private key". To be clear:

  1. *Everyone* has access to the public key.
  2. The key owner has access to the private key

Therefore, the key owner has access to both the public and private keys. Therefore it is safe for the owner to store the public key alongside the private key. You do not want everyone with access to the public key to have access to the private key, true. But there is at least one person with access to both: the owner. So it is false to say you cannot store them side-by-side. You can store the public key with the private key in a secure location if you want. You can store the public key anywhere you like. You will need to make the public key available to others outside the secure location so they can use it.

> It doesn't matter if someone can derive the public key from the private key. That's not what's being argued here. The problem is that there is a place where the public key was stored, and Linode also stored the private key there, which is insane.

It is only insane if that place was not secure, and if it was public. We do not that place was insecure or public. All you said was:

> The fact that Linode stored the public and private keys in the same directory is strong evidence that they do not have any competence in security.

The fact that the public key and private key were store together by itself tells us nothing. If they stored the private key in a public place (next to the public key or not), then they are beyond stupid. But that fact the keys were stored together means nothing on its own.

Suppose I have the following:

1. A secured HSM containing both the public and private keys. 2. A public-facing webserver serving the public key.

This is a secure setup, and it is true that "the public and private key were store (sic) together"

Attackers claimed that the keys were stored in memory and that they retrieved them: "We proceeded to breach Linode and acquire their in-memory keys." http://straylig.ht/zines/HTP5/0x02_Linode.txt

Are you sure it is the amex card that supports shopsafe? I thought Amex discontinued their similar product _years_ ago.