There have been horrible implementation flaws in RSA too. For all we know, we're a survey away from finding tens of thousands of factor collisions in RSA keys. I really don't think it matters much whether you use RSA or DSA.

I think the intuition was more that RSA is a simpler algorithm to understand and implement, so the "goof surface" is lower. But yeah, someone somewhere will screw up everything.

It's actually the opposite. RSA is more complex and has more failure modes; the discrete log problem that DSA/DH/ElG use is about as simple as it gets.

Again: I don't think it matters. The Debian fiasco was a devastating fuckup in the core of the most important Unix crypto library, did not just affect DSA, and didn't itself have anything to do with DSA.

Not sure I follow. DSA requires a modular inverse algorithm which RSA doesn't (beyond that both are reliant on modular exponentiation and prime generation as the only "hard parts"). DSA has more algorithm parameters. It's just a more complicated scheme to implement any way you slice it. DSA requires more "units of mistake", and is more likely to be screwed up by the programmer.

I agree that it doesn't matter though.

Ah, I see where you're coming from. I have a mental shorthand that basically says "DSA is the one that works like DH", and you're right, you need the inverse for DSA.

But regarding failure modes, I'm thinking of (as a starting point) things like:

  http://www.ams.org/notices/199902/boneh.pdf

There are a lot of implementation errors that happen with RSA. What's a comparable list for DSA? Failure to generate good nonces, and then...?

> don't use agent forwarding ever. If you know better, be damn sure you are right

I am curious. Why do you say this? My use case for agent forwarding is during automated deployment. Without agent forwarding, when pulling from SVN, I either need to enter password every time or have my private keys uploaded to the server where I want to deploy.

You probably need to rethink the security characteristics of your deployment architecture. You shouldn't be authenticating from a production host (which is presumably internet-facing, and thus more likely to be compromised), you should be pushing to it from a more protected source like a build machine behind a firewall.

Using agent forwarding in this case is precisely the problem being discussed. If someone roots your web server (or whatever it is), they can authenticate as your ssh account to any host that accepts it. So at a minimum your subversion server will be compromised if any of the production hosts are. Bad.

> You probably need to rethink the security characteristics of your deployment architecture.

I'm wiser now :). Although till I don't move to a push model, I think I will explore the restricted keys as suggested by ryan-c and use them.

Unfortunately, none of the one shot deployment systems point this out. Most of them do a git pull on production. When I built mine, I wanted to avoid putting my private keys up on the production, so I went with Agent Forwarding.

Anyone with access to your account (this would include root) on a machine which you have forwarded your agent to can use it to authenticate as you. For your use case, the least evil option would be to set up an SSH key that is restricted on the SVN server to only be able to do an svn export.

Public keys, surely?

Sorry if I am missing out the sarcasm here :) but I did mean private keys since I am trying to authenticate from the prod machine to the source control server.

Then you're a fool! Generate new private keys on the PROD server and upload them.

I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.

> Generate new private keys on the PROD server and upload them.

How is that any more secure then agent forwarding? The vulnerability with agent forwarding needs some work and right timing to be exploited after the prod server is rooted. Having a set of private keys lying around is offering access on a plate.

>I don't know if you can do it with your SCM, but a better solution would be the source control server to push to PROD rather than the other way round, as it prevents attacks from a compromised PROD server.

Yes, I am wiser (or less foolish if you prefer ;-) ) now. One can always fall back to rsync and friends if the SCM lacks.

Having specific keys for specific purposes is more secure because when you add the public half of it to your SVN server, you put the extra options along with the key that limit the server it can come from, and the command it can execute. This means that your seemingly-scary private key can now do one thing and one thing only - pull from svn. Now you can do deployments without any constraints like "abhaga needs to be awake and have his computer on and be SSHed to the right places" :)

A voice of reason. This article was terrible.