Support for modern SSH Ciphers, Keyex and MACs

[pshelly]

Hi thanks for taking the time to make this project, I use all the time.

In regards to SSH I think all users will benefit by the support of modern ssh standards.
Specifically:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-256

[daquexian]

Personally I think it might be better to replace jgit with cgit for modern features(modern ciphers, proxyjump and so on)

[msfjarvis]

Personally I think it might be better to replace jgit with cgit for modern features(modern ciphers, proxyjump and so on)

Do you have a link for cgit? My googling is only bringing up the C web frontend for git.

[daquexian]

@MSF-Jarvis hi :) By cgit I mean the git which is common on pc and can be cross compiled for android

[msfjarvis]

@MSF-Jarvis hi :) By cgit I mean the git which is common on pc and can be cross compiled for android

ahh, brainfart. Thanks.

[aguestuser]

+1 to supporting this. i just tried to migrate my password repo github to a self-hosted gitlab instance and i can no longer sync due to failed algorithm negotiation (where the failure is because the gitlab instance only supports modern cyphers).

[fmeum]

I did a deep dive into potential options for us and thought that it would be a good time to document and discuss our options, either for v1 or v2.

1. Use an up-to-date JGit with the well-maintained mina-sshd backend.

   • Has the advantage of having a rather sane API that e.g. would greatly simplify the OpenKeychain integration.
   • Requires moving to Oreo as the min SDK
   • Android is not even an afterthought, so we would likely need to patch the source code to get it to run on Android Pie and above, see https://github.com/stepinto/android-sshd/blob/master/apache-sshd-patch.diff. Some additional hacks are needed, such as mocking javax.* classes, but I think that I have figured those out.

2. Start using the NDK to integrate libgit2 and libssh2.

   • Has the advantage of not affecting our min SDK.
   • Building on Android is part of the README
   • Requires writing Java-to-C bindings. Luckily, we are not a full-featured Git client.

3. Build and run cross-compiled git.

   • If we get it to work, it should be very convenient to use as it would just be a bunch of Runtime.exec calls.
   • Based on this discussion with a Google insider, calling native binaries delivered in the APK is likely safe for the foreseeable future.

4. Use SSHJ with our legacy version of JGit.

   • This requires implementing a custom backend, probably using the one for mina-sshd as an example.

If there should be any other potential options, please let me know.

Regarding the issue of SSH key generation: We can either keep Jsch for this or just write it ourselves, it's quite easy for the two key types we would care about ("ssh-rsa" and "ssh-ed25519").

Edit: Added option 4, which I will look into a bit more. If somebody has already figured out 3 once, it's probably our best bet though.

[msfjarvis]

I'm not very comfortable with the 3rd idea. It's just a matter of time when Google Play starts doing takedowns at random over it and I don't need to reiterate what stupidity ensues after that.

Option 4 and option 2 both look great, though I have a slight inclination towards the former citing my general aversion to working with C, even if it's for JNI bindings.

[fmeum]

I went over the codebase of SSHJ and am positive that this is our best option.

Implementing a JGit backend that supports public key and password authentication is relatively straightforward thanks to SSHJ's well-designed API. We could also enable host key verification along the way without too much effort. This I could probably code up when I have the time.

OpenKeychain support is likely doable, but requires some trickery. For every SSH key type, we would need to implement fake PrivateKey subclasses and a factory that produces implementations of Signature that perform the actual signature verification via the OpenKeychain API. This definitely requires a non-trivial amount of work, in particular it would mean handling UI thread calls from within JGit. For that, we would probably need to run JGit operations in a coroutine on the IO thread and use runBlocking(Dispatchers.Main) in the Signature methods to launch activities via a passed-in context and wait for their results.

[msfjarvis]

Sweet! Would wrapping up the PgpActivity breakdown help with this? I'm more than happy to invest extra time in getting it done if it's gonna make it easier for you.

[fmeum]

Sweet! Would wrapping up the PgpActivity breakdown help with this? I'm more than happy to invest extra time in getting it done if it's gonna make it easier for you.

For now I would just try to prototype a drop-in replacement for the current password/pubkey flow. When we have gained some experience with it and it does work for users, we could think about the steps needed to also replace the OpenKeychain flow.

[fmeum]

I got trust-on-first-use host key verification and public key auth via all supported SSH key types (in particular ssh-ed25519) working on my local branch (https://github.com/FabianHenneke/Android-Password-Store/tree/fhenneke_sshj).

I have also switched the SSH key gen over to use the Android Keystore as opposed to a simple key file, but importing key files is of course still supported. As a proof of concept, I have added support for P-256, as well as the usual choices of RSA-2048 and RSA-4096. With a key stored in the Android Keystore, we could do away with the key file passphrase and rely on fingerprint/device unlock instead.

Note that so far this requires patching SSHJ, but only in a minor way (see hierynomus/sshj#586). I hope that the PR is accepted into upstream.