Bignum cryptography is more dangerous than block cipher cryptography and (in secure systems) invariably depends on hash functions anyways (they're the worst of both worlds). The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true.
Meanwhile, the utility of public-key cryptography in SSO systems is minimal. Public key is useful, and sometimes the only viable solution, when you have a potentially unbounded population of verifiers or signers. But that's never the case in SSO schemes, which have a bounded number of cryptographic participants (or, if they don't, are badly broken).
Long story short: public key crypto is a last resort for systems that can't be deployed in any other way.
The idea that public key algorithms are "more secure" than "shared-key" (symmetric, block cipher core) cryptography is exactly the opposite of true.
That seems backwards to me. How is having one key that can sign things be less secure than having multiple? If someone pwns a box with the shared key, they can forge credentials. If someone pwns a box with the public key, they can't. I would make sense to me that you'd want the important key that can be used to sign credentials in as few places as possible.
After fielding a custom-cryptography single signon system for your Ruby applications, you think your biggest concern is "how well will the system survive the loss of one of my app servers to an attacker"? Let me help you out with that: you won't survive the loss of one of your app servers. You're going to have to rebuild and rekey everything.
No, the biggest concern you have doing custom-cryptography for your Ruby apps is that the cryptography itself is going to hand attackers control of your app servers. Which, from experience, is somewhat likely. More likely if you haplessly use RSA or DSA.
Obviously you're going to rebuild compromised servers and change all the keys... as soon as you find out you've been hacked.
What about before then? You're advocating a scheme whereby if any verifier is compromised, the attacker can forge tokens. This isn't the case with a system that uses asymmetric crypto.
You're going to have to re-key because as soon as you got hacked the security of your SSO scheme is likely nil. When you find out about has nothing to do with anything.
In any case, no part of block cipher crypto requires every pair of participants to share the same key --- even in the unlikely even that you needed all-pairs keys (virtually all SSO systems have a star topology).
The idea that a system is going to resist forgery because it uses public key cryptography would be amusing if it wasn't so common. In reality, cryptography does not work the way _Applied Cryptography_ says it does; it works more like the way _Cryptography Engineering_ says it does. In other words: it conspires at all points and at all times to fuck you.
I take it you're being sarcastic, but the negative comments you're receiving are I think because you departed from giving advice on implementation and strategy, and attempted to give a piece of cryptographic advice.
The only way anyone gets to imply that public key crypto is less secure, or more dangerous, without being challenged, is if a new attack is presented. Otherwise it's all innuendo and handwaving.
Most apps and sites may not derive any advantage from public key crypto, but you can't say that for sure until you see a site (or SSO multi-site) design.
That didn't really answer my question, and you're changing the argument. You said, paraphrasing, "public key is less secure than shared key", which doesn't really make sense, for the reasons I already mentioned. Saying its all irrelevant because my app is already insecure is totally orthogonal to this sub-thread.
Meanwhile, the utility of public-key cryptography in SSO systems is minimal. Public key is useful, and sometimes the only viable solution, when you have a potentially unbounded population of verifiers or signers. But that's never the case in SSO schemes, which have a bounded number of cryptographic participants (or, if they don't, are badly broken).
Long story short: public key crypto is a last resort for systems that can't be deployed in any other way.