Create subkeys to avoid problems with signature oracles

[moose-team]

Create subkeys to avoid problems with signature oracles

[gmaxwell]

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.

[maxogden]

for reference there is a previous discussion on this issue here https://github.com/substack/cipherhub/issues/2

[paulproteus]

Hi @maxogden,

If what you're saying is that you know that the crypto this project provides is an anti-feature (that is to say, the secure authentication is worse than no crypto at all, and that "you shouldn't re-use a key for multiple things" per https://github.com/substack/cipherhub/issues/2 ), and that you've known that since 2013, then honestly I would prefer that to see this project focus on the UI aspects, and remove the crypto. The UI aspects seem great so far.

Calling it "secure" with a flashy web page when the crypto worsens people's experiences (rather than improving it) seems actively misleading to me. (The site indicates that "secure" means that you "don't use plaintext transports", but that doesn't seem particularly interesting when the featureset of the app is that anyone can join the network and record all fully-signed messages by all parties; since this doesn't provide privacy, nor anonymity, nor secrecy, it's not clear what security property it does provide.)

However, I know it's your team's project, and I still think you're great, and it's free software, and it's a free world! And you can do whatever you want, and that is all OK with me. I figure it's useful to help you see the Friends project from another perspective.

I have very mixed feelings about leaving this comment; I know that you are an upstanding person who wants to do (and does) great things, and I don't wish to de-motivate you or the rest of them (who I don't know, but I'm sure are also great). It seems that your project is a project of joy and a volunteer effort and I wish you the greatest success, however you and the team define it.

I also hope you'll consider engaging with the Liberationtech community, where many people have experience building and revising secure chat apps; you can find that community here. https://mailman.stanford.edu/mailman/listinfo/liberationtech

I can close this comment, since it's not clear that sub-keys are the right approach without some clarity about the threat model. Elsewhere, @gmaxwell reminded me that my sub-key proposal is worse than OTR in that a straightforward implementation of sub-keys would fail to provide privacy.

[mafintosh]

@paulproteus @gmaxwell thanks for the feedback! really appreciate it. friends is still very alpha. does it make sense to use OTR for the public rooms? it would seem sub-key signing would be sufficient enough for authentication in those right?

[maxogden]

@paulproteus sorry, I wasn't trying to say anything to that effect, I was just linking to a previous discussion

[beaugunderson]

just want to thank you for taking the time to share your concerns/knowledge and note that I agree that we should both specify a threat model and clarify the webpage text & README to note that some of the security claims are aspirational (this got public extremely quickly and the crypto/security claims are what people seem to have the biggest reaction to so far)

---

Sent from my phone.

On Apr 29, 2015, at 2:38 PM, Asheesh Laroia [email protected] wrote:

Closed #53.

—
Reply to this email directly or view it on GitHub.

[maxogden]

re: messaging, we should remove any indication that it's an end-to-end encrypted chat app. Perhaps the word 'secure' is too vague, so we should remove it.

[beaugunderson]

+1 removing secure

[maxogden]

done!

[calvinmetcalf]

I wrote a module to do this, we can use it in gh-sign except it uses sha2 to sign the subkey so it wouldn't be usable with ssh-agent which only uses sha1. I can either rewrite it to use sha1 (and accept different params to allow it to be used with ssh agent) or we can prompt for sshkey password in the app.

The module I wrote creates an ephemeral ed25519 key which it signs and keeps in memory, it includes the generated public key and the signature of the key with each signature. So it is dead simple (just have a signature like before) at the cost of signature size.

[maxogden]

For the record I was able to trace SSH2_AGENTC_SIGN_REQUEST to this signing function which is hardcoded to SHA1: https://github.com/openssh/openssh-portable/blob/72ef7c148c42db7d5632a29f137f8b87b579f2d9/ssh-rsa.c#L39 :(

@calvinmetcalf I guess bypassing ssh-agent and prompting for user PW is the correct way to do it, as we could do our own signing that way.

[paulproteus]

For what it's worth, as a prospective user, I would be rather disturbed if moose asks me for my SSH passphrase.​ I do realize that moose can already communicate with my SSH agent, so it can sign things as me anyway. I also realize it is running as my user ID, so it can do anything I can do (including install key loggers, etc.), but anyway, that is what my reaction would be. Since the use of SHA1 here is no worse than SSH's use of SHA1 (since it is literally SSH's use of SHA1), I wouldn't be bothered by the fact that moose uses that supposedly-outmoded hash function. Having said that, I'm still hopeful that the moose project will publish a threat model. Also if comments like this are annoying rather than helpful, please feel free to ask me to quiet down.

[maxogden]

@paulproteus your comments are much appreciated! You raise a great point here. It's probably quite cumbersome and scary to ask for a password for most users.

@calvinmetcalf It looks like openssh won't support anything newer than sha1 for a while, and it's difficult to install newer versions of ssh on e.g. mac osx anyway, so its probably more practical to be compatible with ssh-agent for subkey. But it would be nice to allow the app that uses subkey to choose the tradeoff.

[calvinmetcalf]

ok adding in an signAsync method that defers to a user supplied function
and an verifyAsync which is just sync and assuming sha1, should be an easy
drop in for gh-sign

On Tue, May 5, 2015 at 2:21 PM Max Ogden [email protected] wrote:

@paulproteus https://github.com/paulproteus your comments are much
appreciated! You raise a great point here. It's probably quite cumbersome
and scary to ask for a password for most users.

@calvinmetcalf https://github.com/calvinmetcalf It looks like openssh
won't support anything newer than sha1 for a while, and it's difficult to
install newer versions of ssh on e.g. mac osx anyway, so its probably more
practical to be compatible with ssh-agent for subkey. But it would be nice
to allow the app that uses subkey to choose the tradeoff.

—
Reply to this email directly or view it on GitHub
#53 (comment).

[calvinmetcalf]

@paulproteus the threat model I'm working off of is one similar to say IRC or something like a public email list.

• I don't want anyone to be able to pretend to be me
• I'd like to be sure the person I'm talking to is who they claim
• I don't want spam