[Demand] Import/Export OpenPGP Subkey and Use OpenPGP to Exchange Message.

[snowyu]

Metadata

Field	Value
Previous Stage	...
Figma Link	figma.com/...
Expected UX prototype due	YYYY-MM-DD
Actual UX prototype release	-
Expected engineering due	YYYY-MM-DD
Corresponding Pull Request	-
Completion Version	-

Catalogue

Make Exchange Security Message across System more easy.

[neruthes]

Let me elaborate why we think OpenPGP is not good for Maskbook later.

[Jack-Works]

It is possible. But Maskbook only supports EC K-256(secp256k1) key.

[neruthes]

Features which are not provided in OpenPGP PKI but needed by Maksbook

• Dual Usage: We use the same key for ECDSA and ECDH, although orthodox practices of cryptography prefer separated management of key life cycle.
• Dynamic Recipient Indication: We define recipients as user groups. The members of these user groups are dynamic; people enter and leave, constantly.

Limitations of OpenPGP payloads

• The public key must be short enough for a profile biography. But the shortest version has 1487 characters.
• The public key must itself be put in the profile biography. A fingerprint is not enough since Maskbook should not rely on any centralized online service.
• Payloads require correct usage of CRLF characters and Space characters. This can be difficult or impossible on certain social networks.
• Payloads are too long. See why we invented Magic URL Payload for Twitter.

[snowyu]

1. The OpenPGP supports ECC keys in gpg(enable with --experts) and openpgpjs with subkeys supported. we can specify a ECC subkey as maskbook used and revoke the subkey should be supported in maskbook. I think signation key and encryption key should be seperated.
   • define a special uid to identify, such as: "displayName@Maskbook <your@email.com>"
2. I can not understand about Dynamic Recipient Indication problem. It seem not the duty of PGP.
3. About payload problem:
   • The standard openpgp base64 bound should be only used on import/export(exchange keys) or user required.
   • For exchange the message such as twitter, I suggest you should choose the base32768 to encode instead base64. and drop the-----BEGIN PGP PUBLIC KEY BLOCK----- header.

[yisiliu]

1. The OpenPGP supports ECC keys in gpg(enable with --experts) and openpgpjs with subkeys supported. we can specify a ECC subkey as maskbook used and revoke the subkey should be supported in maskbook. I think signation key and encryption key should be seperated.

   • define a special uid to identify, such as: "displayName@Maskbook <your@email.com>"

We don't really want to support multiple payloads in Maskbook. The ideal payload needs to be short and concise. I am using ECC keys in PGP now but the payload is still tedious.

2. I can not understand about Dynamic Recipient Indication problem. It seem not the duty of PGP.

I agree. Neither PGP nor pure ECC keys can solve this problem.

3. About payload problem:

   • The standard openpgp base64 bound should be only used on import/export(exchange keys) or user required.
   • For exchange the message such as twitter, I suggest you should choose the base32768 to encode instead base64. and drop the-----BEGIN PGP PUBLIC KEY BLOCK----- header.

Thanks for the suggestion. We had a similar discussion on encoding formats. We will try to improve the user experience first and then get back to this problem.

[neruthes]

Base32768 looks good. We have been thinking of similar concepts but we prefer to prioritize visual uniformity, where Base4096Hanzi and Base4096Hangul are the most prevailing candidates.

I can not understand about Dynamic Recipient Indication problem. It seem not the duty of PGP.

Because it is not a duty of OpenPGP, we cannot use OpenPGP.

[snowyu]

We don't really want to support multiple payloads in Maskbook. The ideal payload needs to be short and concise. I am using ECC keys in PGP now but the payload is still tedious.

You do not need all keys in OpenPGP, you can extract the necessary subkey from OpenPGP keys only. The basic things is import/export subkeys from/to OpenPGP, and the exchange message should be done as normal(unless the user need generate the OpenPGP format infomation).

In fact, the specifications which put OpenPGP key in user's profile have already used.

We will try to improve the user experience first and then get back to this problem.

Ok. The UE is a problem indeed, more easy use means more easy crack. Enhance UE and Security both is too difficult.

Because it is not a duty of OpenPGP, we cannot use OpenPGP.

So what does your project ultimately care about? OpenPGP put heart into security and Immutable infomation many years. If your project is focused on user experience, then use OpenPGP directly for security, Btw, one key for sign and encrypt both is real bad idea for security.

Learn more about from the keybase- the OpenPGP keys center, maybe you can benefit from it.

[Jack-Works]

maybe we can support import/export persona key as OpenGPG format

[neruthes]

Dynamic recipient indication is a core feature. Every post is encrypted to a dynamic group of public keys but not a specific set of public keys.

[snowyu]

Every post is encrypted to a dynamic group of public keys but not a specific set of public keys.

The posts in a group should be encrypted with the current session-key(Symmetric-Key).

• Join group means send the current session-key to the user via group owner or member.
• Leave group means change the current session-key.

The public-key pair is always used to encrypt the session-key or sign. The session-key is always used to encrypted contents. See the OpenPGP String to Key for the session-key.

Or more security: https://signal.org/docs/specifications/x3dh/

[Jack-Works]

We have the related design of session-key (it called chatroom key(we treat the group as a e2e encrypted chatroom), https://github.com/DimensionDev/Maskbook/issues/168 ) and we're going to implement that in future.