@silverpill

No, the recipient would also generates an ephemeral key, and uses that when replying.

So it's always a one shot ephemeral (sender)/static (recipient) HPKE exchange, with sender authenticity guaranteed by the signature. Could also use the shared secret from the original post but force a different IV, but "replies are just the sender and receiver being flipped, code path is the same" is easier.

@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.

@silverpill

If the signature in proof covers fep0806:cipherData, you can do ephemeral_key_pub | ciphertext. and use Encryption to a Public Key.

@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.

@silverpill

Ah , mea culpa, you're right. 5.1.1 avoids the nonce reuse issue and provides imperfect forward secrecy. I've been fighting u-boot on "new" exotic target the last day so my thinking isn't as sharp as it should be.

Replies should go through the same process (avoids sender having to store the shared secret, less state is more better in this case).

@silverpill

Think 5.1.3 (AuthEncap) is better since it still uses an ephemeral key, but does an extra DH to authenticate the sender. 5.1.1 (Encap) is simpler, but unless the aad contains at least the sender's identity, there is nothing preventing someone from extracting a ciphertext, and re-signing it (forging the origin).

Having a trivial amount of AAD is computationally cheaper than doing the extra DH, but the extra DH would be sub 100 usec, so this is "pick something to taste".

ps: Spent the day chasing LLVM bugs, errors in this would be all mine.

@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).

@silverpill

Do you think it's worth doing this?

Identity hiding is a useful property (especially in the current environment), and simpler is better. Especially if the inner activity is self-authenticating.

ps: I should look more into the fediverse protocol, but from what I remember from peeking at it a long time ago it was a giant mess of w3c specs.

@greyarea

I can think of two scenarios where HPKE-level sender authentication or aad binding might be important:

1. The sender creates an activity that is attributed to somebody else, encrypts it, and sends to the recipient. This shouldn't be a problem, because the inner activity MUST be portable, and therefore required to have an integrity proof. A compliant recipient can't be fooled into thinking that misattributed activity is real.
2. Somebody (e.g. server operator) takes the fep0806:cipherText out of EncryptedActivity, and creates a new activity with the same fep0806:cipherText but different id, actor and/or to. This shouldn't be a problem either. In the worst case, the activity will be delivered to somebody else who will not be able to decrypt it. Replacing id and actor may be even a good thing (obfuscation).

it was a giant mess of w3c specs.

It's an ever-expanding mess of W3C specs, RFCs and FEPs.

Integrity proofs are relatively new, they are described in Data Integrity W3C spec: https://www.w3.org/TR/vc-data-integrity/

@silverpill

Agreed on 1 and 2, and think that enabling identity obfuscation is a feature.