Anonymous user
Template:User committed identity/doc: Difference between revisions
m
→Weakness
m (→Getting the hash: hide interwiki codes from the displayed link) |
m (→Weakness) |
||
Line 66:
An attacker without access to the account could claim that the current account's owner stole their identity. The attacker could state that they did not publish a hash when they used to own the account, or that they did not register an account and that someone else is using their name.
An attacker may want to know the secret passphrase, pretending he wants to verify your ownership. He will use social behavior to convince you that you must reveal it. Then by revealing him the passphrase to him, he can pretend he is now the "legitimate" owner of your account. The passphrase verification (necessarily made by someone else) is inherently unsecure.
This weakness does not indicate the [[en:commitment scheme]] is worthless, because the ''commit phase'' did not apply to all interested parties (the real person and all potential attackers).
== Better protection ==
But a real protection should use a two-keys echange mechanism based on asymetric key pairs:
* these keys are used to encrypt on one side (and decrypt on the other side) the hashes of the plain-text request (that does not need to be encrypted itself) which also contains in clear text the public key of the sender; the hash then terminates each message and authenticates its sender. When replying, your response must contain (in its clear text) the initial encrypted hash that was in the verifier request, so that your reply cannot be reused as a formal acceptation for an unrelated request. In both cases, the hashes are encrypted using the private key (never revealed to any one) of each message sender: each one "reveals" only his public key.
* The hashes should be computed by including the content of the clear-text message, so that this message cannot be altered maliciously by anyone else (the hash asserts that the text is authentic and comes only from the user that owns the private key, and because this public hash is then followed by a secretly encrypted hash of all the previous content, it cannot be reused for unrelated responses; and it's still easy to assert that this second encrypted hash can be decrypted successfully using the public key of the message sender, to check that it matches his public key also present in the clear-text message and as well the public key can assert that the first message and its hash was not altered).
* But for that goal you still need a strong hashing algorithm (SHA256 at least) in addition to the encryption algorithm with asymetric key pairs used to sign the hashes and authenticate each sender. Asymetric encryption is known to be slow for long messages, but this should not be a problem because it will encrypt only strong hashes (this also secures the asymetric encryption to protect the private keys which are typically longer than hashes and cannot be infered from the public keys that are also longer than the hashes). With SHA256 or SHA512 used for the hash, you can then use asymetric encryption with 1024-bit asymetric keys. With that the "commitment" of each one can be trustable because everyone keeps his secrets but signed authenticated messages can be safely archived, and published as an evidence, a proof that cannot be later denied by any one (not even by the sender of each signed message that should attest with his signature that he is alone to own and control the private key).
* The mechanism can be used as a proof of authenticity for any kind of message, request, or reply: what is authentic is the clear-text text of the message that contains any kind of public information that one can trust, so it can contain a public account name, or the date of the message and the nature of the request. Its authenticity is proven by the fact it still contains the encrypted hashes that were kept unseparable from the clear-text message containing all the necessary public information that cannot be altered without breaking the secure hashes (which can no longer be decrypted with the public key of the orignal message sender. It can then be used to authenticate a verification request, and its reply.
* Each user must only publish his own public key and never has to give his private key. The user can also change the public key (and his private key) later on his public page at any time (and this change can be verified by issuing a request to the account owner to prove that he still also owns the former private key (that must be kept for a reasonnable time) and not just the new public key that replaced the old one on the account.
Such mechanism is used in emails (e.g. with PGP), or for authenticating web sites (using server certificates that contain their public key and other proof of their alleged identity, because it has been signed by a third-party using exchanges based also an asymetric cryptography with key pairs for the site owner and key pairs for the third-party signatory).
==See also==
| |||