4 ms·

I think you are not talking about the same thing that the rest of us are talking about. I see three locations or context involved: 1. The public area - meaning

I think you are not talking about the same thing that the rest of us are talking about. I see three locations or context involved: 1. The public area - meaning anyone has access. 2. The application context (server, etc) -- should be a "secured" location, meaning few people or processes have legitimate access, and measures should be taken to prevent unauthorized access. The private key should never be present in location 1, public area. The public key is expected to be available here. However, the problem would not be that the keys are together, but that the private key is available here at all, paired with the public or not. To be clear: I am saying the private key should never be available in context 1. The typical assumption in most scenarios is that context 2 is secure, and by that I mean secure enough to house the private key. After all, the actions taken in context 2 usually require the private key. So it is reasonable to say that we consider this area secure enough to house private keys, and then take adequate measures to protect it. In this case, if the public key is also stored here it is irrelevant, as the public key is already available in context 1. If you have made the decision that context 2 is safe enough for the private key then there is no reason not to also store the public. However, we have seen that in a typical deployment scenario context 2, the application context, is often compromised. This leads us to create context 3: 3. Dedicated secure key storage. This often comes in the form of an HSM or similar device. See http://en.wikipedia.org/wiki/Hardware_security_module http://en.wikipedia.org/wiki/Hardware_security_module The purpose of having an HSM is that instead of doing the cryptographic work (which requires the private key in clear) in context 2 , you send a work request to the HSM saying, "Here is the data I need you to work on, here is the cryptographic operation I need performed, and here is the private key identifier representing the private key I want you to use," the HSM performs the crypto operation, and returns the result. Importantly, the private key is never known outside the HSM. Even in this situation, there is no reason not to also store the public key in the HSM. In fact, it is very common to store both the public and private key parts in the HSM so that you can use the same API in your code (the key id) to reference both. Many crypto APIs have limited or no support for cryptographic operations using a key supplied from the outside (outside the HSM). This is on purpose. So often you have to keep the public key in the HSM too if you want to use the HSM for the crypto. > It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless. No. No. No. It is true that you must publish the public key for others to use it, but that does not mean you cannot also store it in the secure location. As I have explained above it is often required that it also be present in the secure location. > This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key. No. You are not understanding what you are reading. I am saying that anyone who has access to the private key also has access to the public key, so there is no reason not to store them together in the secure location. I'll say it again: If you have the private key, you might as well have the public key. You would never distribute the private key. Period. And just because you store the public key in the same secure location as the private key does not mean you have to give everyone access to that secure location. You could, I don't know, make a copy of the public key to distribute by itself.

jmillikin 13y ago
> The typical assumption in most scenarios is that context > 2 is secure, and by that I mean secure enough to house > the private key. 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. > I am saying that anyone who has access to the private > key also has access to the public key, so there is no > reason not to store them together in the secure location And I'm saying that you don't want someone with access to the public key to also have access to the private key, so they must not be stored in the same location. Do you see the difference? 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.
- prodigal_erik 13y ago
  Putting the private key somewhere that antagonists could read it was insane. The fact that the public key was also there didn't do any extra harm, and removing the public key wouldn't help at all. Any attacker has (or can get) your public key, because anyone interested can, that's its purpose.
- jdbernard 13y ago
  > 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"

jmillikin 13y ago

> The typical assumption in most scenarios is that context > 2 is secure, and by that I mean secure enough to house > the private key. 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. > I am saying that anyone who has access to the private > key also has access to the public key, so there is no > reason not to store them together in the secure location And I'm saying that you don't want someone with access to the public key to also have access to the private key, so they must not be stored in the same location. Do you see the difference? 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.

prodigal_erik 13y ago
Putting the private key somewhere that antagonists could read it was insane. The fact that the public key was also there didn't do any extra harm, and removing the public key wouldn't help at all. Any attacker has (or can get) your public key, because anyone interested can, that's its purpose.
jdbernard 13y ago
> 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"