mwarning / trigger

Android app to lock/unlock/ring doors. Supports generic HTTPS/SSH/Bluetooth/MQTT and Nuki Smartlock.
GNU General Public License v3.0
130 stars 22 forks source link

Rework SSH key management #32

Closed mwarning closed 4 years ago

mwarning commented 4 years ago
clach04 commented 4 years ago

For the public key only case, I wonder if https://en.wikipedia.org/wiki/Public_key_fingerprint is appropriate? Those should fit into a QR code as they are much smaller, so hopefully helps/resolves issue #27, then on first connect with the server the real key can be downloaded and then checked to see if it matches, the ssh key in Trigger would then be updated with the real, full key.

In terms of how to do that, either roll your own or use (and/or abuse :-p ) an existing one like openpgp4fpr URI scheme. See https://metacode.biz/openpgp/openpgp4fpr - that also has the option of using the fingerprint to download the public key from a server (at scan time). I believe https://www.openkeychain.org/ has an implementation for this (but I have never used this).

This is a slightly academic suggestion as I don't have any real experience with the fingerprint approach (and this isn't a pain point for me). Not sure what the use cases are here:

mwarning commented 4 years ago

@clach04 you scenario would mean that the server provides the secret key. But that should undermine the use case of public/secret key cryptography. The user needs to create it's own key pair and registers it's public key with the server/door-controller. The fingerprint is needed to verify that the server did indeed received the correct public key. This can only be done by another channel (outside of this app).

Anyway, the key pair management style has been reworked. Let's close this ticket.