Nostr notes by Grey Area

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

2026-07-26T19:35:35Z

In reply to nevent1q…xc23
_________________________

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

> Do you think it's worth doing this? Identity hiding is a ...

2026-07-26T03:58:40Z

In reply to nevent1q…436f
_________________________

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

Think 5.1.3 (AuthEncap) is better since it still uses an ...

2026-07-24T10:05:38Z

In reply to nevent1q…7t3z
_________________________

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.

Ah , mea culpa, you're right. 5.1.1 avoids the nonce reuse ...

2026-07-23T23:44:06Z

In reply to nevent1q…7737
_________________________

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

If the signature in proof covers fep0806:cipherData, you can do ...

2026-07-23T17:49:01Z

In reply to nevent1q…hze2
_________________________

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

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

2026-07-22T21:54:13Z

In reply to nevent1q…dga5
_________________________

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.

Of an envelope. If actor being changed mid-transit isn't a ...

2026-07-22T17:42:00Z

In reply to nevent1q…nv22
_________________________

Of an envelope. If actor being changed mid-transit isn't a problem, then omit it from the aad. Including the from/to as part of the AAD binds the ciphertext to the origin/recipient (the HPKE ciphertext does not carry any of this information).

It is worth noting that, as the FEP is specified now, using the sender and recipient's keypairs to do HPKE will result in the same shared secret being generated for every message. This is catastrophic to security as the nonce for the symmetric portion of the HPKE encryption is deterministic (RFC 9180 5.1).

This can be avoided by either: having the sender generate an ephemeral keypair (include the public key envelope), or using a unique HPKE info per envelope. The former is better as it gives imperfect forward secrecy (sender identity key compromise does not reveal past plaintexts), the latter is cheaper to do.

The primitive choices are sensible. The "aad" is sent in ...

2026-07-21T13:58:27Z

In reply to nevent1q…5qtp
_________________________

The primitive choices are sensible.

The "aad" is sent in the clear (or just public as it is now) so you could do something like "fep-0806-aad" | ':' | <id> | ':' | <actor> |':' | <to>. If the proof covers all of that then it's not strictly needed, but it's cheap paranoia.

I was going to say add version info to the labels, but fep0806:cipherAlgorithm covers that.

WhatsApp. It's biggest claim to fame is non-group messaging ...

2026-07-17T17:42:36Z

In reply to nevent1q…zqrr
_________________________

WhatsApp.

It's biggest claim to fame is non-group messaging (WireGuard), and the fact that the designer based it on the Signal wire protocol design (same person). The latter research that adds concrete security proofs is an added bonus, as well as decent library availability.

But, there's only so many ways to do NIKE (Non-Interactive Key Exchange), and the IETF/IRTF has a preference for reusing their own standards.

TLDR: Noise over HPKE is a personal preference, I think it's harder to blow your foot off with Noise and it's easier to implement (having done multiple Noise impls, and dealt with HPKE more than I should), but honestly either is a reasonable choice, and if you want something more standardized, HPKE is reasonable.

HPKE has the benefit of being standardized, and imperfect forward ...

2026-07-17T17:15:56Z

In reply to nevent1q…tzvz
_________________________

HPKE has the benefit of being standardized, and imperfect forward secrecy is the best you can do with 0-RTT (which probably fits the fediverse model better).

Just be very careful about the "use correctly" and it's "fine". I'm partial to Noise (https://noiseprotocol.org/) for these sort of use cases because it has less foot+guns and there's more flexibility, but I wouldn't freak out or scream if I saw HPKE in use.

As a side note, it is indeed safe to convert ed25519 keys to X25519 keys assuming a common sense step is taken when using the latter (https://eprint.iacr.org/2021/509).

Sorry for the delayed response, but yes. The naive approach would ...

2025-12-05T15:43:37Z

In reply to nevent1q…qru6
_________________________

Sorry for the delayed response, but yes.

The naive approach would be:

- Convert both party's Ed25519 keys to X25519 keys
- ECDH(Sender static, Recipient static) -> k
- HKDF(k) -> Shared secret

The problem with this approach is that, if either side's private key gets compromised, all historical traffic is trivially decryptable. (Static-Static ECDH)

Perfect forward secrecy (compromise of either key does not give attacker the ability to read past messages) requires at least one extra round trip, which is not great in this setting.

The tweak I suggested is:

- Convert both party's Ed25519 keys to X25519 keys
- Sender generates a ephemeral (throw away) X25519 key
- ECDH(Sender static, Recipient static) -> k_1
- ECDH(Sender ephemeral, Recipient static) -> k_2
- HKDF(k_1 | k_2) -> Shared secret
- Sender discards the ephemeral key

With this improvement, sender long term key compromise does not allow decryption of past traffic, because the ephemeral keypair is long gone into the void (one-way forward secrecy, Static-Static + Ephemeral-Static ECDH).

Note: While the theoretical safety of reusing a Ed25519 key for also doing X25519 was an open question, there are proofs that it is safe.

As a note, FEP-0806 is overly simplistic in that it has no ...

2025-12-02T22:41:46Z

In reply to nevent1q…28s9
_________________________

As a note, FEP-0806 is overly simplistic in that it has no forward secrecy.

As an easy improvement, if the sender also generates a per-message ephemeral X25519 keypair, you can do static-static + static-ephemeral KEX and get imperfect forward secrecy (no additional round trips required).

Nostr event nevent1qqswl6fsj4gx4fzlrz3yk0ay57vkluyauclmmtn0rzl9xfkdazz9r7czyz7wl70aldky5cvr6v0fzuau22egt4d638l5md5vefemh6a9grprjz7e8tq

2025-11-06T10:01:34Z

In reply to nevent1q…rxak
_________________________

https://ja.wikibooks.org/wiki/%E5%88%91%E6%B3%95%E7%AC%AC92%E6%9D%A1

It would be up to the Israeli govt if they want to press charges or not. Existing case law is hilarious and depressing.

It would be interesting to see how much of this sort of thing ...

2025-11-06T09:19:05Z

In reply to nevent1q…g7s4
_________________________

It would be interesting to see how much of this sort of thing (flag desecration, obscenity, defamation) would survive dedicated legal effort to overturn them on constitutional grounds.

But someone that's Not Me should do it because, getting wrung through the legal system to have standing to bring it up to the Supreme Court sounds time consuming and annoying.

According to twixtter the line finally dispersed while I was on ...

2025-08-18T18:17:01Z

In reply to nevent1q…ejz3
_________________________

According to twixtter the line finally dispersed while I was on my way home, which was way into the afternoon, so "fuck it, I'll melonbooks my way to victory for that" was the right call.

Is creative freedom without school girls and tentacles, really ...

2025-08-03T05:48:52Z

In reply to nevent1q…exsv
_________________________

Is creative freedom without school girls and tentacles, really free?

Looked, was expecting something I would find on dlsite or an ...

2025-08-02T08:45:14Z

In reply to nevent1q…9qze
_________________________

Looked, was expecting something I would find on dlsite or an ILLUSION title. Somewhat disappoint.