3 ms·

What are the odds that the private keys for all of the .gov domains are also sent to the NSA? I guess if you are worried about another nation spying on your tra

What are the odds that the private keys for all of the .gov domains are also sent to the NSA? I guess if you are worried about another nation spying on your traffic you would be fine. I would expect that all of this traffic is decryptable by NSA though.

carlosdp 10y ago
I think we can pretty safely assume all information given to the government is in the hands of government agencies, one way or another.
mikeash 10y ago
Would you otherwise have an expectation that your data sent to the government would be kept secret from the NSA?
brainfire 10y ago
I think it's safe to assume that would be impossible to keep secret. The number of people that would need to be "in on it" is huge. I can vouch personally that at least one civilian department doesn't do this.
- EdHominem 10y ago
  Do you really have a policy that would survive an NSA-directed evil-sysadmin attack from any of the participants in your chain of trust? As a civilian branch of the government? It's pretty hard to setup a system that would survive an powerful adversary who simply didn't know your passwords, have access to your safes, etc. But to then make that system hardened against a malicious insider with get-of-of-jail card?!
  - brainfire 10y ago
    It would have to be one of the four people with root. Multiply this by the number of groups that operate a .gov website (it's a lot) compounded by turnover (even more.) And account for the cat-herders needed to organize it and do it every time the private key rotates (no less than yearly for our internet-facing sites.) There are a lot of ways you could do this on a small scale, but you really can't scale up this particular mechanism and keep it secret.
    - EdHominem 10y ago
      > It would have to be one of the four people with root. Or anyone who'd ever gotten access to the computer, or installed a camera near it, etc. The critical part of that answer though, is "one of the". The system fails if any of the individuals is be malicious. A more-robust system would require multiple malicious agents in various organizational silos (security, compliance, management) to fail. > every time the private key rotates Well, if I got in once it probably phones that home for me. > you really can't scale up this particular mechanism and keep it secret Well, it isn't secret. We know the NSA intercepts hardware to muck with it, when needed. Much easier even than planting something in your server room explicitly. Also, they wield NSLs compelling silence and cooperation. It's not like being discovered here or there would stop scare or stop them. It would probably scale pretty well given that this is the extreme; most people just generate keys on the old debian box in the corner.
      - brainfire 10y ago
        > A more-robust system would require multiple malicious agents in various organizational silos (security, compliance, management) to fail. Yes, and at that point the name for it is "policy". These are our own keys after all- nobody would blink an eye if they were supposed to be collected. They're not.
        EdHominem 10y ago
        > They're not. [keys not collected by another agency] Right. I think you're absolutely correct, now. And I fully expect (hope!) that the NSA will one-day come to you with some more-secure hardware and that you will gladly cooperate because as you say - we are all on the same team. My point is that you can't say what you're saying now. You aren't secure, and you don't have the type of procedures that would ever let you get to more than a 4/10 or so. You don't even see having four independent points of failure as an issue, rather than a benefit. By promising people that the NSA does not have your organization's keys you're providing the less technical with a false picture. And maybe, one day, that might matter. You might trick the next leaker into trusting your org as a way to whistle-blow and cause them to be caught by the NSA before they reach the news. > Yes, and at that point the name for it is "policy". [security procedures] Yeah, and software is just automated policy. If this is a zero, and that's a zero, etc... If the guard in the vault runs a non-exploitable policy (ie no "I'm the boss" backdoors) then you can greatly reduce evil-sysadmin attacks.
noahkunin 10y ago
Gov employee here (18F). If the operative word is "sent" and "all" the likelihood is zero, as I can assert I've never sent a private key to NSA, and I've made quite a few over the past few years. That said, carlosdp makes a great point as to how one should behave. Even though not all private keys get shipped to NSA (can't make claims about other teams), the government is very public about other data sharing programs (see https://www.dhs.gov/sites/default/files/publications/privacy/PIAs/PIA%20NPPD%20E3A%2020130419%20FINAL%20signed.pdf https://www.dhs.gov/sites/default/files/publications/privacy... for example). Even though all government agencies must disclose these types of programs, they are so numerous and often so difficult to decipher, the only rational response is to assume everyone has everything or could have access in the future. The only way to avoid this is to build zero-knowledge systems on the server side, something I hope you'll see more of in 2017.
xenophonf 10y ago
What are you getting at? As far as I know, OMB doesn't require key escrow, so it almost certainly doesn't happen at scale. I'd imagine that if an intelligence service asked an agency for keymat, they'd happily provide it. I know that I wouldn't have a problem with someone from old St. Elizabeths Hospital or Fort Meade or Crystal City asking me for stuff, especially since the order to co-ooperate with DHS or NSA or the Pentagon would come through the agency's chain of command. That said, DHS runs an intrusion prevention system called EINSTEIN, whose mission is to protect all federal civilian computer networks: https://en.wikipedia.org/wiki/Einstein_(US-CERT_program) https://en.wikipedia.org/wiki/Einstein_(US-CERT_program) Using EINSTEIN _is_ mandated by OMB, so if you're worried about the U.S. federal government snooping on your communications with the U.S. federal government, I don't know what to tell you.

carlosdp 10y ago

I think we can pretty safely assume all information given to the government is in the hands of government agencies, one way or another.

mikeash 10y ago

Would you otherwise have an expectation that your data sent to the government would be kept secret from the NSA?

brainfire 10y ago

I think it's safe to assume that would be impossible to keep secret. The number of people that would need to be "in on it" is huge. I can vouch personally that at least one civilian department doesn't do this.

EdHominem 10y ago
Do you really have a policy that would survive an NSA-directed evil-sysadmin attack from any of the participants in your chain of trust? As a civilian branch of the government? It's pretty hard to setup a system that would survive an powerful adversary who simply didn't know your passwords, have access to your safes, etc. But to then make that system hardened against a malicious insider with get-of-of-jail card?!
- brainfire 10y ago
  It would have to be one of the four people with root. Multiply this by the number of groups that operate a .gov website (it's a lot) compounded by turnover (even more.) And account for the cat-herders needed to organize it and do it every time the private key rotates (no less than yearly for our internet-facing sites.) There are a lot of ways you could do this on a small scale, but you really can't scale up this particular mechanism and keep it secret.
  - EdHominem 10y ago
    > It would have to be one of the four people with root. Or anyone who'd ever gotten access to the computer, or installed a camera near it, etc. The critical part of that answer though, is "one of the". The system fails if any of the individuals is be malicious. A more-robust system would require multiple malicious agents in various organizational silos (security, compliance, management) to fail. > every time the private key rotates Well, if I got in once it probably phones that home for me. > you really can't scale up this particular mechanism and keep it secret Well, it isn't secret. We know the NSA intercepts hardware to muck with it, when needed. Much easier even than planting something in your server room explicitly. Also, they wield NSLs compelling silence and cooperation. It's not like being discovered here or there would stop scare or stop them. It would probably scale pretty well given that this is the extreme; most people just generate keys on the old debian box in the corner.
    - brainfire 10y ago
      > A more-robust system would require multiple malicious agents in various organizational silos (security, compliance, management) to fail. Yes, and at that point the name for it is "policy". These are our own keys after all- nobody would blink an eye if they were supposed to be collected. They're not.
      - EdHominem 10y ago
        > They're not. [keys not collected by another agency] Right. I think you're absolutely correct, now. And I fully expect (hope!) that the NSA will one-day come to you with some more-secure hardware and that you will gladly cooperate because as you say - we are all on the same team. My point is that you can't say what you're saying now. You aren't secure, and you don't have the type of procedures that would ever let you get to more than a 4/10 or so. You don't even see having four independent points of failure as an issue, rather than a benefit. By promising people that the NSA does not have your organization's keys you're providing the less technical with a false picture. And maybe, one day, that might matter. You might trick the next leaker into trusting your org as a way to whistle-blow and cause them to be caught by the NSA before they reach the news. > Yes, and at that point the name for it is "policy". [security procedures] Yeah, and software is just automated policy. If this is a zero, and that's a zero, etc... If the guard in the vault runs a non-exploitable policy (ie no "I'm the boss" backdoors) then you can greatly reduce evil-sysadmin attacks.

noahkunin 10y ago

Gov employee here (18F). If the operative word is "sent" and "all" the likelihood is zero, as I can assert I've never sent a private key to NSA, and I've made quite a few over the past few years. That said, carlosdp makes a great point as to how one should behave. Even though not all private keys get shipped to NSA (can't make claims about other teams), the government is very public about other data sharing programs (see https://www.dhs.gov/sites/default/files/publications/privacy/PIAs/PIA%20NPPD%20E3A%2020130419%20FINAL%20signed.pdf https://www.dhs.gov/sites/default/files/publications/privacy... for example). Even though all government agencies must disclose these types of programs, they are so numerous and often so difficult to decipher, the only rational response is to assume everyone has everything or could have access in the future. The only way to avoid this is to build zero-knowledge systems on the server side, something I hope you'll see more of in 2017.

xenophonf 10y ago

What are you getting at? As far as I know, OMB doesn't require key escrow, so it almost certainly doesn't happen at scale. I'd imagine that if an intelligence service asked an agency for keymat, they'd happily provide it. I know that I wouldn't have a problem with someone from old St. Elizabeths Hospital or Fort Meade or Crystal City asking me for stuff, especially since the order to co-ooperate with DHS or NSA or the Pentagon would come through the agency's chain of command. That said, DHS runs an intrusion prevention system called EINSTEIN, whose mission is to protect all federal civilian computer networks: https://en.wikipedia.org/wiki/Einstein_(US-CERT_program) https://en.wikipedia.org/wiki/Einstein_(US-CERT_program) Using EINSTEIN _is_ mandated by OMB, so if you're worried about the U.S. federal government snooping on your communications with the U.S. federal government, I don't know what to tell you.