gmaxwell
commented
9 years ago In addition to the concerns raised about signing oracles by @paulproteus above:
Generally signing messages in the context of casual conversation is an anti-feature: Usually talking to someone does not create transferable cryptographic proof of what you said... logs of your conversation become liabilities when they can be taken and proven to others (even excerpted out of context for that purpose).
Thoughtful protocols like OTR are design to avoid this: they instead set things up so that each participant is confident of who the other participants are but this confidence is not transferable; logs could have been forged. I'd encourage you to not reinvent the wheel here, but multiple party OTR is not a done thing.
It's likely that a reasonable approximation can be accomplished by generating an ephemeral subkey and signing it, then signing with that; and when all participants acknowledge receipt (or after a timeout) you publish the private key, enabling forgery. This doesn't provide as strong a guarantee as what a good multiparty OTR can do... but it would be better. But I caution thinking very carefully before running with this or any other simple idea. What you're doing here is building a novel cryptosystem, and it's very hard to do this right and not get something wrong in the details which causes meaningful harm to people. Even this kind of half-assed implementation of mpOTR would still have a lot of parts that could be gotten wrong.
max-mapper
paulproteus
mafintosh
beaugunderson
calvinmetcalf
Hi nice moose-team people!
I wanted to file an issue suggesting that you consider using a different private key for message signing as for SSH protocol signing.
@kentonv discusses signing oracles here https://plus.google.com/+KentonVarda/posts/J3vcacmUUc1, which is a problem where if I can get someone to say something in a moose chat, and that message is also meaningful in a different context, now I can show their signed message to someone else and claim they signed something with different meaning in the new context.
TLS 1.3 has some built-in protections around this, and GPG's standard approach is to use sub-keys. I imagine a sensible approach for moose would also to be create a subkey that is specific for the purpose of signing messages in moose.
Note that I haven't dug into the moose code yet, so if you already do create a sub-key for signing messages in moose, OK; please accept my apologies. I'm writing this based on the description I see at moose-team.github.io/friends/ website, which I am hoping is up-to-date.
(I'm also generally a little weirded-out by your remark that it is "secure" at the top of that page, which isn't a super meaningful thing to say without a clear threat model. One example of a great threat model document is this -- https://pond.imperialviolet.org/threat.html -- which reads basically like a collection of user stories, so should be a reasonably approachable thing to write in an aspirational way about the properties you want the software to have. If you want, I can file a separate bug requesting a threat model; I thought I'd merely point out the concept here, and if you feel that's in-scope for the project, great.)
Cheers!