Allow custom salt on NIP-44

[arthurfranca]

Want to use it with this (from #978 pull request) to achieve forward secrecy every three weeks window on DMs.

[vitorpamplona]

@paulmillr

[vitorpamplona]

I think this change is fine. But I don't know if this is enough to claim that "Forward Secrecy" has been resolved. I can't find a really specific definition for forward secrecy out there.

[paulmillr]

yes, the diff is fine, but the devil is in the details. To analyse the security:

1. How many times an event is wrapped? Just 2?
2. If today is feb 5th, and I wrap 10 events, which timestamps are they going to have? Assuming it's random within one week of feb 5th?
3. How's the key infra?

Ideally these things would be implemented in software and tested without any NIPs, on "temp events" that don't require bumping NIP version. Then it's simple to review. Practicality is the King, so, whatever works in production, is fine. Details matter though.

[paulmillr]

2 -- if it's random within ONE week of feb 5, that means some events would use one epoch, and some would use the other one. Are all events are using single epoch?

[arthurfranca]

@paulmillr #978 proposal doesn't shuffe .created_at value nor use some of its chars as salt.

Simplified flow is:

• User A tells B that both of them should use session_privkey_X instead of their own to sign events to talk to each other.
• These events are wrapped twice, so there are 2 encryptions and both call get_conversation_key(private_key_A, public_key_B, first_32_chars_of_session_privkey_X) (or get_conversation_key(private_key_B, public_key_A, first_32_chars_of_session_privkey_X))

The session duration is fixed at 3 weeks. After that, A (or B) has to use a new session_privkey_Y.
They will use the first 32 chars of session_privkey_Y as salt.

The new conversation key won't be able to decrypt old content.

[arthurfranca]

I think this change is fine. But I don't know if this is enough to claim that "Forward Secrecy" has been resolved. I can't find a really specific definition for forward secrecy out there.

@vitorpamplona if we follow nip44 definition, the question is: When a key is compromised, is it possible to decrypt all previous conversations?

With #978, the answer is: No. However, a compromised key can decrypt some recent messages.

If i'm actively talking to 5 people for years and my key gets compromised, just the last three weeks of these 5 conversations will be decryptable.

[vitorpamplona]

When a key is compromised, is it possible to decrypt all previous conversations?

If the main private key leaks, you can still decrypt everything, including all variations of the shared key designed by this PR. So, the salt does protect against the shared key leaking, but It doesn't solve the forward secrecy problem.

[arthurfranca]

@vitorpamplona if one has just the last used salt, how can it decrypt old messages that used different salts?

The Chat Session List event won't keep old salts from same chat.

[vitorpamplona]

Where are you saving the salt?

[arthurfranca]

The salt is saved on relays on the "chat session list" event (in fact it saves the "session privkey" and the salt is the first 32 chars of that key).
Edit: The client may save previous salts locally, but an attacker wouldn't have access to them

[vitorpamplona]

The client may save previous salts locally, but an attacker wouldn't have access to them

Anyone can save all kind:10043 events. That is probably a profitable and legal business model to supply to the attackers when people's private keys inevitably leak.

[arthurfranca]

Probably a good idea to require AUTH when serving kind:10043 events.

[vitorpamplona]

Probably a good idea to require AUTH when serving kind:10043 events.

Sure, but if the salt is the same for all users, all the attacker must do is to find one user without an AUTHed relay to download the 10043 event. Anyway, you may argue that #978 fixes forward secrecy, but not this PR in itself (because it depends on how other NIPs manage their salt).

I think it is important to mention that Forward Secrecy is when the crypto stuff gives assurances that session keys will never be compromised even if long-term secrets used in the session key exchange are compromised. The assurance in this case, comes from an operational feature (each user's own relays) that might simply not be there or fail from time to time. Thus, to me, it cannot be assured.

[arthurfranca]

It is one salt per user pair. I will remove changes in text related to forward secrecy.