You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if the key server doesn't use TBs, a malicious client can attempt to equivocate about the name by re-registering the same username with a different key.
This attack can be mitigated by lookup in the current tree of the pad. The server could return a ErrorNameExisted along with a proof of absence (from the latest committed STR).
However, the client doesn't get any proof that the name already exists, and until the current tree is committed. A malicious server can now easily cheat and give clients false information about which names exist, don't exist etc and they wouldn't have any proof.
It means that while we don't have a better solution for registration promises, the key server would be forced to use TBs.
Currently, if the key server doesn't use TBs, a malicious client can attempt to equivocate about the name by re-registering the same username with a different key.
This attack can be mitigated by lookup in the current tree of the pad. The server could return a
ErrorNameExisted
along with a proof of absence (from the latest committed STR).However, the client doesn't get any proof that the name already exists, and until the current tree is committed. A malicious server can now easily cheat and give clients false information about which names exist, don't exist etc and they wouldn't have any proof.
It means that while we don't have a better solution for registration promises, the key server would be forced to use TBs.
See #109.
The text was updated successfully, but these errors were encountered: