1
$\begingroup$

I'm working on a messaging service that lets users author messages and have them signed with an RSA key. The key is used for identity purposes only and can be revoked, so compromising the private key is annoying, but does not expose proprietary information.

Still, in order for a service to sign on behalf of a user, that user must either provide the key's passphrase (or even the key and passphrase) and have it go over the wire on each signing, or the key is stored by the service without the user's passphrase.

In either case the service itself must be trusted since at some point they will have access to the key in an unprotected form.

So the question is, what is the better design (other than "don't do it"): require the passphrase on each signing event, or rely on the service to store the key without the original passphrase and require them to ensure safe keeping (using their own passphrase, encrypt it otherwise, etc). Or is there a third way by which the service can sign on behalf of the user without exposing the private key at all?

Clarification: The idea is that the user maintains portability of their identity, i.e. they could use their key to sign and publish messages themselves or provide the key to a new authoring service they pick instead, i.e. the key follows the user, not the service.

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ Let me see if I have this straight. Every use has a public and private key. But they won't sign messages themselves, instead the server signs the messages. $\endgroup$
    – mikeazo
    Aug 9, 2012 at 17:07
  • $\begingroup$ "require them to ensure safe keeping" of what? $\:$ $\endgroup$
    – user991
    Aug 9, 2012 at 17:18
  • $\begingroup$ @mikeazo Correct. I want messages that can be authenticated as unaltered and originating from a specific user, but provide this as a simple authoring experience from a web app. Messages are passed in a heterogenous system, i.e. the authoring service isn't the authority to vouch for identity. The underlying ecosystem is described here: claassen.net/geek/blog/2012/07/… $\endgroup$
    – Arne Claassen
    Aug 9, 2012 at 17:21
  • $\begingroup$ @ricky safe keeping of the private key. I.e. if the web service is compromised, the key shouldn't be persisted in unencrypted form. $\endgroup$
    – Arne Claassen
    Aug 9, 2012 at 17:22

1 Answer 1

Reset to default
2
$\begingroup$

Store the key encrypted. Send the encrypted key to the user and have them decrypt it and sign the message. Whatever your objections are to this scheme, they are most likely either misguided or can be addressed by the implementation of the scheme.

Improve this answer
$\endgroup$
3
  • $\begingroup$ The objection would be usability with the intended audience being non-technical. Unless I can get a pure javascript way of executing the decrypt/signing on the client side, it's a non-starter. $\endgroup$
    – Arne Claassen
    Aug 10, 2012 at 2:16
  • 1
    $\begingroup$ What's the problem with getting a pure JavaScript way of decrypting/signing on the client side? (Punch things like 'JavaScript RSA' into your favorite search engine and you'll find dozens of implementations.) Make sure to serve the JS over SSL, of course. $\endgroup$
    – David Schwartz
    Aug 10, 2012 at 2:29
  • $\begingroup$ thanks for that link. I'd found the version on github and it didn't work and i couldn't make it work, but that one does work. That does open up a much better approach then. $\endgroup$
    – Arne Claassen
    Aug 10, 2012 at 5:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.