silverpill

@silverpill@mitra.social · Joined ⁨Nov⁩ ⁨2021⁩

Developer of ActivityPub-based micro-blogging and content subscription platform Mitra. I help maintain the FEP repository and write my own FEPs too. Currently working on ActivityPub Next.

Matrix
@silverpill:unredacted.org
$XMR
48YM8jwJqDkeUvD38vepSXFeMZH1zsjbvGwTTuaNSSq6Q5GyeWaeiheAZUsSmNn72YdyLpw8geb4FL3opZfGbguJLUj8Mi9
PGP
0541 49E3 0F91 C6D7 8FFA C49C 955F 5A6E 2123 25F0
OMEMO fingerprint
689a2fb0ec87a9481fb45cb7d8870da6aeb4d8247bd69a39017701133b901f04
Matrix (backup)
@silverpill:poa.st

Replying to @⁨greyarea@mitra.vpclmulqdq.moe⁩

@greyarea Alright, I implemented the auth mode. It's not difficult, but it requires the actor of outer activity to be the same as the actor of inner (plaintext) activity. With base mode (5.1.1), the actor of outer activity could be different, which means we can hide the real sender.

Do you think it's worth doing this?

I think authentication of the sender at the HPKE level shouldn't be necessary because the inner activity is self-authenticating (includes integrity proof).

Replying to @⁨xailog@wizard.casa⁩

@xailog @liaizon The idea is very simple:

- Find a grassroots ecosystem, which is not very well known to general public
- Start promoting it to general public, while inserting your name or brand in every communication.
- People not familiar with the ecosystem think that you are very important.
- You get accolades, invited to conferences, receive grants and contracts.
- Grassroots ecosystem slowly dies and is replaced by structures that you control.
- PROFIT

Replying to @⁨greyarea@mitra.vpclmulqdq.moe⁩

@greyarea Yes, proof covers all properties of the activity. But I can't omit encap_key, it is required by SetupBaseR function defined in section 5.1.1

I've read a bit more about DHKEM and now I am even more confused. Isn't encap_key an ephemeral key? The library I am using describes it as such:

https://docs.rs/hpke/latest/hpke/trait.Kem.html#tymethod.encap_with_rng

Derives a shared secret and an ephemeral pubkey that the owner of the reciepint’s pubkey can use to derive the same shared secret.

This "ephemeral pubkey" is what I labeled as encap_key. It is later included in fep0806:cipherData

-----

I think it's okay to have no forward secrecy, the goal of this FEP is to describe a simple encryption mechanism that anyone can implement. I'll just warn readers about its weakness.

www.rfc-editor.orgRFC 9180: Hybrid Public Key Encryption This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Replying to @⁨reesericci@socialhub.activitypub.rocks⁩

A standardized emoji catalog allows a C2S client to ...

But the proposal doesn't fully explain how to do that. In particular:

- How catalogs are created? (I wrote a FEP that provides some recommendations, FEP-9f9f: Collections)
- What activities are used to update a catalog?

Summary card of repository fediverse/fep, described as: Fediverse Enhancement ProposalsCodeberg.orgfep/fep/9f9f/fep-9f9f.md at mainfep - Fediverse Enhancement Proposals

Replying to @⁨fox@social.hostnetwork.xyz⁩

@fox I was told that your image doesn't work, something related to the configuration path. So we made another one: https://codeberg.org/silverpill/-/packages/container/mitra/5.7.1

But your image is still listed in the readme - it's good to have a backup.

Codeberg.orgmitraCodeberg is a non-profit community-led organization that aims to help free and open source projects prosper by giving them a safe and friendly home.

Replying to @⁨greyarea@mitra.vpclmulqdq.moe⁩

@greyarea I assume this is "Authentication Using an Asymmetric Key" (https://www.rfc-editor.org/rfc/rfc9180.html#name-authentication-using-an-asy)?

Because in "Encryption to a Public Key" mode, sender's key is not used.

If I understand the idea correctly, the ephemeral key would need to be added to fep0806:cipherData. That is, instead of encap_key | ciphertext it will be ephemeral_key_pub | encap_key | ciphertext.

www.rfc-editor.orgRFC 9180: Hybrid Public Key Encryption This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.