Yes, proof covers all properties of the activity. But I can't omit encap

2026-07-23 19:30:59 UTC

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](https://www.rfc-editor.org/rfc/rfc9180.html#name-encryption-to-a-public-key )

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.

Author Public Key

npub19yg7mshq9vdtvvcm48svw03cmzewue4jug62cltnleh3y78khz5sm5wysk

Seen on

wss://relay.momostr.pink

Show more details

Published at

2026-07-23 19:30:59 UTC

Kind type

1 Short Text Note

Event JSON

{ "id": "3e131d86a463c044f3ccc4e8a43d35ca4741f89dfe3fd041f3939b596bdea6dc", "pubkey": "2911edc2e02b1ab6331ba9e0c73e38d8b2ee66b2e234ac7d73fe6f1278f6b8a9", "created_at": 1784835059, "kind": 1, "tags": [ [ "p", "8d460d6a13ed3f5d251207ed323436ebebe126a43b143e25dd053cd471e0df45" ], [ "p", "2911edc2e02b1ab6331ba9e0c73e38d8b2ee66b2e234ac7d73fe6f1278f6b8a9" ], [ "p", "1690b24ed3894f2c26aa363e294e6e54b7e023e8ebf74c16ce0a225c87cfc435" ], [ "e", "34d1d1c90f2828cbd821dd774d5ee67e4d060b8354c0addc6d0b38ce78b83fc0", "", "reply", "bceff9fdfb6c4a6183d31e9173bc52b285d5ba89ff4db68cca73bbeba540c239" ], [ "p", "677402b7647146d8d513c27988818e9819ac9642fae4ae3f0b736461c5b5c172" ], [ "e", "0a18a3a3c0d8840dfe9fdec4ded6694f73249d3561fadaed35099501abeb5d71", "", "root", "1690b24ed3894f2c26aa363e294e6e54b7e023e8ebf74c16ce0a225c87cfc435" ], [ "p", "2ceb75c8271582855ec79d56c3f90da020e88de9f98dd6e76a1c7e436d5da02a" ], [ "p", "bceff9fdfb6c4a6183d31e9173bc52b285d5ba89ff4db68cca73bbeba540c239" ], [ "proxy", "https://mitra.social/objects/019f9075-ad6b-75b3-a406-16bdfa73722b", "activitypub" ], [ "L", "pink.momostr" ], [ "l", "pink.momostr.activitypub:https://mitra.social/objects/019f9075-ad6b-75b3-a406-16bdfa73722b", "pink.momostr" ], [ "-" ] ], "content": "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](https://www.rfc-editor.org/rfc/rfc9180.html#name-encryption-to-a-public-key )\n\nI'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:\n\nhttps://docs.rs/hpke/latest/hpke/trait.Kem.html#tymethod.encap_with_rng\n\n\u003e Derives a shared secret and an ephemeral pubkey that the owner of the reciepint’s pubkey can use to derive the same shared secret.\n\nThis \"ephemeral pubkey\" is what I labeled as encap_key. It is later included in fep0806:cipherData\n\n-----\n\nI 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.", "sig": "cb5b8b20b8db533a6f671a7af6434c310bafc96a755b4a0c7905b86885679f34e218475f9abd5c90871643c413a5873235269c07954379fc58239bde06396c4e" }

silverpill on Nostr: Yes, proof covers all properties of the activity. But I can't omit encap_key, it is ...