3 ms·

Pitting two well-known security principles (or at least watered-down versions) against each other: "security by obscurity is evil" and "defense in depth". Whic

Pitting two well-known security principles (or at least watered-down versions) against each other: "security by obscurity is evil" and "defense in depth". Which trumps here? Should the public keys be printed in every phone book, just because it says "public" in the name? Or should they be kept semi-secret, since publishing them could lead to them being factored offline?

akerl_ 11y ago
Defense in depth doesn't conflict with "security by obscurity is evil": Defense in depth is that I keep my private key secured with a passphrase, on an encrypted volume, and that I take measures to protect against applications having access to it unless they require it. It's the layer of physical security where I don't leave my laptop where it's easily accessed, and everything else that goes into securing a workstation. Defense in depth recommends having multiple layers of security, such that a breach of a single layer doesn't constitute a full breach. There's no requirement (and in fact I'd argue there's no solid recommendation) for including obscurity as one or more of the layers.
- kelnos 11y ago
  The parent may not have used the best terminology, but the point still stands: your "defense in depth" example utterly fails to protect your private key if your public key is widely-available and easily-factorable. If I didn't have my public key on GitHub, it's unlikely that even that could fall into an attacker's hands. Not that I would rely on that assumption, but it would reduce my attack surface.
  - akerl_ 11y ago
    If you think there's a chance that public RSA (lets not even get started on ed25519) keys of reasonable size are easily-factorable, there's a lot of groups out there who'd love to make you rich or lock you up.
    - dragonwriter 11y ago
      > If you think there's a chance that public RSA (lets not even get started on ed25519) keys of reasonable size are easily-factorable, there's a lot of groups out there who'd love to make you rich or lock you up. I think that's more accurate if you replace "think" with "can actually practically demonstrate".
- scintill76 11y ago
  What if, in 10 years, 1024-bit keys are factorable in <10 days on commodity hardware? I could call that a "breach of a single layer." If 1024-bit keys have been widely publicized, it turns into a "full breach", because the defenses weren't deep enough. If the keys had not been publicized, then the entire 1024-bit key space has to be iterated online in order to find weak keys. Now, of course the user can take some responsibility for not upgrading their key in 10 years, etc. I don't see why it's, like, some moral obligation to invite factoring attacks just because of the name of the key and knee-jerk hatred for "obscurity." Put another way, it makes sense to avoid pure obscurity when adding it takes extra work. In this case, GitHub is going out of their way to add theoretical weakness, but apparently we must do it, because security bible!

akerl_ 11y ago

Defense in depth doesn't conflict with "security by obscurity is evil": Defense in depth is that I keep my private key secured with a passphrase, on an encrypted volume, and that I take measures to protect against applications having access to it unless they require it. It's the layer of physical security where I don't leave my laptop where it's easily accessed, and everything else that goes into securing a workstation. Defense in depth recommends having multiple layers of security, such that a breach of a single layer doesn't constitute a full breach. There's no requirement (and in fact I'd argue there's no solid recommendation) for including obscurity as one or more of the layers.

kelnos 11y ago
The parent may not have used the best terminology, but the point still stands: your "defense in depth" example utterly fails to protect your private key if your public key is widely-available and easily-factorable. If I didn't have my public key on GitHub, it's unlikely that even that could fall into an attacker's hands. Not that I would rely on that assumption, but it would reduce my attack surface.
- akerl_ 11y ago
  If you think there's a chance that public RSA (lets not even get started on ed25519) keys of reasonable size are easily-factorable, there's a lot of groups out there who'd love to make you rich or lock you up.
  - dragonwriter 11y ago
    > If you think there's a chance that public RSA (lets not even get started on ed25519) keys of reasonable size are easily-factorable, there's a lot of groups out there who'd love to make you rich or lock you up. I think that's more accurate if you replace "think" with "can actually practically demonstrate".
scintill76 11y ago
What if, in 10 years, 1024-bit keys are factorable in <10 days on commodity hardware? I could call that a "breach of a single layer." If 1024-bit keys have been widely publicized, it turns into a "full breach", because the defenses weren't deep enough. If the keys had not been publicized, then the entire 1024-bit key space has to be iterated online in order to find weak keys. Now, of course the user can take some responsibility for not upgrading their key in 10 years, etc. I don't see why it's, like, some moral obligation to invite factoring attacks just because of the name of the key and knee-jerk hatred for "obscurity." Put another way, it makes sense to avoid pure obscurity when adding it takes extra work. In this case, GitHub is going out of their way to add theoretical weakness, but apparently we must do it, because security bible!