ya know, i don't even understand what that means
as in, they get your key out of the breach?
i mean, once you grasp that simple part of it how do you propose to change the nostr protocol so identities aren't tied to public keys?
needs a broadcast protocol for identities, so you can roll them over without losing your central identity secret key
another protocol, and that protocol has to be integrated into the clients so they refer to this separate protocol to look for current identity
actually, wrong term
I meant forward security
post compromise security is interesting, but it is not applicable in nostr
yes, these terms are not easy to understand and rarely well explained
forward secrecy literally means that you can encrypt a message in a way that could not be predicted by an adversary
usually such schemes involve using a seed value to derive a hash based on some temporal value, usually the time alone is sufficient
it's my firm opinion that the field of cryptography and signals security have a long way to go in building adequate models to make this understanding accessible
too many engineers, not enough teachers (i'm probably more teacher than engineer)
also, i appreciate this point: post compromise security is irrelevant in a system with persistent identities, only forward security matters
yes, the only case it could work with unnecessary complexity is where you use a remote signer, each client maintains state locally, and you remove a client
in this case you can also do the following which is easier: rotate the secret used for encryption
post compromise recovery requires key rotation and really should have a context of a connection
the point about the stable identity is part of the problem, to do post compromise with nostr you have to add a new form of temporary identity called a conversation... the identity is revealed to participants in the process but it is not the identitity that is maintained during it
so, yeah, it depends a lot on client state and that's why all the signals and whatsapps and sessions and suchlike are in a shambles, and i don't think MLS fully solves the problem, it does provide a mechanism for maintaining per-discussion identity but it doesn't deal with the "and then" part of it
the only solution for this relates to relays holding state data, btw
and i've been saying this for quite some time, that relays should be able to be trusted to hold state data
part of the issue then is really about clients having a deterministic keychain as this is the only way to keep the data across instances without actually explicitly storing it on the client
