...
As such, simply removing an account or de-registering it is not sufficient to guarantee that no funds will be transferred to or from said account. As a result it's necessary to introduce a new state for accounts: archived. It's a special marker state in which permissions for all operations on the account except for the de-archive instruction are forbidden. This serves two purposes.
...
The archival option is useful in the following scenarios:
- In case of a data breach, if the attacker managed to obtain the primary key, but not the majority of the secondary keys (e.g. by brute-forcing the public key), the owner of the original account has the option to change all secondary keys.
- In case of a data breach, if the attacker managed to obtain the primary key, and the majority of (but not all of) secondary keys, the owner still has the option to freeze the assets. Only the person with access to all the original keys can freeze the account. Upon unfreezing the accounts, it's advisable to change all secondary keys.
- In case of a data breach, if the attacker managed to obtain all of the accounts keys, the attacker can do two things:
- Immediately transfer all or part of the assets to a different account. This is countered by the archival request.
- Attempt to change the secondary keys. The original owner would still have access to the primary key, and potentially transfer access to law enforcement, exposing the identity thief to persecution. The original owner can also register a smartcontract that archives the account if more than a set number of secondary keys are de-registered in a set block. This has the added benefit of storing the de-archival key in an accessible account, thus making it impossible to recover without cracking another primary key.
- Try to archive or delete the account.
In the 3-rd case of data breach, the identity thief is indistinguishable from the original owner. As such it is preferable to reduce the likelihood of
Key collision is not a factor: It is astronomically unlikely that two ed2559 keys coincide. Specifically, it's 1 in 2256 or 1 in 1077. The probability of no two keys coinciding given that the ed25519 algorithm works as advertised is (due to the birthday paradox) exp[-10-69 ], if there are 108 or one hundred million accounts on the same network. Even assuming that the number of historical accounts is larger, it is practically impossible to generate the same key twice
...
.
This was not necessary originally, because the user was capable of (in theory) of changing the public key of their account. As accounts are inseparable from the keys used to generate them. It is impossible to do so with the new architecture.
...
- the account that wishes to de-archive another account must retain the private key corresponding to the archived account. If the key is lost the account is archived permanently. To prevent a malicious actor from archiving multiple accounts, archival must also require knowing the (primary) private key of the archived account.Only the owner of the primary key can request archival.
- Before or during During archival another account may be optionally nominated as a successor. If such an account exists, de-archival requires knowledge of both (primary) private keys. Losing either one locks the account permanently.
- After archival, smartcontracts involving the archived account fail with an error message. After de-archival smartcontracts resume operation as normal. Triggers must be given facilities to accumulate information about previously failed execution attempts. This is necessary, because archival can be used to avoid smart-contract-based payments.
- It's possible to remove smartcontracts from an archived account. It's not possible to add any.
- After archival, all pending transactions submitted from an archived account, but not executed at the time of archival are frozen: removed from the queue and added to a special section in the Archived account. When the archival is reversed the transactions are remembered, but not automatically re-submitted. Which transactions are to be re-submitted is chosen by the user after de-archival.
- In case 3.c, a thief gains nothing from archiving an account with a pre-nominated successor. Financial gain can still be extracted from deleting accounts (blackmail),
Changes to the Client API
...