[Feature] External keypair interface

[neruthes]

Status
Brainstorming

---

Host the keypair of a Persona in external devices (e.g. Yubikey). Maskbook queries the external device to perform signature and decryption operations.

[Jack-Works]

I have considered that feature, I think it is good but maybe hard to accomplish in the current Maskbook architecture.

---

When Maskbook encrypting to people, it needs to do multiple times of encryption (for every recipient, at least 1 encryption), IDK if the user needs to press yubikey N times to complete the process. If so, the UX is not too good IMO.

[yisiliu]

They will need to press the key each time they need to authorize encryptions. We still need to work on our own hardware device to match our needs.

[neruthes]

I see. YubiKey will need to be used O(N) times when decrypting all Recipient-Specific PostKey Envelope payloads. Unless we can implement a feature which allows Maskbook to recognize some feature of the desired Recipient-Specific PostKey Envelope payload before passing it to YubiKey.

I imagine it this way:

• Alice wants to send to Bob and Bob is the one who uses YubiKey.
• Alice adds a RecipientFeature in the Recipient-Specific PostKey Envelope payload.
• The RecipientFeature is calculated through KDF(Alice.pub, Bob.pub, PostIV, ECDH(Alice.pri, Bob.pub)).
• Bob needs to calculate ECDH(Alice.pub, Bob.pri) which is identical to ECDH(Alice.pri, Bob.pub). The Maskbook installation on the machine of Bob can use the metadata of the Post to determine the RecipientFeature for Bob, hence reducing the total attempts of decryption to 1 for YubiKey.
• An attacker knows other input values for the KDF, but cannot get through ECDH, so the attacker cannot get Bob.pub out of the RecipientFeature.

This is based on the following assumptions:

• YubiKey can perform naked ECDH operations.
• Or at least Alice can encrypt the RecipientFeature through standard ECIES, so Bob can try an initial O(N) times to permanentize the RecipientFeature value between Alice and Bob.