[y0ghur7_xxx]

> @Benjojo12 and I are building an encryption tool that will also support SSH keys as recipients, because everyone effectively already publishes their SSH public keys on GitHub.

Is this not already possible with tools like https://ssh-vault.com/ and (shameless plug) https://sshenc.sh/?

Those tools use the RSA keys to encrypt a symmetric key that is then used to encrypt the data, but the outcome is effectively the same. No?

[akerl_]

Don’t those run afoul of the linked white paper (under “dangerous” in the 2nd paragraph), which talks about the attack paths made available if an RSA key is used for signing and encryption?

[y0ghur7_xxx]

I don't think so: neither of those tools sign the message with the same RSA keypair. sshenc.sh for example does not sign the message whatsoever. An attacker could just intercept a ciphertext, drop it, encrypt a different message and send that.

Those tools are not meant for sender authentication. If you want that you would have to first share the senders pubkey with the recipient, and sign your message with the corresponding privkey.

[ptoomey3]

While the tools themselves might not use the same key for both operations, I think the question was asking about whether it is problematic that a user’s SSH keys, used in SSH for signing, are also used by these tools for encrypting. In other words, the concern being the same key is used for two different operations, even if not in the same tool.

As I commented in https://news.ycombinator.com/item?id=19953623, I’d love to see another blog post walking folks through why/how the “dangerous” RSA keys are in fact useable for both operations because the textbook RSA concerns aren’t a concern because of X, Y, and Z.

[tptacek]

The point of the tool isn't to use SSH keys; that's just a nice feature of it. The normal usage for the tool doesn't involve SSH keys at all.

[akerl_]

I don’t know if that’s really the case, given https://docs.google.com/document/d/11yHom20CrsuX8KQJXBBw04s8...

> Goals

> * The option to encrypt to SSH keys, with built-in GitHub .keys support

And lower on the page, it shows the use of built-in command-line syntax for “github:$recipientname”.

It definitely works for keys that aren’t used for SSH, but support for SSH keys seems to be a large part of the rational for the ed25519 support (otherwise it would just be a tool that operated on X25519 keys directly).

[tptacek]

That's true, I'm just saying, the rationale for the existence of the tool isn't "build something that encrypts with SSH keys", but rather, "build a modern replacement for PGP file encryption".