stud0709 / OneMoreSecret

Password management based on Android KeyStore, QR and Bluetooth
MIT License
92 stars 2 forks source link

A short question #20

Closed jenspfahl closed 10 months ago

jenspfahl commented 10 months ago

Very interesting concept! But what I don't get is why do you use asymmetric keys? Enc- and decryption happens on the mobile device, right? Why not use a symmetric key instead and expose the key alias? And what is the content of the QR code sequence I have to scan? Does it contain the related key alias and the public key?

stud0709 commented 10 months ago

"Enc- and decryption happens on the mobile device, right?" - No, there is a desktop client as well, and this thing should not be able to decrypt on its own.

The QR is more or less "oms00_......" - the same text you get when you encrypt something on the phone (OK, there is additional information to maintain integrity of the QR code sequence as well).

MessageComposer defines within method prepareRsaAesEnvelope the contents of the header - after that, the AES encrypted data follows (which is specific to the use case aka applicationId). Your "related key alias" is position (3) within the header.

jenspfahl commented 10 months ago

Ok, but for what is the RSA-encrypted AES key needed you send in the message? It looks like encryption inside encryption but if a hacker obtains the RSA private key also the AES encryption is compromised. So where is the advantage here?

stud0709 commented 10 months ago

Yes, if you give away your RSA key (which is hardware-protected on your mobile, the app does not "have" it) - you are screwed.

RSA can encrypt only a couple of bytes. So you generate a random AES key, use it to encrypt your bulk data, encrypt that AES key with RSA, and add it to your data along with the fingerprint of the RSA key required to decrypt the whole thing again as follows:

jenspfahl commented 10 months ago

I see. And the public key can be shared with the desktop app?

stud0709 commented 10 months ago

Exactly, see Key Management

jenspfahl commented 10 months ago

You wrote in Key Management:

If you generated your private key in the app or restored it, and you are using omsCompanion, you will need to share the private key with the latter, if you want to encrypt passwords on your desktop PC directly.

I see it problematic to share the private key. In this case you could also share a symmetric key. Or, as an idea, you generate two key pairs, one for the app and one for the omsCompanion. Then the user only exchanges the public keys. That would be a classic asymmetric key use case.

stud0709 commented 10 months ago

That's a typo :) you share a public key. There is no way to get the public key out of the hardware keystore.

jenspfahl commented 10 months ago

Ah ok. That makes sense. Last question. How does the backup of the private key work? In case I lose my phone?

stud0709 commented 10 months ago

Here is one. If you create a new key, the first thing you get is a backup file like this. You can even print it out if you like.

stud0709 commented 10 months ago

I'll close this one. Feel free to reopen if you have more questions or just write to Discord