From 9ca871da6aaaa0e1ce3c72dcf93428ff7f8ce14a Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 1 May 2026 23:37:44 +0330 Subject: [PATCH 01/20] feat: add TIP draft for ASR recovery standard --- tip-asr.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 tip-asr.md diff --git a/tip-asr.md b/tip-asr.md new file mode 100644 index 0000000..b7ec10c --- /dev/null +++ b/tip-asr.md @@ -0,0 +1,12 @@ +--- +tip: +title: ASR - Adaptive Secure Recovery +author: Ali (@alichatme) +discussions-to: https://github.com/tronprotocol/tips/issues/858 +status: Draft +type: Standards Track +category: Core +created: 2026-05-01 +requires: +replaces: +--- From aa3fcd128acb69cdf438bccf6268b72e7f198e30 Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 1 May 2026 23:49:11 +0330 Subject: [PATCH 02/20] feat: add full ASR proposal specification --- tip-asr.md | 570 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 570 insertions(+) diff --git a/tip-asr.md b/tip-asr.md index b7ec10c..0a63a26 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -10,3 +10,573 @@ created: 2026-05-01 requires: replaces: --- + +ASR – Adaptive Secure Recovery +Adaptive Secure Recovery Standard for Cryptocurrency Accounts + +### Introduction + +One of the most significant challenges in the cryptocurrency ecosystem is the secure storage of Seed Phrases. Standard protocols like BIP-39, despite their simplicity and widespread adoption, lack any independent cryptographic layer or active defense mechanisms. +Consequently, if the seed phrase is compromised, the user’s entire assets become accessible and transferable without any security barriers. In this context, the ASR standard is introduced to eliminate this fundamental weakness. + +### Rationale + +ASR is a standard that ensures the user’s digital currency account assets are not at risk, even if the recovery data is lost or stolen. +This is because the recovery process in ASR, in addition to a numerical variable, depends on a private keyword variable. This variable is stored in the user’s memory or in a separate location from the numerical variable and acts as the key for recovery. It consists of only 12 English letters, which are easy to remember or can be stored separately from the numerical variable to ensure that even if the numerical recovery data is fully exposed, recovery without the keyword is practically impossible. + +ASR is not a static recovery mechanism; rather, it is a network-dependent, account-state-dependent, and Core security policy-dependent recovery system. This design transforms asset recovery from a single point of failure into a multi-stage, auditable, and adaptive attack-resistant process. + + +### Overall ASR Architecture +ASR consists of three main components: + +. ASR-REC: Recovery Numbers +. ASR-VAR: Variable Secret +. ASR-CRC: Cyclic Reduction Core + + +## Component One: ASR-REC (Recovery Numbers) +The numerical recovery data, by default, consists of 12 four-digit numbers (a total of 48 digits). +Each number falls within the range 0000 to 9999. +This range operates in a modular manner. +These values are displayed to the user in groups of four digits, separated by - and prefixed with ASR-REC. + +# Example of ASR-REC Display Format +ASR-REC-1185-7517-7217-1362-1364-1388-4765-6867-7966-6765-2678-6765 + +# Display Requirements + +· Mandatory Left-to-Right +· Mandatory ASCII +· Mandatory uniform formatting using "-" and displaying ASR-REC to the left of the numerical variable to prevent homography attacks + +In the ASR standard, the user can store the ASR-REC digits without concern, because the recovery process, in addition to having ASR-REC, also requires a private lexical variable called ASR-VAR. + +## Component Two: ASR-VAR (Variable Secret) +The user’s private variable is a lexical variable consisting of 12 uppercase English letters (A–Z), selected and mapped by the user. +This variable is exclusively held by the user and stored either in the user’s memory or in a location separate from ASR-REC. +ASR-VAR is not stored on the network or in the wallet. +This variable is considered the access key to the assets, and without ASR-VAR, neither the network nor the wallet can map ASR-REC to an account. + +# Display Requirements +. Uppercase letters A–Z only +. ASCII encoding only +. No spaces +. Left-to-Right display +. Uniform formatting with "-" with ASR-VAR displayed to the left of the variable to prevent homography attacks +. A maximum of two consecutive repeated letters is allowed + +The repetition restriction is applied to prevent the selection of extremely low-entropy variables (e.g., AAAAAAAAAAAA) and is comparable to password policy standards in secure systems. +Allowing up to two consecutive repeated letters ensures linguistic compatibility with natural English language structures. + +# Example ASR-VAR Display: +ASR-VAR-SUNBOYINHOME + +Each ASR-VAR lexical character, after entering the cryptographic cycle specific to this standard ASR-CRC , is used by default to encrypt four digits of ASR-REC. + +## Component Three : ASR-CRC (Cyclic Reduction Core) +This system structurally increases the cost of each guess or attack attempt by creating exponential growth in computational states. + +The cyclic cryptographic core is responsible for: +. Converting letters to numbers +. Executing cryptographic cycles via additive variable aggregation to expand numerical digit ranges +. Ensuring full coverage of the numerical range 0000 to 9999 in the default ASR configuration + +# Letter-to-Number Mapping +The ASR-VAR vocabulary consists exclusively of uppercase English letters A–Z in ASCII. +Each letter corresponds to a number: +A = 1, B = 2, …, Z = 26 + +# Cryptographic Cycle Execution: +First, the lexical variables are converted into a numeric sequence, written inside brackets, and separated by - +Then, each variable is added to the next variable in sequence; the last variable is added modularly to the first. +This is performed for all 12 values. +The results are written inside brackets and separated by - forming the next cycle. +With repeated aggregation, subsequent cycles produce numbers with increasing digit lengths. +These cycles continue until the last variable exceeds four digits (in the default ASR configuration). + +# Full Range Coverage Guarantee: +Once variable values exceed four digits, only the rightmost four digits of each value are extracted for integration, and the remaining leftmost digits are discarded. +Continuation of the cycles is necessary to guarantee full coverage of the numeric range 0000 to 9999. + +# Complete Practical Example of the ASR-CRC Cryptographic Model + +Assume the user selects the following ASR-VAR + +ASR-VAR-ABCDEFGHIJKL + +In the first step, each lexical variable of ASR-VAR is replaced with its numerical digit inside brackets and separated by the - sign. + +[1-2-3-4-5-6-7-8-9-10-11-12] + +Then, each variable is added to the variable in front of it, and the last variable is also added modularly to the first variable. The results of the additions are written in order inside brackets and separated by the - sign, and recorded as the next cycle. + +Numerical example of the first cycle of the above example: + +1+2=3 +2+3=5 +3+4=7 +4+5=9 +5+6=11 +6+7=13 +7+8=15 +8+9=17 +9+10=19 +10+11=21 +11+12=23 +12+1=13 + +Result: +[3-5-7-9-11-13-15-17-19-21-23-13] + +Second Cycle +3+5=8 +5+7=12 +7+9=16 +9+11=20 +11+13=24 +13+15=28 +15+17=32 +17+19=36 +19+21=40 +21+23=44 +23+13=36 +13+3=16 + +Result: +[8-12-16-20-24-28-32-36-40-44-36-16] + +The cycles continue until the last variable exceeds four digits for all variables. Then, in the above assumption, as well as in the default ASR standard, only the rightmost four digits resulting from the cycle of each variable enter the integration stage, and the remaining left digit(s) of each variable are ignored. + +# Modular Integration of ASR-CRC Output with ASR-REC (with Example) + +In ASR, the user’s private variable (ASR-VAR) is first processed through the ASR-CRC core. +The output of this process is a four-digit numeric value (ASR-CRC Output), which serves as an intermediate recovery value and cannot independently reconstruct the Seed or private key. +This four-digit value is then modularly added to each four-digit ASR-REC number, and the final result is displayed to the user. +If the sum exceeds 9999, the calculation continues modularly from 0000. + +# In another example, with hypothetical numbers different from the previous example. + +Assume: +The value of the first four-digit number in ASR-REC is equal to: +4444 + +And the four-digit output resulting from processing ASR-VAR in the ASR-CRC cycles is equal to: +2222 + +In this case, the integration is performed as follows: +4444 + 2222 = 6666 + +The value 6666 is displayed as the ASR-REC value to the user. + +# Recovery Process +During recovery, the user enters 6666 as the first ASR-REC value. +After entering ASR-VAR, the wallet reruns ASR-CRC and calculates: +ASR-CRC Output = 2222 + +The wallet, after subtracting the number resulting from the ASR-CRC cycle from the user's 4-digit ASR-REC number, reconstructs the original middle digit value for account recovery + +6666 − 2222 = 4444 + +Note: If subtraction results in a value below 0000, the calculation proceeds modularly by subtracting from 9999. + +After reconstructing ASR-REC values, the wallet sends the recovery proof to the network in accordance with the ASR standard. + +If account status, security policies, and timing conditions are approved, the network issues a Network Recovery Authorization (NRA). + +Only after receiving this authorization can the recovery process be completed. + +This model guarantees that: +Without ASR-VAR, ASR-REC cannot be reconstructed + +Even with ASR-REC and ASR-VAR, recovery cannot be completed without network authorization + +Recovery requires the simultaneous presence of three independent factors +. ASR-REC +. ASR-VAR +. Network-issued Recovery Authorization + +This design transforms recovery from a static operation into a controlled, network-dependent, abuse-resistant process. + +## Additional Engineering Considerations and Security Constraints + +1. Intentionally Underdetermined Recovery + +In ASR, Seed reconstruction is deliberately underdetermined. Even with full possession of ASR-REC and ASR-VAR and complete execution of ASR-CRC, the solution space does not collapse to a single value. +The final degree of mathematical freedom required to determine the Seed is provided exclusively by the network Core and is outside the wallet’s control. + +2. Explicit Separation of Local Computation and Final Recovery Control + +All cryptographic operations +. ASR-CRC execution +. Recovery Proof generation +. ASR-VAR processing +are performed locally in the wallet. +However, these computations alone never produce the Seed or private key. + +Final recovery control depends exclusively on the issuance of Network Recovery Authorization. + +3. Fundamental dependence of recovery on network authorization (Network-Gated Recovery) + +Completion of the recovery process in ASR is subject to receiving a Network Recovery Authorization (NRA), which: + +. Without owner signature +. Without smart contracts +. Without fees or gas +. Only while online + +Without NRA, Seed reconstruction is cryptographically and engineering-wise +impossible. + +4. Preventing Adaptive Online Attacks by Stabilizing the Recovery Context + +To prevent adaptive online brute-force attacks, the wallet is required to generate a Recovery Context Identifier derived from ASR-REC before any combination of ASR-REC with ASR-VAR and before executing ASR-CRC. + +This identifier: + +· Is independent of ASR-VAR +· Is independent of variable cryptographic outputs +· Remains constant for all recovery attempts of a single account + +Network policies such as rate limits, delays, and attempt counters are applied based on this identifier, not based on the Proof or cryptographic variables. + +5. Ineffectiveness of Attacker Variable Changes Changing any of the following does not create a new recovery context: + +. ASR-VAR +. Wallet client or version +. IP, VPN, Tor, or network source +. Recovery Proof + +All these attempts are mapped to a single Recovery Context and will be subject to network restrictions. + +6. Minimum Disclosure Principle During recovery The network, during the recovery process + +. Has no access to ASR-VAR +. Does not store Seeds or private keys +. Does not interpret Recovery Proof contents + +The network only issues or denies recovery authorization based on account state and security policies. + +7. Absolute Prohibition of Offline Recovery + +Unlike BIP-39, ASR provides no valid offline recovery path. + +Lack of network access definitively prevents recovery. + +This is a fundamental design requirement, not an implementation flaw. + +8. Deterministic Recovery Context Derivation + +To prevent adaptive online brute-force attacks and any attempt to bypass network rate-limiting policies, the wallet is required to generate a unique identifier called the Recovery Context Identifier (RCID) before receiving ASR-VAR from the user and before any cryptographic processing, ASR-CRC execution, or Recovery Proof generation. + +This identifier must have the following characteristics: + +· Derived deterministically and ONLY from the raw ASR-REC data +· Completely independent of: + · ASR-VAR + · ASR-CRC outputs + · Recovery Proof + · Wallet version, client, IP, or network conditions +· Remains constant for all recovery attempts associated with a fixed, unchanging ASR-REC +· Generated before any user interaction with the cryptographic process + +To state it more explicitly: + +RCID must be a function solely of ASR-REC, with no other variable involved in its generation. + +Requirement to map all attempts to a single context + +The wallet is required to send the generated RCID along with the Network Recovery Authorization (NRA) request to the network. + +The network applies all security policies, including: + +· Rate Limit +· Delay +· Attempt counters +· Progressive time-based restrictions + +based on the RCID, not on cryptographic variables, Proof, or user inputs. + +Consequently, changing any of the following by an attacker: + +· Changing ASR-VAR +· Changing Recovery Proof +· Changing IP, VPN, Tor, or network source +· Changing wallet/client version or type + +will not create a new recovery context. + +All such attempts are considered by the network as attempts to recover a single account and will be subject to the same security restrictions. + +Security implication of RCID design + +This design ensures that an attacker cannot bypass network rate-limiting policies by changing input variables or the execution environment. + +As a result: + +Adaptive online brute-force attacks in ASR become practically and temporally impossible. + +Because the network, instead of rate-limiting "cryptographic attempts", rate-limits the "recovery target". + +This pattern, known as account-centric rate limiting, is considered one of the most advanced defense patterns in financial and banking systems. + +Implementation MUST + +In wallet implementation: + +· RCID generation must be performed before receiving any user input and before any cryptographic processing. +· Any dependency of RCID on ASR-VAR, CRC output, Proof, or execution conditions is considered a violation of ASR security requirements. + +## Responsibilities + +# User Responsibilities +Maintain ASR-VAR and ASR-REC separately + +# Wallet Responsibilities +The wallet performs all local cryptographic recovery computations + +. Storing ASR-REC +. Receiving and processing ASR-VAR +. Executing ASR-CRC +. Generating Recovery Proof + +However, the wallet is deliberately designed to lack the ability to independently reconstruct the Seed or derive the private key. +Even with correct and complete execution of all local steps, the recovery process will not converge to a single value without receiving the additional data issued by the Core network. + +The wallet: + +· Is not the owner of the Seed +· Does not have final control over the account +· Cannot complete recovery offline or unilaterally + +This limitation is a fundamental security constraint in the ASR design, not an implementation flaw. + +# Role and Responsibilities of the Core Network in the ASR Recovery Process + +The Core network in ASR does not act as a "computing engine" or "Seed holder". Instead, it is responsible for providing the final degree of freedom necessary to complete the recovery. + +Network responsibilities are limited to the following: + +· Evaluating account status and active security policies +· Applying rate limits, delays, and attempt counters based on the Recovery Context +· Issuing or denying the Network Recovery Authorization (NRA) + +The network: + +· Has no access to ASR-VAR +· Does not store or reconstruct the Seed or private key +· Does not participate in the wallet's local cryptographic computations + +However, without issuing the NRA, the Seed reconstruction process is cryptographically and engineering-wise impossible to complete. +This dependency is not an ownership control mechanism, but a network‑centric security constraint to prevent unauthorized recovery and adaptive attacks. + +# ASR Network Layer Responsibilities + +. No smart contracts +. No gas or fees +. Core logic level +· First block of 3 unsuccessful attempts → Apply a 24-hour restriction. +· Each subsequent block of 3 unsuccessful attempts → Apply a time restriction double the previous one (e.g., 24h → 48h → 96h → ...). +· Mandatory: When a restriction is applied, a countdown timer must be displayed to the user, indicating the remaining waiting time. + +### Delayed Account Activation Option + +When displaying recovery data, users may enable Delayed Account Activation (disabled by default). +Users may select a delay between 1 and 94 days, registered with a valid network signature. +If enabled and the account remains inactive for the specified period, activation using recovery data is delayed accordingly. +During delay: +Assets are view-only +No signed operations are permitted +Countdown timer is displayed +Notifications are sent to previously active wallets + +# Definition of “Owner Activity” +Any valid on-chain transaction signed by the owner that changes network state, including but not limited to + +. Asset transfers +. Voting +. Freeze/unfreeze +. Stake/unstake +. Reward withdrawal +. Direct smart contract calls + +Receiving assets without owner signature is not considered activity. + +## Position of ASR in the Key Generation to Recovery Chain (Engineering Placement of ASR) + +To accurately understand the ASR standard, it is necessary to clearly define its position in the engineering chain from cryptographic key generation to the account recovery process. + +In HD wallet architecture and the BIP-39 standard, the key generation path is as follows: + +Entropy +→ Checksum +→ Mnemonic (2048 words) +→ PBKDF2-HMAC-SHA512 +→ 512-bit Seed +→ Master Private Key +→ Public Key / Address +→ Wallet +→ Recovery using Mnemonic + +In this structure, the Mnemonic directly represents the Seed, and anyone who gains access to it can recover the user's private key and assets without any security barrier. + +Where ASR Fits in This Chain + +The ASR standard does not change any of the following processes: + +· Entropy generation +· Seed generation +· Key Derivation Functions (KDF) +· Private and public key generation +· HD Wallet structure +· Network cryptographic algorithms + +All of the above steps remain exactly as before, following existing cryptographic standards. + +ASR only redefines the Recovery layer. + +From an engineering perspective, the new chain will be as follows: + +Entropy +→ Seed Generation (unchanged) +→ Master Keys (unchanged) +→ Wallet (unchanged) + +↓ (at recovery time) + +ASR Recovery Layer +    ASR-REC (numeric recovery data) +    ASR-VAR (user private variable) +    ASR-CRC (cyclic cryptographic process) +    Network Verification + +Fundamental Difference from BIP-39 + +In BIP-39: +Mnemonic = Seed = Access to Private Key + +In ASR: +ASR-REC ≠ Seed +ASR-REC has no relation to the Seed or private key without ASR-VAR. +ASR-REC is only an "input to the recovery process", not a direct representation of the private key. + +The recovery process is only completed when: + +1. The user enters ASR-REC +2. The user enters ASR-VAR +3. The ASR-CRC cryptographic cycle is executed +4. The network verifies the process + +Without these four steps, recovery is impossible. + +## Checksum in ASR +The Checksum in the ASR standard is used solely to detect typographical errors in the recovery data entered by the user and has no security or cryptographic role in the recovery process. + +The Checksum is generated as a value derived from the ASR-REC data using the SHA-512/256 function, but this value: + +· Does not by itself indicate the correctness of ASR-REC +· Does not enable full or definitive validation of the recovery data +· Does not reduce the cryptographic search space + +Final validation of recovery data in ASR is inherently network‑dependent and occurs only within the framework of the online recovery process, after verification of account status and Core network security policies. + +Consequently: + +· The Checksum in ASR is merely a user‑experience aid +· It provides no valid path for offline verification of recovery data +· It does not enable recovery or validation independent of the network in any way + +## Role of KDF and Seed in ASR + +The Key Derivation Function (KDF) and Seed are still generated before ASR. + +ASR has no involvement in Seed generation whatsoever. + +Rather, after Seed generation and wallet creation, the recovery data – instead of a Mnemonic – is defined in the form of ASR-REC and dependent on ASR-VAR. + +In engineering terms: + +ASR replaces the Mnemonic, not the Seed. + +# Engineering Conclusion + +ASR is not a key generation standard. + +ASR is a Secure Recovery Standard that: + +· Without changing core network cryptography +· Without changing key algorithms +· Without relying on smart contracts +· Without fees + +transforms the recovery layer from a single point of failure into a multi-stage, network-dependent process. + +This precise positioning introduces ASR as an independent, complementary layer in cryptographic wallet architecture, not a replacement for key generation standards. + +### Absolute Prohibition of Offline Recovery in ASR + +Unlike BIP-39, where recovery is completely offline, ASR is fundamentally designed to be network‑dependent. + +Executing ASR-CRC and mapping to ASR-REC alone does not result in the reconstruction of the Seed or private key. +The output of all ASR components is only an intermediate recovery value. + +Full recovery is conditional upon receiving a Network Recovery Authorization (NRA) from the Core network. + +In the absence of NRA, recovery is engineering‑wise impossible. + +### Threat Model +The ASR standard is designed to protect the account recovery process against threats related to the disclosure of recovery data, and not to counter full compromise of the user's execution environment. + +1. ASR is resilient against: + +· Partial or full disclosure of recovery data (ASR-REC) +· Disclosure of the user's private variable (ASR-VAR) +· Theft of physical or digital backups +· Offline brute‑force attacks (fundamentally impossible) +· Adaptive online brute‑force attacks (using Recovery Context and rate limiting) +· Phishing attacks targeting the recovery process +· Shoulder surfing +· Attempts to recover without network authorization +· Malicious delayed recovery, even in the event of simultaneous theft of all recovery data + (using Recovery Delay, network notifications, and account‑state dependency) + +2. Out of Scope: + +· Active malware with simultaneous access to the user's execution environment +· Compromise of operating system, firmware, or runtime +· Attacks based on full device control at the time of owner signing +· Non‑cryptographic attacks such as physical coercion or in‑person social engineering + +### Why ASR Is a Recovery Alternative to BIP-39 (Design Rationale) + +BIP-39 is a Seed generation standard that makes recovery dependent on full knowledge of the Mnemonic. +In this model, recovery is a completely offline, unsupervised process with no distinction between the legitimate owner and an attacker. + +In contrast, ASR does not replace the Seed or private key. +Instead, it transforms the recovery process into a conditional, multi‑stage, network‑dependent flow. + +The key differences are: + +· In BIP‑39, full disclosure of the Mnemonic directly leads to loss of assets. + In ASR, the recovery data alone is incapable of recovery and is useless without network approval. +· BIP‑39 enables offline brute‑force attacks and unlimited attempts without rate limiting. + ASR fundamentally makes this class of attacks impossible by eliminating offline recovery. +· BIP‑39 has no native concept of "recovery control, suspension, or rejection." + ASR turns recovery into an observable, rate‑limit‑able, and policy‑governable event at the network level. +· BIP‑39 reduces recovery to a single point of failure. + ASR eliminates this single point of failure by separating ASR‑REC, ASR‑VAR, and network verification cycles. +· In BIP‑39, the network is unaware of the recovery process. + In ASR, the network is part of the recovery security model. + +As a result, ASR enhances security not by replacing basic cryptography, but by completely redesigning the concept of digital asset recovery. + +### Summary +ASR is not a recovery phrase; it is a security‑oriented, network‑dependent recovery system. + +In this standard, the recovery process is deliberately underdetermined, and even with full possession of the user's recovery data, reconstructing the Seed or controlling the assets is impossible without a recovery authorization issued by the network. + +By moving recovery from a single point of failure to a multi‑stage process that depends on account status, time, and the Core network's security policies, ASR completely eliminates offline recovery while enabling monitoring, rate limiting, delays, and resistance to adaptive attacks. + +This design transforms asset recovery from a static, uncontrollable operation into a dynamic, manageable, and abuse‑resistant mechanism. + +Authors: Ali (@alichatme), ChatGPT From 31aee48c94e8a2aa17f7a9dedd449ab97ffef5be Mon Sep 17 00:00:00 2001 From: alichatme Date: Sat, 2 May 2026 01:18:02 +0330 Subject: [PATCH 03/20] fix: update TIP header creation date to 2026-05-02 --- tip-asr.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 0a63a26..5e7e0a8 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -6,9 +6,9 @@ discussions-to: https://github.com/tronprotocol/tips/issues/858 status: Draft type: Standards Track category: Core -created: 2026-05-01 -requires: -replaces: +created: 2026-05-02 +requires: +replaces: --- ASR – Adaptive Secure Recovery From 78cb4bec7763efb7279d02709c1b88353635814d Mon Sep 17 00:00:00 2001 From: alichatme Date: Sat, 2 May 2026 16:28:22 +0330 Subject: [PATCH 04/20] Update author tip-asr.md --- tip-asr.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 5e7e0a8..78605bb 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -1,7 +1,7 @@ --- tip: title: ASR - Adaptive Secure Recovery -author: Ali (@alichatme) +author: Ali (@alichatme), ChatGPT discussions-to: https://github.com/tronprotocol/tips/issues/858 status: Draft type: Standards Track @@ -578,5 +578,3 @@ In this standard, the recovery process is deliberately underdetermined, and even By moving recovery from a single point of failure to a multi‑stage process that depends on account status, time, and the Core network's security policies, ASR completely eliminates offline recovery while enabling monitoring, rate limiting, delays, and resistance to adaptive attacks. This design transforms asset recovery from a static, uncontrollable operation into a dynamic, manageable, and abuse‑resistant mechanism. - -Authors: Ali (@alichatme), ChatGPT From 3867d82fbd8d5a68fd3169374ba5d23dc22b6cdd Mon Sep 17 00:00:00 2001 From: alichatme Date: Sun, 3 May 2026 22:55:00 +0330 Subject: [PATCH 05/20] Update Delayed Account Activation Option --- tip-asr.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 78605bb..50d53e8 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -381,14 +381,19 @@ This dependency is not an ownership control mechanism, but a network‑centric s ### Delayed Account Activation Option -When displaying recovery data, users may enable Delayed Account Activation (disabled by default). -Users may select a delay between 1 and 94 days, registered with a valid network signature. -If enabled and the account remains inactive for the specified period, activation using recovery data is delayed accordingly. -During delay: -Assets are view-only -No signed operations are permitted -Countdown timer is displayed -Notifications are sent to previously active wallets +When viewing recovery data, the user can enable the Delayed Account Activation option (disabled by default). +The user can select a delay period from 1 to 94 days and register it with the owner’s signature on the network. + +If this option is enabled, whenever a **Network Recovery Authorization (NRA)** is issued by the network and account recovery succeeds, the newly recovered account will remain inactive until the end of the delay period. + +**Status during the delay period:** +- Assets are view‑only. +- No signed operations by the owner are permitted before the delay ends. +- A countdown timer shows the remaining time to the user. +- Notifications are sent to previously active wallets. + +**Security note:** +If the owner still has access to a previously active wallet, they can, upon detecting suspicious activity or a potential attack, stop the new account activation process before the delay ends by providing a valid signature. # Definition of “Owner Activity” Any valid on-chain transaction signed by the owner that changes network state, including but not limited to From a86d3875c0cedf1a3850278fd6177bde276617d8 Mon Sep 17 00:00:00 2001 From: alichatme Date: Sat, 9 May 2026 18:46:08 +0330 Subject: [PATCH 06/20] update delayed account --- tip-asr.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tip-asr.md b/tip-asr.md index 50d53e8..d2a1ede 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -386,6 +386,10 @@ The user can select a delay period from 1 to 94 days and register it with the ow If this option is enabled, whenever a **Network Recovery Authorization (NRA)** is issued by the network and account recovery succeeds, the newly recovered account will remain inactive until the end of the delay period. +**Displaying Recovered Devices with a Single RCID and the Ability to Terminate Previous Sessions:** +- It should be possible to view active and inactive devices associated with an RCID, as well as to terminate previous sessions for ASR accounts. +- **Limitation for newly recovered accounts:** A newly recovered account will not be able to terminate previous sessions for 30 days after activation. + **Status during the delay period:** - Assets are view‑only. - No signed operations by the owner are permitted before the delay ends. From eeff8d2b5e02283db45185bb81364bdbd390941d Mon Sep 17 00:00:00 2001 From: alichatme Date: Tue, 16 Jun 2026 07:06:56 +0330 Subject: [PATCH 07/20] Update tip-asr.md --- tip-asr.md | 59 ++++++++++++++++++++++++++++++------------------------ 1 file changed, 33 insertions(+), 26 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index d2a1ede..142a247 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -1,7 +1,7 @@ --- tip: title: ASR - Adaptive Secure Recovery -author: Ali (@alichatme), ChatGPT +author: Ali (@alichatme) discussions-to: https://github.com/tronprotocol/tips/issues/858 status: Draft type: Standards Track @@ -14,12 +14,14 @@ replaces: ASR – Adaptive Secure Recovery Adaptive Secure Recovery Standard for Cryptocurrency Accounts -### Introduction + +# Introduction One of the most significant challenges in the cryptocurrency ecosystem is the secure storage of Seed Phrases. Standard protocols like BIP-39, despite their simplicity and widespread adoption, lack any independent cryptographic layer or active defense mechanisms. Consequently, if the seed phrase is compromised, the user’s entire assets become accessible and transferable without any security barriers. In this context, the ASR standard is introduced to eliminate this fundamental weakness. -### Rationale + +# Rationale ASR is a standard that ensures the user’s digital currency account assets are not at risk, even if the recovery data is lost or stolen. This is because the recovery process in ASR, in addition to a numerical variable, depends on a private keyword variable. This variable is stored in the user’s memory or in a separate location from the numerical variable and acts as the key for recovery. It consists of only 12 English letters, which are easy to remember or can be stored separately from the numerical variable to ensure that even if the numerical recovery data is fully exposed, recovery without the keyword is practically impossible. @@ -27,7 +29,7 @@ This is because the recovery process in ASR, in addition to a numerical variable ASR is not a static recovery mechanism; rather, it is a network-dependent, account-state-dependent, and Core security policy-dependent recovery system. This design transforms asset recovery from a single point of failure into a multi-stage, auditable, and adaptive attack-resistant process. -### Overall ASR Architecture +# Overall ASR Architecture ASR consists of three main components: . ASR-REC: Recovery Numbers @@ -41,10 +43,10 @@ Each number falls within the range 0000 to 9999. This range operates in a modular manner. These values are displayed to the user in groups of four digits, separated by - and prefixed with ASR-REC. -# Example of ASR-REC Display Format +### Example of ASR-REC Display Format ASR-REC-1185-7517-7217-1362-1364-1388-4765-6867-7966-6765-2678-6765 -# Display Requirements +### Display Requirements · Mandatory Left-to-Right · Mandatory ASCII @@ -58,7 +60,7 @@ This variable is exclusively held by the user and stored either in the user’s ASR-VAR is not stored on the network or in the wallet. This variable is considered the access key to the assets, and without ASR-VAR, neither the network nor the wallet can map ASR-REC to an account. -# Display Requirements +### Display Requirements . Uppercase letters A–Z only . ASCII encoding only . No spaces @@ -69,7 +71,7 @@ This variable is considered the access key to the assets, and without ASR-VAR, n The repetition restriction is applied to prevent the selection of extremely low-entropy variables (e.g., AAAAAAAAAAAA) and is comparable to password policy standards in secure systems. Allowing up to two consecutive repeated letters ensures linguistic compatibility with natural English language structures. -# Example ASR-VAR Display: +### Example ASR-VAR Display: ASR-VAR-SUNBOYINHOME Each ASR-VAR lexical character, after entering the cryptographic cycle specific to this standard ASR-CRC , is used by default to encrypt four digits of ASR-REC. @@ -82,12 +84,12 @@ The cyclic cryptographic core is responsible for: . Executing cryptographic cycles via additive variable aggregation to expand numerical digit ranges . Ensuring full coverage of the numerical range 0000 to 9999 in the default ASR configuration -# Letter-to-Number Mapping +### Letter-to-Number Mapping The ASR-VAR vocabulary consists exclusively of uppercase English letters A–Z in ASCII. Each letter corresponds to a number: A = 1, B = 2, …, Z = 26 -# Cryptographic Cycle Execution: +### Cryptographic Cycle Execution: First, the lexical variables are converted into a numeric sequence, written inside brackets, and separated by - Then, each variable is added to the next variable in sequence; the last variable is added modularly to the first. This is performed for all 12 values. @@ -95,11 +97,11 @@ The results are written inside brackets and separated by - forming the next cycl With repeated aggregation, subsequent cycles produce numbers with increasing digit lengths. These cycles continue until the last variable exceeds four digits (in the default ASR configuration). -# Full Range Coverage Guarantee: +### Full Range Coverage Guarantee: Once variable values exceed four digits, only the rightmost four digits of each value are extracted for integration, and the remaining leftmost digits are discarded. Continuation of the cycles is necessary to guarantee full coverage of the numeric range 0000 to 9999. -# Complete Practical Example of the ASR-CRC Cryptographic Model +### Complete Practical Example of the ASR-CRC Cryptographic Model Assume the user selects the following ASR-VAR @@ -148,14 +150,14 @@ Result: The cycles continue until the last variable exceeds four digits for all variables. Then, in the above assumption, as well as in the default ASR standard, only the rightmost four digits resulting from the cycle of each variable enter the integration stage, and the remaining left digit(s) of each variable are ignored. -# Modular Integration of ASR-CRC Output with ASR-REC (with Example) +### Modular Integration of ASR-CRC Output with ASR-REC (with Example) In ASR, the user’s private variable (ASR-VAR) is first processed through the ASR-CRC core. The output of this process is a four-digit numeric value (ASR-CRC Output), which serves as an intermediate recovery value and cannot independently reconstruct the Seed or private key. This four-digit value is then modularly added to each four-digit ASR-REC number, and the final result is displayed to the user. If the sum exceeds 9999, the calculation continues modularly from 0000. -# In another example, with hypothetical numbers different from the previous example. +### In another example, with hypothetical numbers different from the previous example. Assume: The value of the first four-digit number in ASR-REC is equal to: @@ -169,7 +171,7 @@ In this case, the integration is performed as follows: The value 6666 is displayed as the ASR-REC value to the user. -# Recovery Process +### Recovery Process During recovery, the user enters 6666 as the first ASR-REC value. After entering ASR-VAR, the wallet reruns ASR-CRC and calculates: ASR-CRC Output = 2222 @@ -329,10 +331,10 @@ In wallet implementation: ## Responsibilities -# User Responsibilities +### User Responsibilities Maintain ASR-VAR and ASR-REC separately -# Wallet Responsibilities +### Wallet Responsibilities The wallet performs all local cryptographic recovery computations . Storing ASR-REC @@ -351,7 +353,7 @@ The wallet: This limitation is a fundamental security constraint in the ASR design, not an implementation flaw. -# Role and Responsibilities of the Core Network in the ASR Recovery Process +### Role and Responsibilities of the Core Network in the ASR Recovery Process The Core network in ASR does not act as a "computing engine" or "Seed holder". Instead, it is responsible for providing the final degree of freedom necessary to complete the recovery. @@ -370,7 +372,7 @@ The network: However, without issuing the NRA, the Seed reconstruction process is cryptographically and engineering-wise impossible to complete. This dependency is not an ownership control mechanism, but a network‑centric security constraint to prevent unauthorized recovery and adaptive attacks. -# ASR Network Layer Responsibilities +### ASR Network Layer Responsibilities . No smart contracts . No gas or fees @@ -379,7 +381,8 @@ This dependency is not an ownership control mechanism, but a network‑centric s · Each subsequent block of 3 unsuccessful attempts → Apply a time restriction double the previous one (e.g., 24h → 48h → 96h → ...). · Mandatory: When a restriction is applied, a countdown timer must be displayed to the user, indicating the remaining waiting time. -### Delayed Account Activation Option + +# Delayed Account Activation Option When viewing recovery data, the user can enable the Delayed Account Activation option (disabled by default). The user can select a delay period from 1 to 94 days and register it with the owner’s signature on the network. @@ -399,7 +402,7 @@ If this option is enabled, whenever a **Network Recovery Authorization (NRA)** i **Security note:** If the owner still has access to a previously active wallet, they can, upon detecting suspicious activity or a potential attack, stop the new account activation process before the delay ends by providing a valid signature. -# Definition of “Owner Activity” +### Definition of “Owner Activity” Any valid on-chain transaction signed by the owner that changes network state, including but not limited to . Asset transfers @@ -507,7 +510,7 @@ In engineering terms: ASR replaces the Mnemonic, not the Seed. -# Engineering Conclusion +### Engineering Conclusion ASR is not a key generation standard. @@ -522,7 +525,8 @@ transforms the recovery layer from a single point of failure into a multi-stage, This precise positioning introduces ASR as an independent, complementary layer in cryptographic wallet architecture, not a replacement for key generation standards. -### Absolute Prohibition of Offline Recovery in ASR + +# Absolute Prohibition of Offline Recovery in ASR Unlike BIP-39, where recovery is completely offline, ASR is fundamentally designed to be network‑dependent. @@ -533,7 +537,8 @@ Full recovery is conditional upon receiving a Network Recovery Authorization (NR In the absence of NRA, recovery is engineering‑wise impossible. -### Threat Model + +# Threat Model The ASR standard is designed to protect the account recovery process against threats related to the disclosure of recovery data, and not to counter full compromise of the user's execution environment. 1. ASR is resilient against: @@ -556,7 +561,8 @@ The ASR standard is designed to protect the account recovery process against thr · Attacks based on full device control at the time of owner signing · Non‑cryptographic attacks such as physical coercion or in‑person social engineering -### Why ASR Is a Recovery Alternative to BIP-39 (Design Rationale) + +# Why ASR Is a Recovery Alternative to BIP-39 (Design Rationale) BIP-39 is a Seed generation standard that makes recovery dependent on full knowledge of the Mnemonic. In this model, recovery is a completely offline, unsupervised process with no distinction between the legitimate owner and an attacker. @@ -579,7 +585,8 @@ The key differences are: As a result, ASR enhances security not by replacing basic cryptography, but by completely redesigning the concept of digital asset recovery. -### Summary + +# Summary ASR is not a recovery phrase; it is a security‑oriented, network‑dependent recovery system. In this standard, the recovery process is deliberately underdetermined, and even with full possession of the user's recovery data, reconstructing the Seed or controlling the assets is impossible without a recovery authorization issued by the network. From aad787e912936b4e290d1f7d77e78dcd817631ac Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 18 Jun 2026 09:21:26 +0330 Subject: [PATCH 08/20] Update tip-asr.md --- tip-asr.md | 43 ++++++++++++++++++++++--------------------- 1 file changed, 22 insertions(+), 21 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 142a247..92986e5 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -10,25 +10,24 @@ created: 2026-05-02 requires: replaces: --- - ASR – Adaptive Secure Recovery Adaptive Secure Recovery Standard for Cryptocurrency Accounts - - +___ +___ # Introduction One of the most significant challenges in the cryptocurrency ecosystem is the secure storage of Seed Phrases. Standard protocols like BIP-39, despite their simplicity and widespread adoption, lack any independent cryptographic layer or active defense mechanisms. Consequently, if the seed phrase is compromised, the user’s entire assets become accessible and transferable without any security barriers. In this context, the ASR standard is introduced to eliminate this fundamental weakness. - - +___ +___ # Rationale ASR is a standard that ensures the user’s digital currency account assets are not at risk, even if the recovery data is lost or stolen. This is because the recovery process in ASR, in addition to a numerical variable, depends on a private keyword variable. This variable is stored in the user’s memory or in a separate location from the numerical variable and acts as the key for recovery. It consists of only 12 English letters, which are easy to remember or can be stored separately from the numerical variable to ensure that even if the numerical recovery data is fully exposed, recovery without the keyword is practically impossible. ASR is not a static recovery mechanism; rather, it is a network-dependent, account-state-dependent, and Core security policy-dependent recovery system. This design transforms asset recovery from a single point of failure into a multi-stage, auditable, and adaptive attack-resistant process. - - +___ +___ # Overall ASR Architecture ASR consists of three main components: @@ -380,8 +379,8 @@ This dependency is not an ownership control mechanism, but a network‑centric s · First block of 3 unsuccessful attempts → Apply a 24-hour restriction. · Each subsequent block of 3 unsuccessful attempts → Apply a time restriction double the previous one (e.g., 24h → 48h → 96h → ...). · Mandatory: When a restriction is applied, a countdown timer must be displayed to the user, indicating the remaining waiting time. - - +___ +___ # Delayed Account Activation Option When viewing recovery data, the user can enable the Delayed Account Activation option (disabled by default). @@ -389,17 +388,19 @@ The user can select a delay period from 1 to 94 days and register it with the ow If this option is enabled, whenever a **Network Recovery Authorization (NRA)** is issued by the network and account recovery succeeds, the newly recovered account will remain inactive until the end of the delay period. -**Displaying Recovered Devices with a Single RCID and the Ability to Terminate Previous Sessions:** +### Displaying Recovered Devices with a Single RCID and the Ability to Terminate Previous Sessions: + - It should be possible to view active and inactive devices associated with an RCID, as well as to terminate previous sessions for ASR accounts. -- **Limitation for newly recovered accounts:** A newly recovered account will not be able to terminate previous sessions for 30 days after activation. +- Limitation for newly recovered accounts: +A newly recovered account will not be able to terminate previous sessions for 30 days after activation. -**Status during the delay period:** +### Status during the delay period: - Assets are view‑only. - No signed operations by the owner are permitted before the delay ends. - A countdown timer shows the remaining time to the user. - Notifications are sent to previously active wallets. -**Security note:** +### Security note: If the owner still has access to a previously active wallet, they can, upon detecting suspicious activity or a potential attack, stop the new account activation process before the delay ends by providing a valid signature. ### Definition of “Owner Activity” @@ -524,8 +525,8 @@ ASR is a Secure Recovery Standard that: transforms the recovery layer from a single point of failure into a multi-stage, network-dependent process. This precise positioning introduces ASR as an independent, complementary layer in cryptographic wallet architecture, not a replacement for key generation standards. - - +___ +___ # Absolute Prohibition of Offline Recovery in ASR Unlike BIP-39, where recovery is completely offline, ASR is fundamentally designed to be network‑dependent. @@ -536,8 +537,8 @@ The output of all ASR components is only an intermediate recovery value. Full recovery is conditional upon receiving a Network Recovery Authorization (NRA) from the Core network. In the absence of NRA, recovery is engineering‑wise impossible. - - +___ +___ # Threat Model The ASR standard is designed to protect the account recovery process against threats related to the disclosure of recovery data, and not to counter full compromise of the user's execution environment. @@ -560,8 +561,8 @@ The ASR standard is designed to protect the account recovery process against thr · Compromise of operating system, firmware, or runtime · Attacks based on full device control at the time of owner signing · Non‑cryptographic attacks such as physical coercion or in‑person social engineering - - +___ +___ # Why ASR Is a Recovery Alternative to BIP-39 (Design Rationale) BIP-39 is a Seed generation standard that makes recovery dependent on full knowledge of the Mnemonic. @@ -584,8 +585,8 @@ The key differences are: In ASR, the network is part of the recovery security model. As a result, ASR enhances security not by replacing basic cryptography, but by completely redesigning the concept of digital asset recovery. - - +___ +___ # Summary ASR is not a recovery phrase; it is a security‑oriented, network‑dependent recovery system. From 4a631d40e1ac7b52e8e0508f64b24c8c800e3e1c Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 31 Aug 2026 01:49:09 +0330 Subject: [PATCH 09/20] Update tip-asr.md --- tip-asr.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 92986e5..ebd7447 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -272,14 +272,14 @@ To prevent adaptive online brute-force attacks and any attempt to bypass network This identifier must have the following characteristics: -· Derived deterministically and ONLY from the raw ASR-REC data -· Completely independent of: - · ASR-VAR - · ASR-CRC outputs - · Recovery Proof - · Wallet version, client, IP, or network conditions -· Remains constant for all recovery attempts associated with a fixed, unchanging ASR-REC -· Generated before any user interaction with the cryptographic process +- Derived deterministically and ONLY from the raw ASR-REC data +- Completely independent of: + - ASR-VAR + - ASR-CRC outputs + - Recovery Proof + - Wallet version, client, IP, or network conditions +- Remains constant for all recovery attempts associated with a fixed, unchanging ASR-REC +- Generated before any user interaction with the cryptographic process To state it more explicitly: From 944361eec2c8753a79c288702c356d5f8c1fb1d5 Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 31 Aug 2026 01:57:11 +0330 Subject: [PATCH 10/20] Update tip-asr.md --- tip-asr.md | 208 ++++++++++++++++++++++++++--------------------------- 1 file changed, 104 insertions(+), 104 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index ebd7447..ae92aec 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -31,9 +31,9 @@ ___ # Overall ASR Architecture ASR consists of three main components: -. ASR-REC: Recovery Numbers -. ASR-VAR: Variable Secret -. ASR-CRC: Cyclic Reduction Core +- ASR-REC: Recovery Numbers +- ASR-VAR: Variable Secret +- ASR-CRC: Cyclic Reduction Core ## Component One: ASR-REC (Recovery Numbers) @@ -47,9 +47,9 @@ ASR-REC-1185-7517-7217-1362-1364-1388-4765-6867-7966-6765-2678-6765 ### Display Requirements -· Mandatory Left-to-Right -· Mandatory ASCII -· Mandatory uniform formatting using "-" and displaying ASR-REC to the left of the numerical variable to prevent homography attacks +- Mandatory Left-to-Right +- Mandatory ASCII +- Mandatory uniform formatting using "-" and displaying ASR-REC to the left of the numerical variable to prevent homography attacks In the ASR standard, the user can store the ASR-REC digits without concern, because the recovery process, in addition to having ASR-REC, also requires a private lexical variable called ASR-VAR. @@ -60,12 +60,12 @@ ASR-VAR is not stored on the network or in the wallet. This variable is considered the access key to the assets, and without ASR-VAR, neither the network nor the wallet can map ASR-REC to an account. ### Display Requirements -. Uppercase letters A–Z only -. ASCII encoding only -. No spaces -. Left-to-Right display -. Uniform formatting with "-" with ASR-VAR displayed to the left of the variable to prevent homography attacks -. A maximum of two consecutive repeated letters is allowed +- Uppercase letters A–Z only +- ASCII encoding only +- No spaces +- Left-to-Right display +- Uniform formatting with "-" with ASR-VAR displayed to the left of the variable to prevent homography attacks +- A maximum of two consecutive repeated letters is allowed The repetition restriction is applied to prevent the selection of extremely low-entropy variables (e.g., AAAAAAAAAAAA) and is comparable to password policy standards in secure systems. Allowing up to two consecutive repeated letters ensures linguistic compatibility with natural English language structures. @@ -79,9 +79,9 @@ Each ASR-VAR lexical character, after entering the cryptographic cycle specific This system structurally increases the cost of each guess or attack attempt by creating exponential growth in computational states. The cyclic cryptographic core is responsible for: -. Converting letters to numbers -. Executing cryptographic cycles via additive variable aggregation to expand numerical digit ranges -. Ensuring full coverage of the numerical range 0000 to 9999 in the default ASR configuration +- Converting letters to numbers +- Executing cryptographic cycles via additive variable aggregation to expand numerical digit ranges +- Ensuring full coverage of the numerical range 0000 to 9999 in the default ASR configuration ### Letter-to-Number Mapping The ASR-VAR vocabulary consists exclusively of uppercase English letters A–Z in ASCII. @@ -193,9 +193,9 @@ Without ASR-VAR, ASR-REC cannot be reconstructed Even with ASR-REC and ASR-VAR, recovery cannot be completed without network authorization Recovery requires the simultaneous presence of three independent factors -. ASR-REC -. ASR-VAR -. Network-issued Recovery Authorization +- ASR-REC +- ASR-VAR +- Network-issued Recovery Authorization This design transforms recovery from a static operation into a controlled, network-dependent, abuse-resistant process. @@ -209,9 +209,9 @@ The final degree of mathematical freedom required to determine the Seed is provi 2. Explicit Separation of Local Computation and Final Recovery Control All cryptographic operations -. ASR-CRC execution -. Recovery Proof generation -. ASR-VAR processing +- ASR-CRC execution +- Recovery Proof generation +- ASR-VAR processing are performed locally in the wallet. However, these computations alone never produce the Seed or private key. @@ -221,10 +221,10 @@ Final recovery control depends exclusively on the issuance of Network Recovery A Completion of the recovery process in ASR is subject to receiving a Network Recovery Authorization (NRA), which: -. Without owner signature -. Without smart contracts -. Without fees or gas -. Only while online +- Without owner signature +- Without smart contracts +- Without fees or gas +- Only while online Without NRA, Seed reconstruction is cryptographically and engineering-wise impossible. @@ -235,26 +235,26 @@ To prevent adaptive online brute-force attacks, the wallet is required to genera This identifier: -· Is independent of ASR-VAR -· Is independent of variable cryptographic outputs -· Remains constant for all recovery attempts of a single account +- Is independent of ASR-VAR +- Is independent of variable cryptographic outputs +- Remains constant for all recovery attempts of a single account Network policies such as rate limits, delays, and attempt counters are applied based on this identifier, not based on the Proof or cryptographic variables. 5. Ineffectiveness of Attacker Variable Changes Changing any of the following does not create a new recovery context: -. ASR-VAR -. Wallet client or version -. IP, VPN, Tor, or network source -. Recovery Proof +- ASR-VAR +- Wallet client or version +- IP, VPN, Tor, or network source +- Recovery Proof All these attempts are mapped to a single Recovery Context and will be subject to network restrictions. 6. Minimum Disclosure Principle During recovery The network, during the recovery process -. Has no access to ASR-VAR -. Does not store Seeds or private keys -. Does not interpret Recovery Proof contents +- Has no access to ASR-VAR +- Does not store Seeds or private keys +- Does not interpret Recovery Proof contents The network only issues or denies recovery authorization based on account state and security policies. @@ -291,19 +291,19 @@ The wallet is required to send the generated RCID along with the Network Recover The network applies all security policies, including: -· Rate Limit -· Delay -· Attempt counters -· Progressive time-based restrictions +- Rate Limit +- Delay +- Attempt counters +- Progressive time-based restrictions based on the RCID, not on cryptographic variables, Proof, or user inputs. Consequently, changing any of the following by an attacker: -· Changing ASR-VAR -· Changing Recovery Proof -· Changing IP, VPN, Tor, or network source -· Changing wallet/client version or type +- Changing ASR-VAR +- Changing Recovery Proof +- Changing IP, VPN, Tor, or network source +- Changing wallet/client version or type will not create a new recovery context. @@ -325,8 +325,8 @@ Implementation MUST In wallet implementation: -· RCID generation must be performed before receiving any user input and before any cryptographic processing. -· Any dependency of RCID on ASR-VAR, CRC output, Proof, or execution conditions is considered a violation of ASR security requirements. +- RCID generation must be performed before receiving any user input and before any cryptographic processing. +- Any dependency of RCID on ASR-VAR, CRC output, Proof, or execution conditions is considered a violation of ASR security requirements. ## Responsibilities @@ -336,19 +336,19 @@ Maintain ASR-VAR and ASR-REC separately ### Wallet Responsibilities The wallet performs all local cryptographic recovery computations -. Storing ASR-REC -. Receiving and processing ASR-VAR -. Executing ASR-CRC -. Generating Recovery Proof +- Storing ASR-REC +- Receiving and processing ASR-VAR +- Executing ASR-CRC +- Generating Recovery Proof However, the wallet is deliberately designed to lack the ability to independently reconstruct the Seed or derive the private key. Even with correct and complete execution of all local steps, the recovery process will not converge to a single value without receiving the additional data issued by the Core network. The wallet: -· Is not the owner of the Seed -· Does not have final control over the account -· Cannot complete recovery offline or unilaterally +- Is not the owner of the Seed +- Does not have final control over the account +- Cannot complete recovery offline or unilaterally This limitation is a fundamental security constraint in the ASR design, not an implementation flaw. @@ -358,27 +358,27 @@ The Core network in ASR does not act as a "computing engine" or "Seed holder". I Network responsibilities are limited to the following: -· Evaluating account status and active security policies -· Applying rate limits, delays, and attempt counters based on the Recovery Context -· Issuing or denying the Network Recovery Authorization (NRA) +- Evaluating account status and active security policies +- Applying rate limits, delays, and attempt counters based on the Recovery Context +- Issuing or denying the Network Recovery Authorization (NRA) The network: -· Has no access to ASR-VAR -· Does not store or reconstruct the Seed or private key -· Does not participate in the wallet's local cryptographic computations +- Has no access to ASR-VAR +- Does not store or reconstruct the Seed or private key +- Does not participate in the wallet's local cryptographic computations However, without issuing the NRA, the Seed reconstruction process is cryptographically and engineering-wise impossible to complete. This dependency is not an ownership control mechanism, but a network‑centric security constraint to prevent unauthorized recovery and adaptive attacks. ### ASR Network Layer Responsibilities -. No smart contracts -. No gas or fees -. Core logic level -· First block of 3 unsuccessful attempts → Apply a 24-hour restriction. -· Each subsequent block of 3 unsuccessful attempts → Apply a time restriction double the previous one (e.g., 24h → 48h → 96h → ...). -· Mandatory: When a restriction is applied, a countdown timer must be displayed to the user, indicating the remaining waiting time. +- No smart contracts +- No gas or fees +- Core logic level +- First block of 3 unsuccessful attempts → Apply a 24-hour restriction. +- Each subsequent block of 3 unsuccessful attempts → Apply a time restriction double the previous one (e.g., 24h → 48h → 96h → ...). +- Mandatory: When a restriction is applied, a countdown timer must be displayed to the user, indicating the remaining waiting time. ___ ___ # Delayed Account Activation Option @@ -406,12 +406,12 @@ If the owner still has access to a previously active wallet, they can, upon dete ### Definition of “Owner Activity” Any valid on-chain transaction signed by the owner that changes network state, including but not limited to -. Asset transfers -. Voting -. Freeze/unfreeze -. Stake/unstake -. Reward withdrawal -. Direct smart contract calls +- Asset transfers +- Voting +- Freeze/unfreeze +- Stake/unstake +- Reward withdrawal +- Direct smart contract calls Receiving assets without owner signature is not considered activity. @@ -437,12 +437,12 @@ Where ASR Fits in This Chain The ASR standard does not change any of the following processes: -· Entropy generation -· Seed generation -· Key Derivation Functions (KDF) -· Private and public key generation -· HD Wallet structure -· Network cryptographic algorithms +- Entropy generation +- Seed generation +- Key Derivation Functions (KDF) +- Private and public key generation +- HD Wallet structure +- Network cryptographic algorithms All of the above steps remain exactly as before, following existing cryptographic standards. @@ -487,17 +487,17 @@ The Checksum in the ASR standard is used solely to detect typographical errors i The Checksum is generated as a value derived from the ASR-REC data using the SHA-512/256 function, but this value: -· Does not by itself indicate the correctness of ASR-REC -· Does not enable full or definitive validation of the recovery data -· Does not reduce the cryptographic search space +- Does not by itself indicate the correctness of ASR-REC +- Does not enable full or definitive validation of the recovery data +- Does not reduce the cryptographic search space Final validation of recovery data in ASR is inherently network‑dependent and occurs only within the framework of the online recovery process, after verification of account status and Core network security policies. Consequently: -· The Checksum in ASR is merely a user‑experience aid -· It provides no valid path for offline verification of recovery data -· It does not enable recovery or validation independent of the network in any way +- The Checksum in ASR is merely a user‑experience aid +- It provides no valid path for offline verification of recovery data +- It does not enable recovery or validation independent of the network in any way ## Role of KDF and Seed in ASR @@ -517,10 +517,10 @@ ASR is not a key generation standard. ASR is a Secure Recovery Standard that: -· Without changing core network cryptography -· Without changing key algorithms -· Without relying on smart contracts -· Without fees +- Without changing core network cryptography +- Without changing key algorithms +- Without relying on smart contracts +- Without fees transforms the recovery layer from a single point of failure into a multi-stage, network-dependent process. @@ -544,23 +544,23 @@ The ASR standard is designed to protect the account recovery process against thr 1. ASR is resilient against: -· Partial or full disclosure of recovery data (ASR-REC) -· Disclosure of the user's private variable (ASR-VAR) -· Theft of physical or digital backups -· Offline brute‑force attacks (fundamentally impossible) -· Adaptive online brute‑force attacks (using Recovery Context and rate limiting) -· Phishing attacks targeting the recovery process -· Shoulder surfing -· Attempts to recover without network authorization -· Malicious delayed recovery, even in the event of simultaneous theft of all recovery data +- Partial or full disclosure of recovery data (ASR-REC) +- Disclosure of the user's private variable (ASR-VAR) +- Theft of physical or digital backups +- Offline brute‑force attacks (fundamentally impossible) +- Adaptive online brute‑force attacks (using Recovery Context and rate limiting) +- Phishing attacks targeting the recovery process +- Shoulder surfing +- Attempts to recover without network authorization +- Malicious delayed recovery, even in the event of simultaneous theft of all recovery data (using Recovery Delay, network notifications, and account‑state dependency) 2. Out of Scope: -· Active malware with simultaneous access to the user's execution environment -· Compromise of operating system, firmware, or runtime -· Attacks based on full device control at the time of owner signing -· Non‑cryptographic attacks such as physical coercion or in‑person social engineering +- Active malware with simultaneous access to the user's execution environment +- Compromise of operating system, firmware, or runtime +- Attacks based on full device control at the time of owner signing +- Non‑cryptographic attacks such as physical coercion or in‑person social engineering ___ ___ # Why ASR Is a Recovery Alternative to BIP-39 (Design Rationale) @@ -573,15 +573,15 @@ Instead, it transforms the recovery process into a conditional, multi‑stage, n The key differences are: -· In BIP‑39, full disclosure of the Mnemonic directly leads to loss of assets. +- In BIP‑39, full disclosure of the Mnemonic directly leads to loss of assets. In ASR, the recovery data alone is incapable of recovery and is useless without network approval. -· BIP‑39 enables offline brute‑force attacks and unlimited attempts without rate limiting. +- BIP‑39 enables offline brute‑force attacks and unlimited attempts without rate limiting. ASR fundamentally makes this class of attacks impossible by eliminating offline recovery. -· BIP‑39 has no native concept of "recovery control, suspension, or rejection." +- BIP‑39 has no native concept of "recovery control, suspension, or rejection." ASR turns recovery into an observable, rate‑limit‑able, and policy‑governable event at the network level. -· BIP‑39 reduces recovery to a single point of failure. +- BIP‑39 reduces recovery to a single point of failure. ASR eliminates this single point of failure by separating ASR‑REC, ASR‑VAR, and network verification cycles. -· In BIP‑39, the network is unaware of the recovery process. +- In BIP‑39, the network is unaware of the recovery process. In ASR, the network is part of the recovery security model. As a result, ASR enhances security not by replacing basic cryptography, but by completely redesigning the concept of digital asset recovery. From 3510458853daa88d67e19fb51d53305ca31aad83 Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 9 Oct 2026 18:37:14 +0330 Subject: [PATCH 11/20] Update tip-asr.md --- tip-asr.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/tip-asr.md b/tip-asr.md index ae92aec..df99022 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -198,8 +198,14 @@ Recovery requires the simultaneous presence of three independent factors - Network-issued Recovery Authorization This design transforms recovery from a static operation into a controlled, network-dependent, abuse-resistant process. +___ +___ +# Network-Dependent Account Recovery in ASR: Architectural Constraints and the Impossibility of Offline Recovery + -## Additional Engineering Considerations and Security Constraints +___ +___ +# Additional Engineering Considerations and Security Constraints 1. Intentionally Underdetermined Recovery From e01663f92c435af1b6b1430892f2ff8404e470ff Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 9 Oct 2026 19:38:19 +0330 Subject: [PATCH 12/20] Update tip-asr.md --- tip-asr.md | 1245 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1245 insertions(+) diff --git a/tip-asr.md b/tip-asr.md index df99022..02d4ff4 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -203,6 +203,1251 @@ ___ # Network-Dependent Account Recovery in ASR: Architectural Constraints and the Impossibility of Offline Recovery +In the ASR standard, the impossibility of offline recovery is not a flaw or implementation limitation, but a design feature. Unlike common standards such as BIP-39, where the entire recovery process is offline and solely dependent on recovery words, ASR, in addition to offline dependence on two values ASR-VAR and ASR-REC_Display, is fundamentally based on receiving data from the network. + +The reason for network dependence is the separation of Final_Entropy into two independent shares: + +· First, the local share (key_local): which is reconstructed from the user's recovery data and the ASR-REC_Main structure. +· Second, key_network is generated by the wallet and sent to the network. The network stores the key_network sent by the wallet in Core Recovery Key Network Storage and returns a successful storage confirmation message to the wallet. + +During the Enrollment phase, the wallet temporarily generates key_network and keeps it in memory to send it in the Enrollment message and receive its successful registration from the network. + +After successful completion of Enrollment and receiving the confirmation message, the temporary copy of key_network MUST be erased from the wallet's memory, and the wallet MUST NOT store, retain, display, or provide it to the user. Because: + +· key_network is a recovery key belonging to the network, not a user key. +· The user's responsibility is limited to safeguarding and maintaining ASR-REC_Display and ASR-VAR. +· Displaying key_network to the user increases the risk of leakage through user error (screenshots, notes, insecure storage). +· This violates the architectural separation between user data and network data. + +Reconstruction of Final_Entropy is only possible through the XOR combination of these two shares: + +``` +Final_Entropy = key_local XOR key_network +``` + +Therefore, disclosure of ASR-REC_Display or ASR-VAR alone, even with very high computational power, is not sufficient to reconstruct Final_Entropy; because each of these two components alone does not provide the attacker with the necessary information to complete the recovery process. + +The precise security statement of ASR is: + +Complete offline recovery, under the threat model defined for ASR, is not possible; because Final_Entropy is composed of key_local and key_network, and key_network can only be obtained through the network-based Recovery path. + +Furthermore, disclosure of one of the two components ASR-REC_Display or ASR-VAR alone is not sufficient to reconstruct key_local and obtain key_network from the network, and the attacker needs both components to complete this step. + +Supplementary explanations on structure and mechanism + +1. Dual-Mode Display Structure of ASR for the User + +The recovery standard in ASR has two modes: 12-number and 24-number, and backup is performed based on one of these two modes, chosen by the user. + +When starting the backup process, the wallet presents both modes to the user so they can choose one. After selecting either the 12-number or 24-number mode, the rest of the generation and recovery process is carried out by the wallet based on that choice. + +12-number mode + +· ASR-REC = 12 four-digit numbers with 13-bit capacity and original number range: 0000 to 8191, totaling 8192 states +· ASR-VAR = 12 uppercase English letters with range A to Z + +``` +12 × 13 = 156 bits +Nominal entropy = 156 bits +``` + +24-number mode + +· ASR-REC = 24 four-digit numbers with 13-bit capacity and original number range: 0000 to 8191, totaling 8192 states +· ASR-VAR = 24 uppercase English letters with range A to Z + +``` +24 × 13 = 312 bits +Nominal entropy = 312 bits +``` + +The 24-number mode provides a much higher security margin and greater theoretical and numerical resistance against quantum search, based on the NIST standard. + +The choice between these two modes (12-number and 24-number, with 13-bit four-digit numbers) MUST be made by the user when starting the recovery process. The wallet cannot display the 12-number mode by default or impose it on the user in any way; rather, wallets MUST display both the 12 and 24-number modes to the user in the first step of backup, so the user can choose one and continue the backup steps based on their choice. + +2. Removal of Checksum from the ASR Architecture + +The ASR standard does not use a Checksum in its core structure. + +Checksum is typically used to detect data entry or transmission errors and is not a cryptographic mechanism or a security-enhancing factor. In the ASR architecture, given that the format, length, type, and range of inputs are precisely defined in the standard beforehand, and wallets are required to validate these rules, Checksum is not considered an essential component for ASR security. + +Reason for removing Checksum + +One of the fundamental principles of ASR is to prevent the recovery process from becoming a problem that can be solved offline (Offline Recovery). + +Adding a Checksum creates an additional validation rule that, if the attacker has the necessary data for verification, can allow them to eliminate invalid combinations without going through the complete network recovery process. + +ASR has explicit formats and rules for error detection, implementation, and validation. Checksum, as an additional validation constraint, can in certain scenarios further limit the space of acceptable combinations for an attacker. Therefore, ASR refrains from adding unnecessary constraints to its recovery standard. + +ASR does not use Checksum to increase the acceptable search space, and Checksum is not considered part of ASR's security entropy. + +This decision is more compatible with ASR architectural principles based on tying the recovery process to two variables and the network. + +Difference from BIP-39 + +In BIP-39, Checksum is used for word structure, detecting some input errors, or random changes in the recovery phrase. ASR does not define such a Checksum in its structure. Instead, wallets are required to validate the format, number, character type, and value range of ASR-REC_Display and ASR-VAR according to the standard. This validation detects format errors, but does not claim to detect all typographical errors or valid value transpositions. + +No Checksum in ASR-VAR + +In the ASR standard, the ASR-VAR input is explicitly limited. + +In 12-number mode: + +``` +ASR-VAR = 12 uppercase English letters +Allowed characters = A-Z +``` + +In 24-number mode: + +``` +ASR-VAR = 24 uppercase English letters +Allowed characters = A-Z +``` + +ASR-compliant wallets MUST check this limitation before continuing the Recovery process (and before computing ASR-CRC). + +Therefore, the wallet must not accept inputs such as the following as valid ASR-VAR: + +· a-z (lowercase letters) +· 0-9 (digits) +· Persian characters +· Arabic characters +· symbols +· spaces +· other Unicode characters + +Since wallets are required to check and validate the type and format of characters entered by the user according to the ASR standard, this largely covers the need for a Checksum to detect user input errors. + +ASR-REC Validation without Checksum + +The ASR-REC input also has a specific and limited format in the ASR standard. + +Each ASR-REC value consists of 12 four-digit 13-bit numbers in the range 0000 to 8191, and the input set must consist solely of allowed digits. + +ASR-compliant wallets MUST check the following: + +· The number of values is correct; +· Each value has exactly four digits; +· Values are in the range 0000–8191; +· The overall structure of ASR-REC matches the selected mode; +· Values outside the rules defined by the protocol are rejected. +· Entry and display of numbers use English characters. + +Therefore, a Checksum is not necessary for detecting structural and format errors in ASR-REC either. + +Difference between Checksum and Format Validation + +ASR distinguishes between these two concepts: + +Format Validation: To check whether the input is structurally compliant with the standard. + +``` +ASR-VAR → A-Z +ASR-REC → decimal digits 0000–8191 +``` + +Checksum: An additional control value to detect certain errors. + +ASR uses Format Validation, but does not define Checksum as a security component or part of the Recovery structure. + +Effect on Entropy + +With the removal of Checksum, no independent bits are subtracted from the ASR-REC space for Checksum. + +Therefore, assuming uniform generation of original values: + +12-number mode: + +``` +12 × 13 = 156 bits +Nominal entropy = 156 bits +``` + +24-number mode: + +``` +24 × 13 = 312 bits +Nominal entropy = 312 bits +``` + +In these calculations, Checksum has no contribution to reducing entropy, because it is essentially not part of the ASR architecture. + +Removing Checksum does not mean that ASR has no input validation at all. + +On the contrary, ASR performs validation at the level of format, length, range, and data structure, but refrains from adding an unnecessary cryptographic constraint to its Recovery space, especially when such a constraint could be used independently to filter out invalid combinations. + +For this reason, ASR lacks a Checksum in both ASR-REC_Main and ASR-VAR, and input validation is performed through explicit standard rules and their mandatory implementation in compliant wallets. + +3. Relationship between ASR-REC and ASR-VAR Variables + +In the twelve-number ASR-REC mode: + +· ASR-VAR consists of 12 English letter variables (uppercase A to Z). + +In the twenty-four-number ASR-REC mode: + +· ASR-VAR consists of 24 English letter variables (uppercase A to Z). + +Each character of ASR-VAR, after conversion to a numeric value and passing through the ASR-CRC cycle, produces a four-digit output. This four-digit output is modularly combined with the corresponding value in ASR-REC, and the final result is displayed to the user as ASR-REC_Display. + +Therefore: + +``` +12 ASR-VAR characters ↔ 12 ASR-REC positions +``` + +and: + +``` +24 ASR-VAR characters ↔ 24 ASR-REC positions +``` + +Corresponding to the increase in numeric variables of ASR-REC from 12 four-digit numbers to 24 four-digit numbers, the letter variables of ASR-VAR also increase from 12 letter variables to 24 letter variables. This increase is necessary and essential to preserve the structure, execution steps, and operation of ASR-CRC cycles, without changing the ASR architectural logic. + +4. One-Way Recovery Identifiers + +To prevent direct transmission of ASR-REC_Display and ASR-VAR to the network, ASR uses two one-way identifiers: + +ASR-REC_Display Identifier: + +``` +ASR-REC_Display_ID = SHA-256(Canonical_ASR-REC_Display) +``` + +ASR-VAR Identifier: + +``` +ASR-VAR_ID = SHA-256(Canonical_ASR-VAR) +``` + +Both outputs are SHA-256 and are 32 bytes long. + +These identifiers can be converted to a standard representation for transmission and storage. + +Important Principle + +SHA-256 is a one-way hash function. Computing the identifier from the input data is fast and easy, but directly recovering the input from the hash is computationally infeasible. + +However, ASR security should not rely on the secrecy of these two identifiers. + +In particular: + +ASR-REC_Display_ID and ASR-VAR_ID are not considered secrets. + +The main security of ASR is based on the principle that the attacker, as long as they do not simultaneously have access to both ASR-REC_Display and ASR-VAR, will never reach key_network. + +key_network is an essential component for reconstructing Final_Entropy and is exclusively held by the network. The network provides key_network to the user only after receiving ASR-REC_Display_ID and ASR-VAR_ID and the successful completion of the Recovery process by the wallet. + +Any attempt to bypass the network, without possessing both ASR-REC_Display and ASR-VAR variables, is strictly limited by the Rate Limiting policy. + +5. NRA — Network Recovery Authorization + +NRA (Network Recovery Authorization) means network recovery authorization. + +In the ASR architecture, NRA is a control authorization issued by the network's Recovery Service and is used in two main stages: + +First — Enrollment Stage + +During Enrollment, the wallet sends the information required for account recovery — including the following — along with a signature from the account's Access Key to the network: + +· ASR_Version +· ASR-REC_Display_ID +· ASR-VAR_ID +· key_network +· Recovery_Mode +· Nonce +· Enrollment_Signature + +After successful validation of the Access Key signature by network nodes and verification of other Recovery parameters, the information is recorded and stored in Core Recovery Key Network Storage. Then the network returns an NRA to the wallet. + +This NRA indicates to the wallet that the account's Recovery information has been successfully stored in the designated network infrastructure (recovery storage). + +Second — Recovery Stage + +NRA in the Recovery stage acts as the control authorization for the recovery process, which is issued after full validation of the request and returned to the wallet along with ASR_Version and key_network. + +Steps for the wallet to obtain Recovery information from the network + +In the Recovery process, the wallet first: + +· Sends ASR-REC_Display_ID and Recovery_Mode to the network. + +Then the network issues a PoW_Challenge. + +After solving the PoW, the wallet sends the following to the network: + +· PoW_Solution +· ASR-VAR_ID + +After performing the necessary checks, including: + +· Validation of ASR-REC_Display_ID and matching it with the Recovery record +· Validation of Recovery_Mode and matching it with the Recovery record +· Validity and correctness of PoW +· Validity of ASR-VAR_ID +· Recording necessary values for applying Rate Limit +· Other security policies + +If the submitted information is correct and valid and successful, it returns the following to the wallet: + +· NRA +· ASR_Version +· key_network + +The wallet then reconstructs Final_Entropy using key_local and key_network and completes the account recovery. + +6. Core Recovery Key Network Storage + +key_network is stored in a protected repository called: + +Core Recovery Key Network Storage + +and is under the control of the network's Recovery infrastructure. + +This repository is not a public storage on the blockchain, and its information should not be publicly published on the chain. + +Record Structure + +``` +Core Recovery Key Network Storage +│ +├── Index: (ASR-REC_Display_ID, ASR-VAR_ID) +│ +└── Record: + ├── Account + ├── ASR_Version + ├── Recovery_Mode + ├── ASR-REC_Display_ID + ├── ASR-VAR_ID + ├── key_network + ├── Enrollment_Signature + ├── Signing_Key_ID + ├── Nonce + ├── created_at + └── recovery_status +``` + +Field Descriptions + +· ASR-REC_Display_ID = SHA-256(Canonical_ASR-REC_Display) +· ASR-VAR_ID = SHA-256(Canonical_ASR-VAR) +· ASR_Version specifies the ASR standard version used to create and recover this record. +· Recovery_Mode specifies whether the record corresponds to the 12 or 24-number mode. +· The index (ASR-REC_Display_ID, ASR-VAR_ID) allows the Recovery Service to find the corresponding record. +· Enrollment_Signature is the digital signature of the entire Canonical Enrollment message, not just the key_network signature. +· Signing_Key_ID is the identifier of the signing key. +· Nonce is the unique value of the Enrollment request to prevent Replay. + +Protection of key_network + +During Enrollment, the wallet independently generates key_network using a CSPRNG, then computes key_local = Final_Entropy XOR key_network and encodes the ASR-REC_Main structure based on key_local. It then sends key_network along with other required information and Enrollment_Signature to the Recovery Service. + +After receiving and successfully validating the information, the Recovery Service encrypts the key_network on the network infrastructure side before storing it, using an infrastructure encryption key independent of the account's private key. + +This Storage encryption key must not be derived from the Account Private Key, ASR-REC, ASR-VAR, Account, or any other information recoverable by the user. + +The Storage encryption key must be maintained and protected by the network's secure key management infrastructure and must not be given to the wallet or user. + +Therefore, key_network is stored encrypted in Storage, and the wallet is not responsible for encrypting it for Storage. + +Retrieving key_network + +During Recovery, the wallet first receives the information needed to obtain key_network — including ASR-REC_Display and ASR-VAR — from the user. Then, according to ASR architectural principles and network policies, it initiates the Recovery process in stages: + +1. The wallet first sends ASR-REC_Display_ID and Recovery_Mode to the network's Recovery infrastructure. +2. The network issues a PoW_Challenge. +3. After solving the PoW, the wallet sends PoW_Solution and ASR-VAR_ID. + +If the network confirms the information: + +· The Recovery Service finds the corresponding record. +· The Recovery Service decrypts key_network in the secure infrastructure environment using the Storage encryption key. + +After that, the network returns the following to the wallet through a secure and authenticated internal communication channel: + +· NRA +· ASR_Version +· key_network + +The wallet reconstructs Final_Entropy using key_local and key_network and completes the Recovery process. + +This architecture makes key_network independent of the device, previous wallet installation, or wallet storage location. Therefore, if the wallet is deleted, the device is changed, or a new wallet is installed, upon successful authentication of the Recovery process, the new wallet can obtain key_network from the network's Recovery infrastructure and continue the recovery process. + +7. Requirement for Access Keys Signature to Prevent Replay and Fake key_network Registration in Enrollment + +To prevent fake key_network registration and Replay attacks, every Enrollment request MUST be sent to the recovery infrastructure with a valid signature by the account's Access Keys and a unique Nonce. + +Access Keys are keys that have access to an account's assets and permissions. + +In the signature message, the wallet MUST sign the following Canonical message: + +``` +ASR_Enrollment_Message = + Domain || ASR_Version || Account || Recovery_Mode || + ASR-REC_Display_ID || ASR-VAR_ID || key_network || Nonce +``` + +Enrollment Request Structure + +```json +{ + "Account": "...", + "Recovery_Mode": 12, + "ASR-REC_Display_ID": "...", + "ASR-VAR_ID": "...", + "key_network": "...", + "Nonce": "...", + "Signing_Key_ID": "...", + "Signature": "..." +} +``` + +Recovery Service Checks Before Storage + +· Validity of the signature on the Canonical message +· Belonging of the signing key to the Account +· The signature was produced by a valid Access Key. +· The Nonce has not been used before +· Validation of the structure of ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode +· Validation of the length and structure of key_network +· Store key_network only after all checks succeed +· Return NRA to the wallet, indicating successful registration of key_network in the network recovery infrastructure + +Therefore, the following must be observed: + +· Core Recovery Key Network Storage MUST NOT store any key_network unless the corresponding Enrollment request has been authenticated with a valid signature from an authorized Access Key. +· Every Enrollment request MUST include a unique Nonce. +· The Recovery Service MUST maintain a record of used Nonces with a specified expiry window. Suggested default: 24 hours. +· Any request containing a duplicate Nonce MUST be rejected. +· key_network MUST be encrypted at rest. + +Necessity of Digital Signature in Enrollment + +Requiring a digital signature for Enrollment is essential to prevent fake key_network registration. + +If the signature were not required, an attacker could generate a fake key_network for an arbitrary account and send it to Core Recovery Key Network Storage, creating a fake record, so that during Recovery, the real user encounters an incorrect key_network and their recovery fails. + +This attack can appear as a destructive attack or Denial of Service against the Recovery process. + +Therefore, the Enrollment signature ensures that: + +· Recovery registration must be approved by an authorized Access Key of the account. +· An attacker without access to an authorized Access Key cannot create a valid Enrollment record. +· The integrity of Core Recovery Key Network Storage data is better preserved. + +Enrollment MUST be possible with any valid and authorized Access Key. + +Why Signature Does Not Replace Encryption at Rest + +Digital signature and encryption have two different functions. + +Signature: + +``` +Authenticity + Authorization + Integrity +``` + +Encryption at Rest: + +``` +Confidentiality +``` + +Therefore, ASR uses both separately. + +Digital signature is essential to prevent unauthorized registration of key_network and fake key_network registration for an account, but by itself does not provide confidentiality for key_network in Storage. + +Preventing Circular Dependency + +The account's private key must not be used as the decryption key for key_network in Storage; because such a design could lead to a circular dependency between account recovery and key_network retrieval. + +ASR does not use this design. + +Instead: + +· The Access Key is used in Enrollment for signing and authorization. +· key_network in Storage is protected by an independent Storage Encryption Key. +· Recovery, after meeting the necessary conditions, receives key_network from the Recovery infrastructure. + +Therefore, Signature and Storage Encryption have independent roles. + +8. Generation of key_network + +Step 1 — Generate Final_Entropy + +The wallet generates Final_Entropy using a CSPRNG: + +``` +12-mode → Final_Entropy = 156 bits +24-mode → Final_Entropy = 312 bits +``` + +These sizes, assuming uniform generation, are considered as nominal entropy capacity. + +Step 2 — Generate key_network + +The wallet generates an independent key_network of the same length using a CSPRNG: + +``` +12-mode → key_network = 156 bits +24-mode → key_network = 312 bits +``` + +Step 3 — Compute key_local + +``` +key_local = Final_Entropy XOR key_network +``` + +Step 4 — Encode into ASR-REC_Main + +key_local is encoded into the ASR-REC_Main structure. + +Result: + +ASR-REC_Main contains the necessary information to reconstruct key_local, but without key_network it is not sufficient to fully reconstruct Final_Entropy. + +9. Role of XOR in the key_network Architecture + +XOR is one of the main components of the key_network architecture in ASR. + +Enrollment Stage + +First, two independent values are generated: + +· Final_Entropy with CSPRNG +· key_network with CSPRNG + +Then: + +``` +key_local = Final_Entropy XOR key_network +``` + +key_local is then used to construct and encode ASR-REC. + +Recovery Stage + +After the network provides key_network to the wallet through the authorized process: + +``` +key_local = Decode(ASR-REC_Main) +``` + +and: + +``` +Final_Entropy = key_local XOR key_network +``` + +Important Note + +XOR itself is not ASR encryption. + +The role of XOR in this architecture is to create a reversible relationship between two independent shares: + +``` +Final_Entropy + ↓ +XOR key_network + ↓ +key_local +``` + +and: + +``` +key_local XOR key_network + ↓ +Final_Entropy +``` + +because: + +``` +A XOR K XOR K = A +``` + +Security implication: + +If key_network is not available to the attacker, even possessing key_local is not sufficient to reconstruct Final_Entropy. + +10. Role of SHA-256 + +SHA-256 is used in ASR to create one-way identifiers: + +``` +ASR-REC_Display + ↓ +SHA-256 + ↓ +ASR-REC_Display_ID +``` + +and: + +``` +ASR-VAR + ↓ +SHA-256 + ↓ +ASR-VAR_ID +``` + +The purpose of this transformation is to create a transferable and comparable identifier, without directly sending ASR-REC and ASR-VAR in the Recovery request. + +These identifiers are not secrets, and the main security of ASR does not depend on their secrecy. + +11. Secure Transfer of key_network + +After successful completion of Recovery and issuance of: + +``` +NRA + ASR_Version + key_network +``` + +key_network must be transferred securely to the wallet. + +Requirements: + +· key_network MUST NOT be transferred in plaintext over an insecure channel. +· The transfer MUST be through the same secure channel existing in the TRON infrastructure between the wallet and the network. +· ASR does not mandate a specific new transfer protocol at this level. +· Implementers MUST use the same secure communication infrastructure existing between the wallet and the TRON network. + +ASR uses the same existing security layer of TRON and does not define a new transfer protocol. + +12. Complete Process of Key Network Send and Save in Network — Enrollment + +The Enrollment process in ASR consists of the following steps: + +Step 1 — Generate Final_Entropy + +The wallet generates Final_Entropy using a CSPRNG: + +· 12-number mode: Final_Entropy = 156 bits +· 24-number mode: Final_Entropy = 312 bits + +Step 2 — Generate key_network + +The wallet generates an independent key_network of the same length using a CSPRNG: + +· 12-number mode: key_network = 156 bits +· 24-number mode: key_network = 312 bits + +Step 3 — Compute key_local + +``` +key_local = Final_Entropy XOR key_network +``` + +Step 4 — Encode into ASR-REC_Main + +key_local is encoded into the ASR-REC_Main structure. + +Step 5 — Select ASR-VAR + +The user selects ASR-VAR: + +· In 12-number mode: 12 uppercase English letters (A–Z) +· In 24-number mode: 24 uppercase English letters (A–Z) + +Step 6 — Execute ASR-CRC and Generate ASR-REC_Display + +The wallet executes ASR-CRC cycles and computes ASR-REC_Display based on ASR-VAR and ASR-REC_Main. + +Step 7 — Compute Identifiers + +The wallet computes: + +``` +ASR-REC_Display_ID = SHA-256(Canonical_ASR-REC_Display) +ASR-VAR_ID = SHA-256(Canonical_ASR-VAR) +``` + +Step 8 — Generate Nonce + +The wallet generates a unique Nonce for this Enrollment request. + +Step 9 — Sign Enrollment Message + +The wallet signs the Canonical Enrollment message with an authorized Access Key of the account: + +``` +ASR_Enrollment_Message = + Domain || ASR_Version || Account || Recovery_Mode || + ASR-REC_Display_ID || ASR-VAR_ID || key_network || Nonce +``` + +Step 10 — Send to Network + +The wallet sends the following information to the network through the secure channel existing in the TRON infrastructure: + +``` +{ + ASR_Version, + Account, + Recovery_Mode, + ASR-REC_Display_ID, + ASR-VAR_ID, + key_network, + Nonce, + Signing_Key_ID, + Signature +} +``` + +Step 11 — Network Validation + +The network checks the following: + +· Validity of the Access Key signature +· Belonging of the signature to the specified Account +· Validity of Signing_Key_ID +· Nonce not used (prevention of Replay) +· Validity of the structure of ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode +· Validity of the length and structure of key_network + +Step 12 — Storage + +After all checks succeed: + +· key_network is encrypted with an independent Storage Encryption Key (belonging to the infrastructure). +· The corresponding record is stored in Core Recovery Key Network Storage. + +Step 13 — Return NRA + +The network returns an NRA to the wallet, indicating successful storage. + +Step 14 — Wipe Temporary Sensitive Data + +The wallet erases temporary sensitive data such as Final_Entropy and the temporary copy of key_network from memory after successful completion of Enrollment. + +Step 15 — Display ASR-REC_Display to User + +The wallet displays ASR-REC_Display to the user and emphasizes that ASR-VAR MUST be kept separately. + +13. Complete Process of Key Network Receive and Recovery + +The recovery process in ASR includes a PoW layer to prevent widespread abuse and increase the cost of online attacks. + +Step 1 — Send Identifier + +The wallet sends ASR-REC_Display_ID and Recovery_Mode to the network's Recovery Service. + +Important security note: The network MUST NOT determine from this step whether ASR-REC_Display_ID or Recovery_Mode is valid or invalid. The network's behavior MUST be identical in both cases. + +Step 2 — Issue PoW Challenge + +The network issues a PoW_Challenge. + +Requirements: + +· PoW_Challenge MUST be bound to the Recovery Session. +· PoW Difficulty MUST be adjustable by the network. This adjustability is essential for adapting to network conditions, available computational power, and security policies over time. + +Conceptual structure of PoW_Input: + +``` +PoW_Input = + Domain || + ASR_Version || + ASR-REC_Display_ID || + Challenge || + Session_Nonce +``` + +This binding prevents reuse of a solved PoW_Solution in a different request. + +Step 3 — Send Response and Second Identifier + +The wallet solves the Challenge and computes PoW_Solution. +Then it sends the result along with ASR-VAR_ID to the network: + +``` +{ PoW_Solution, ASR-VAR_ID } +``` + +Note: ASR-REC_Display_ID and Recovery_Mode are not sent again; because they were sent in step 1 and the PoW_Challenge is bound to the same Recovery Session. The network knows the relevant information through the Session. + +Step 4 — Verification and Response + +The network retrieves all information related to this request through the Recovery Session. A Session is a temporary context created at the start of the request and includes ASR-REC_Display_ID, Recovery_Mode, and PoW_Challenge. + +The network checks the following in order: + +· Match of ASR-REC_Display_ID (through Session) +· Match of Recovery_Mode (through Session) +· Correctness of PoW_Solution +· Binding of PoW to Recovery Session +· Match of ASR-VAR_ID with Recovery Record +· Rate Limit status +· Other Recovery security policies + +If all items are valid, the network returns the following to the wallet: + +``` +{ NRA, ASR_Version, key_network } +``` + +If any item is invalid, the network returns only the following message to the wallet: + +``` +{ Recovery Error } +``` + +The error MUST NOT reveal any information about which step failed. + +Reason for ambiguous error: + +If the network announces, for example: +"ASR-REC_Display_ID is valid but ASR-VAR_ID is incorrect" + +the attacker can learn that they correctly guessed and computed ASR-REC_Display_ID, and focus their attack on other parts of recovery. + +Therefore, the Recovery Service MUST NOT reveal the failure step. + +The Recovery Service MUST NOT reveal which individual recovery component failed. + +Step 5 — Reconstruct Final_Entropy + +After successfully receiving a valid response from the network (including key_network, ASR_Version, and NRA), the wallet: + +1. First uses the ASR_Version received from the network to ensure that the ASR-CRC algorithm and reconstruction steps match the version used during Enrollment. +2. Then, using ASR-REC_Display and ASR-VAR, it first processes ASR-VAR again through ASR-CRC cycles and obtains the numeric output for each variable. +3. Then the wallet modularly subtracts the ASR-CRC output from the four-digit value of ASR-REC_Display. This operation is performed for all values, and as a result, the original ASR-REC_Main values that existed before the integration step are reconstructed. + +Conceptually: + +``` +ASR-REC_Main[i] = (ASR-REC_Display[i] − CRC_Output[i]) mod 8192 +``` + +The modular operation is performed in the range 0000–8191; therefore the result always lies in this range and no separate range check is needed. + +Therefore, ASR-REC_Display alone cannot be directly converted to ASR-REC_Main, and its reconstruction requires possessing ASR-VAR and correctly executing the ASR-CRC process. + +Note: In the current version of the ASR standard, all modular calculations are performed in the range 0000–8191 (13-bit space). Future versions of ASR may define different ranges. + +After the wallet reconstructs ASR-REC_Main: + +``` +key_local = Decode(ASR-REC_Main) +``` + +Then: + +``` +Final_Entropy = key_local XOR key_network +``` + +After successful computation of Final_Entropy, the Recovery process is complete. + +14. Rate Limiting + +To prevent adaptive online attacks, each Recovery request must be counted as a single attempt in the Rate Limiting policy. + +Regardless of which component of the Recovery request is incorrect, the result of that request, if failed, is considered a Failed Recovery Attempt. + +Therefore, the following are all considered a type of failure in the Rate Limiting policy: + +· Wrong REC + Correct VAR +· Wrong REC + Wrong VAR +· Correct REC + Wrong VAR +· Wrong REC + Changed VAR +· Invalid PoW +· Invalid REC ID +· Invalid VAR ID +· Invalid Recovery_Mode + +The purpose of this design is to prevent an attacker from creating a new counter by changing one of the identifiers or Recovery parameters and bypassing the previous restriction. + +Initial Policy + +``` +3 failed attempts → 24-hour restriction +next 3 failures → 48-hour restriction +next 3 failures → 96-hour restriction +next 3 failures → 192-hour restriction +... +``` + +That is, after every group of three consecutive failures, the last applied time restriction is doubled: + +``` +Lockout_Time = Previous_Lockout_Time × 2 +``` + +Changing Identifier and Bypassing Restriction + +Changing: + +· ASR-REC_Display_ID +· ASR-VAR_ID +· Recovery_Mode +· IP +· VPN +· Tor +· Device +· Wallet Version + +must not be able to bypass the main Rate Limiting policy. + +Account or Address is not the main basis for Rate Limit, because the user may not have the account address at the time of Recovery. + +Counting Failed Recovery Attempts and applying restrictions is done only after the complete completion of the process and the return of { Recovery Error }. This order ensures that the attacker cannot infer information about the Rate Limit status from the timing or behavior of the network's response. + +Important Principle + +Every failed Recovery Request, regardless of which component was incorrect, must be calculated within a unified Rate Limiting policy. + +Rate Limiting Policy in the ASR Architecture + +In the ASR architecture, each recovery request is counted as a single unit in the Rate Limiting policy. If any of the request components are invalid, including ASR-REC_Display_ID, PoW_Solution, ASR-VAR_ID, or Recovery_Mode, the validation result is not announced separately to the requester. + +Requirement for Complete Completion of Steps: + +The Recovery Service MUST complete all validation steps defined in the Recovery process to the end, regardless of which step it identified an invalid component. + +The Recovery Service MUST NOT stop the process midway in a way that is inferable to the requester. + +At the end of the process, regardless of which component was invalid, only one general message is returned: + +``` +{ Recovery Error } +``` + +Reason for this requirement: + +If the network stops midway and announces that "ASR-REC_Display_ID is valid but ASR-VAR_ID is invalid", the attacker can use this response to determine the validity of part of their input and narrow their search space to the remaining part. This makes the attack faster and more targeted. + +Therefore: + +Recovery Service MUST NOT reveal which individual recovery component failed. + +Prevention of Error Oracle: + +The Rate Limiting policy in the ASR architecture is designed such that even if an invalid component is identified in the early stages of Recovery, this detection must not create a response or behavior that is inferable by the attacker. + +The goal is to prevent the attacker from using differences in error messages, response order, or observable behavior of validation steps, early receipt of the Recovery Error message, or early termination of recovery before completing all steps from the network side, to gain information to limit their search space. + +Unified Recovery Failure Counter: + +All failed requests, regardless of whether the error is related to ASR-REC_Display_ID, PoW_Solution, ASR-VAR_ID, Recovery_Mode, or other security controls, are calculated within the same Rate Limiting policy and the same unified Recovery failure counter. + +Applying Rate Limit for Non-Existent Records + +The Recovery Service MUST apply the Rate Limiting policy even for ASR-REC_Display_IDs that have no record in Core Recovery Key Network Storage. + +Reason: If the network applies Rate Limit only for existing records, the attacker can infer from the difference in network behavior (e.g., the number of allowed attempts before lockout) whether a given ASR-REC_Display_ID belongs to an active record or not. + +Therefore: + +· Every Recovery request, regardless of whether the ASR-REC_Display_ID belongs to an existing or non-existing record, MUST be counted within the same unified Rate Limiting policy. +· The network's behavior MUST be identical in both cases (existing and non-existing record). +· This policy ensures prevention of Recovery Oracle through differences in Rate Limiting behavior. + +This is a point that is forgotten in many systems: + +· Most developers only think about existing records. +· But the attacker uses exactly the difference in behavior to discover information. +· This technique is known in security as "Timing Attack" or "Oracle Attack". + +Design Goals: + +This design simultaneously pursues two goals: + +· Preventing disclosure of the failed step or component of the Recovery process +· Preventing the use of differences in messages or behavior of validation steps to reduce and target the attacker's search space + +This policy is consistent with the principle of Minimum Disclosure and ensures that the Recovery Service does not provide additional information about the record status, validity of input components, or the failure step of the process to the requester. + +Security Principle: + +The Recovery Service MUST NOT reveal which individual recovery component failed. + +15. ASR Security Principle + +Neither of the two components ASR-REC_Display and ASR-VAR alone is sufficient to fully reconstruct ASR-REC_Main and Final_Entropy. + +``` +ASR-REC_Display + ASR-VAR + ↓ + ASR-CRC Processing + ↓ + ASR-REC_Main + ↓ + key_local +``` + +``` +key_local + key_network + ↓ + Final_Entropy +``` + +And key_network is an independent secret protected in Core Recovery Key Network Storage. + +Conceptual Process + +``` +ASR-REC_Display + ASR-VAR + ↓ + ASR-CRC Processing + ↓ + ASR-REC_Main + ↓ + key_local +``` + +whereas: + +``` +ASR-REC_Display + ↓ + SHA-256 + ↓ +ASR-REC_Display_ID +``` + +and: + +``` +ASR-VAR + ↓ + SHA-256 + ↓ +ASR-VAR_ID +``` + +Overall Process Diagram + +``` + ┌──────────────────────────────┐ + │ ASR-REC_Display + ASR-VAR │ + └──────────────┬───────────────┘ + ↓ + ASR-CRC Processing + ↓ + ASR-REC_Main + ↓ + key_local + │ + │ (local — not sent to network) + │ + ┌───────────────────────┘ + │ + │ +ASR-REC_Display + ↓ + SHA-256 + ↓ +ASR-REC_Display_ID + │ + │ +ASR-VAR + ↓ + SHA-256 + ↓ +ASR-VAR_ID + │ + └──────────────┐ + ↓ + Recovery IDs + (ASR-REC_Display_ID + ASR-VAR_ID) + ↓ + Recovery Service + ↓ + PoW + Rate Limit + Validation + ↓ + NRA + Protected key_network + ↓ + (return to Wallet) + ↓ + key_local XOR key_network + ↓ + Final_Entropy +``` + +Important Note + +ASR does not say that key_network prevents guessing ASR-VAR. + +The attacker may be able to guess ASR-VAR. + +But if the attacker has only one of the two components ASR-REC_Display or ASR-VAR correct, that component alone is not sufficient to complete the account Recovery process; because to obtain ASR-REC_Main, we need both ASR-REC_Display and ASR-VAR and correct execution of ASR-CRC cycles. +Also, to obtain key_local, ASR-REC_Main must first be reconstructed. +And to obtain Final_Entropy, in addition to key_local, obtaining key_network from the network's Recovery infrastructure is also necessary; provided that the required information, including ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode, is sent according to the defined process and the request passes the network security controls, including PoW, Rate Limit, and other validation policies. + +16. What is Recovery_Mode? + +Recovery_Mode is a simple field that specifies which recovery mode the user has chosen: + +· 12 → ASR-REC mode with twelve four-digit numbers +· 24 → ASR-REC mode with twenty-four four-digit numbers + +Role of Recovery_Mode + +1. Enrollment: + +At the time of creating and registering ASR, the user chooses one of the 12 or 24 modes. The backup steps continue based on this choice. + +During Enrollment, the wallet sends the Recovery_Mode value to the network in addition to the described values. This value is stored in Core Recovery Key Network Storage and is used during Recovery for request validation and enforcement of the Rate Limiting policy. + +2. Recovery: + +At the beginning of the Recovery process, the wallet sends ASR-REC_Display_ID along with Recovery_Mode to the Recovery Service. + +The network recovery service receives and checks the submitted Recovery_Mode as one of the parameters under the Rate Limiting policy and matches it with the Recovery_Mode stored in the record. A mismatch of Recovery_Mode is considered a Failed Recovery Attempt and is recorded in the same unified Rate Limiting counter. + +Practical Note: The real user knows whether they wrote down 12 numbers or 24 numbers. But the attacker does not have this information, and this mismatch acts as one of the criteria for Rate Limiting. + +Notes + +· ASR-REC_Display_ID and ASR-VAR_ID do not inherently encode Recovery_Mode in their SHA-256 value. +· Recovery_Mode is an explicit and independent parameter used in the Recovery process for request validation and enforcement of Rate Limiting. + +Ambiguous Error + +If Recovery_Mode is invalid or does not match the corresponding record, the Recovery Service must not stop the validation steps midway or reveal the exact reason for failure. In this case, the network returns only the following general message: + +``` +{ Recovery Error } +``` + +The error MUST NOT reveal any information about which step or component failed. + +Relationship of Recovery_Mode with Rate Limiting + +Recovery_Mode is one of the parameters under the Rate Limiting policy in the Recovery process. + +For the 12 and 24 modes, no separate counter or quota is created. All failed Recovery requests, regardless of whether their Recovery_Mode is 12 or 24, are placed under a single counter for each Recovery Request. + +Therefore, changing Recovery_Mode from 12 to 24 or vice versa should not create a new quota, new counter, or bypass Recovery restrictions. + +Also, even if there is no valid record for the provided ASR-REC_Display_ID, the request MUST still be subject to the Rate Limiting policy so that the absence of a record cannot be used as a way to bypass the request rate limit. + +According to the Rate Limiting policy in ASR, if Recovery_Mode, ASR-REC_Display_ID, or ASR-VAR_ID is invalid, the validation process MUST continue to the end according to the Anti-Oracle policy, and the network returns only the following message: + +``` +{ Recovery Error } +``` + +17. Numerical Comparison of Entropy Capacity of BIP-39 and ASR and Its Relation to NIST Reference Security Levels + +First, precise definition of NIST security levels + +NIST has defined five reference security levels for evaluating the resistance of cryptographic systems against attacks. These levels are defined based on comparing the computational cost of attacks with reference operations in symmetric algorithms, including AES and SHA hash functions. + +· Level 1: Difficulty equivalent to key search of a block cipher with a 128-bit key, such as AES-128. +· Level 2: Difficulty equivalent to collision search in a 256-bit hash function, such as SHA-256. +· Level 3: Difficulty equivalent to key search of a block cipher with a 192-bit key, such as AES-192. +· Level 4: Difficulty equivalent to collision search in a 384-bit hash function, such as SHA-384. +· Level 5: Difficulty equivalent to key search of a block cipher with a 256-bit key, such as AES-256. + +In this classification, levels 1, 3, and 5 are respectively associated with 128, 192, and 256 bits of classical security. Levels 2 and 4 are respectively related to the collision resistance of SHA-256 and SHA-384, which NIST places in the reference categories of 128 and 192 bits, respectively. + +Therefore, level 1 and level 2 both fall within the 128-bit reference range, but the type of computational problem is different: + +· Level 1 relates to Key Search. +· Level 2 relates to Collision Search in a hash function. + +Also, NIST specifies that security levels 2 and 4 require precise quantum security analysis, and merely having a certain number of entropy bits is not sufficient to attribute a system to these levels. NIST defines these categories in order of increasing reference security strength, but the type of problem and attack model are fundamental in determining the level. + +Numerical Comparison of Entropy Capacity + +BIP-39 with 12 words of 11 bits and number range 0000 to 2047, totaling 2048 states + +· Total space: 2^132 +· Checksum: 4 bits +· Initial entropy: 128 bits +· Numerical comparison with NIST: on par with the 128-bit reference threshold of level 1 in terms of entropy capacity + +BIP-39 with 24 words of 11 bits and number range 0000 to 2047, totaling 2048 states + +· Total space: 2^264 +· Checksum: 8 bits +· Initial entropy: 256 bits +· Numerical comparison with NIST: on par with the 256-bit reference threshold of level 5 in terms of entropy capacity + +ASR-REC with 12 four-digit 13-bit numbers and number range 0000 to 8191, totaling 8192 states + +· Total space: 2^156 +· Checksum: none +· Nominal entropy: 156 bits, assuming uniform and independent generation of values +· Numerical comparison with NIST: above the 128-bit threshold and below the 192-bit threshold + +ASR-REC with 24 four-digit 13-bit numbers and number range 0000 to 8191, totaling 8192 states + +· Total space: 2^312 +· Checksum: none +· Nominal entropy: 312 bits, assuming uniform and independent generation of values +· Numerical comparison with NIST: above the 256-bit threshold + +In ASR, removing Checksum ensures that no part of the 13-bit capacity of each unit is allocated to a control value; therefore, assuming uniform and independent generation of values, all this capacity can be calculated as nominal entropy capacity. + +However, these numbers represent the capacity of the entropy space and by themselves are not equivalent to an official NIST Security Level. + +Therefore, in the ideal Grover search model, the 312-bit space reduces to approximately 2^156 oracle evaluations. + +This comparison does not mean an official grant of a Security Level from NIST to BIP-39 or ASR. NIST security levels are defined based on the type of cryptographic problem, attack model, computational cost, and security analysis; therefore, the number of entropy bits alone is not sufficient to determine a Security Level. NIST specifically emphasizes the need for precise quantum security analysis for levels 2 and 4. + +ASR Resistance to Birthday Attack + +The birthday attack is primarily used to find collisions in hash functions. For a hash function with n-bit output, the theoretical complexity of a general collision attack is approximately of order 2^(n/2). For example, NIST places the collision resistance of SHA-256 and SHA-384 in the reference categories of 128 and 192 bits, respectively. + +This relationship cannot be directly generalized to the entropy space of ASR-REC, because ASR-REC cannot be considered as a hash function, and the attacker's goal in the ASR recovery process is not to find a collision in a hash function; rather, the goal is to reconstruct Final_Entropy and ultimately complete the recovery process and obtain the account keys. + +In the ASR architecture, even if the attacker possesses one of the values ASR-REC_Display or ASR-VAR, they cannot examine the corresponding possible space alone. This process is only possible by possessing both ASR-REC_Display and ASR-VAR, completing the ASR-CRC cycles, and sending ASR-REC_Display_ID and ASR-VAR_ID along with other required variables, and obtaining key_network from the network recovery infrastructure. + +Reconstruction of Final_Entropy without access to key_network in the ASR architecture is not possible; because: + +``` +Final_Entropy = key_local XOR key_network +``` + +key_network is an independent network share that is protected after Enrollment in Core Recovery Key Network Storage and is provided to the wallet only after the successful completion of the Recovery process, including PoW, identifier validation, and Rate Limiting policies. + +Therefore, ASR security against offline attacks is not solely dependent on the size of the ASR-REC space, and the network architecture also adds an independent layer to the recovery process. + +Additionally, the progressive Rate Limiting policy and the network's uniform behavior in responding to failed requests limit the ability to perform a very large number of attempts in a short time. + +Therefore, the Birthday Attack is not a direct criterion for evaluating ASR-REC security. ASR resistance to widespread recovery attacks should be evaluated based on the entire recovery path, including entropy space, key_network, network validation, Rate Limiting, and other architectural controls. + +Why Offline Recovery Is Not Possible in ASR + +In the ASR architecture, the recovery process is designed such that ASR-REC_Display and ASR-VAR are two independent and complementary components. Possessing only one of these two components is not sufficient to reconstruct ASR-REC_Main. + +If the attacker has only ASR-REC_Display, without ASR-VAR they cannot execute ASR-CRC cycles to process ASR-REC_Display values and obtain ASR-REC_Main. + +On the other hand, if the attacker has only ASR-VAR, they do not have ASR-REC_Display and therefore cannot complete the conversion and reconstruction process of ASR-REC_Main. + +Therefore, reconstruction of key_local requires possessing both components. The attacker must first possess both ASR-REC_Display and ASR-VAR, then execute ASR-CRC cycles to reach ASR-REC_Main, and finally decode it to reconstruct key_local. + +Even after reconstructing key_local, the attacker needs key_network to reach Final_Entropy: + +``` +Final_Entropy = key_local XOR key_network +``` + +key_network is independently maintained in the Recovery infrastructure and is not derived from ASR-REC_Display, ASR-VAR, their identifiers, Account, blockchain state, public parameters, or wallet code. + +Therefore, complete offline recovery with only part of the ASR data is not possible. To complete the reconstruction, the attacker must, in addition to possessing both ASR-REC_Display and ASR-VAR, also access the network Recovery path to obtain key_network. + +Two Independent Boundaries of the ASR Architecture + +The ASR architecture has two independent boundaries: + +1. Local boundary: Requires simultaneous possession of ASR-REC_Display and ASR-VAR to reconstruct ASR-REC_Main and key_local. +2. Network boundary: Requires successful access to key_network to reconstruct Final_Entropy. + +Result of this separation: + +· Disclosure of either of the two local components (ASR-REC_Display or ASR-VAR) alone does not lead to disclosure of the entire recovery secret. +· Even simultaneous disclosure of both local components, without access to key_network, is not sufficient to reconstruct Final_Entropy. +· ASR-REC or ASR-VAR alone are not a complete recovery key. +· Local ASR information alone is not sufficient to reconstruct Final_Entropy. ___ ___ # Additional Engineering Considerations and Security Constraints From 34dbb5a9499cd54038ed8c8c9fce93df7c542fa1 Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 9 Oct 2026 20:35:30 +0330 Subject: [PATCH 13/20] Update tip-asr.md --- tip-asr.md | 355 ++++++++++++++++++++++++++--------------------------- 1 file changed, 177 insertions(+), 178 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 02d4ff4..6bbc780 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -202,22 +202,21 @@ ___ ___ # Network-Dependent Account Recovery in ASR: Architectural Constraints and the Impossibility of Offline Recovery - In the ASR standard, the impossibility of offline recovery is not a flaw or implementation limitation, but a design feature. Unlike common standards such as BIP-39, where the entire recovery process is offline and solely dependent on recovery words, ASR, in addition to offline dependence on two values ASR-VAR and ASR-REC_Display, is fundamentally based on receiving data from the network. The reason for network dependence is the separation of Final_Entropy into two independent shares: -· First, the local share (key_local): which is reconstructed from the user's recovery data and the ASR-REC_Main structure. -· Second, key_network is generated by the wallet and sent to the network. The network stores the key_network sent by the wallet in Core Recovery Key Network Storage and returns a successful storage confirmation message to the wallet. +- First, the local share (key_local): which is reconstructed from the user's recovery data and the ASR-REC_Main structure. +- Second, key_network is generated by the wallet and sent to the network. The network stores the key_network sent by the wallet in Core Recovery Key Network Storage and returns a successful storage confirmation message to the wallet. During the Enrollment phase, the wallet temporarily generates key_network and keeps it in memory to send it in the Enrollment message and receive its successful registration from the network. After successful completion of Enrollment and receiving the confirmation message, the temporary copy of key_network MUST be erased from the wallet's memory, and the wallet MUST NOT store, retain, display, or provide it to the user. Because: -· key_network is a recovery key belonging to the network, not a user key. -· The user's responsibility is limited to safeguarding and maintaining ASR-REC_Display and ASR-VAR. -· Displaying key_network to the user increases the risk of leakage through user error (screenshots, notes, insecure storage). -· This violates the architectural separation between user data and network data. +- key_network is a recovery key belonging to the network, not a user key. +- The user's responsibility is limited to safeguarding and maintaining ASR-REC_Display and ASR-VAR. +- Displaying key_network to the user increases the risk of leakage through user error (screenshots, notes, insecure storage). +- This violates the architectural separation between user data and network data. Reconstruction of Final_Entropy is only possible through the XOR combination of these two shares: @@ -235,7 +234,7 @@ Furthermore, disclosure of one of the two components ASR-REC_Display or ASR-VAR Supplementary explanations on structure and mechanism -1. Dual-Mode Display Structure of ASR for the User +### 1. Dual-Mode Display Structure of ASR for the User The recovery standard in ASR has two modes: 12-number and 24-number, and backup is performed based on one of these two modes, chosen by the user. @@ -243,8 +242,8 @@ When starting the backup process, the wallet presents both modes to the user so 12-number mode -· ASR-REC = 12 four-digit numbers with 13-bit capacity and original number range: 0000 to 8191, totaling 8192 states -· ASR-VAR = 12 uppercase English letters with range A to Z +- ASR-REC = 12 four-digit numbers with 13-bit capacity and original number range: 0000 to 8191, totaling 8192 states +- ASR-VAR = 12 uppercase English letters with range A to Z ``` 12 × 13 = 156 bits @@ -253,8 +252,8 @@ Nominal entropy = 156 bits 24-number mode -· ASR-REC = 24 four-digit numbers with 13-bit capacity and original number range: 0000 to 8191, totaling 8192 states -· ASR-VAR = 24 uppercase English letters with range A to Z +- ASR-REC = 24 four-digit numbers with 13-bit capacity and original number range: 0000 to 8191, totaling 8192 states +- ASR-VAR = 24 uppercase English letters with range A to Z ``` 24 × 13 = 312 bits @@ -265,7 +264,7 @@ The 24-number mode provides a much higher security margin and greater theoretica The choice between these two modes (12-number and 24-number, with 13-bit four-digit numbers) MUST be made by the user when starting the recovery process. The wallet cannot display the 12-number mode by default or impose it on the user in any way; rather, wallets MUST display both the 12 and 24-number modes to the user in the first step of backup, so the user can choose one and continue the backup steps based on their choice. -2. Removal of Checksum from the ASR Architecture +### 2. Removal of Checksum from the ASR Architecture The ASR standard does not use a Checksum in its core structure. @@ -309,13 +308,13 @@ ASR-compliant wallets MUST check this limitation before continuing the Recovery Therefore, the wallet must not accept inputs such as the following as valid ASR-VAR: -· a-z (lowercase letters) -· 0-9 (digits) -· Persian characters -· Arabic characters -· symbols -· spaces -· other Unicode characters +- a-z (lowercase letters) +- 0-9 (digits) +- Persian characters +- Arabic characters +- symbols +- spaces +- other Unicode characters Since wallets are required to check and validate the type and format of characters entered by the user according to the ASR standard, this largely covers the need for a Checksum to detect user input errors. @@ -327,12 +326,12 @@ Each ASR-REC value consists of 12 four-digit 13-bit numbers in the range 0000 to ASR-compliant wallets MUST check the following: -· The number of values is correct; -· Each value has exactly four digits; -· Values are in the range 0000–8191; -· The overall structure of ASR-REC matches the selected mode; -· Values outside the rules defined by the protocol are rejected. -· Entry and display of numbers use English characters. +- The number of values is correct; +- Each value has exactly four digits; +- Values are in the range 0000–8191; +- The overall structure of ASR-REC matches the selected mode; +- Values outside the rules defined by the protocol are rejected. +- Entry and display of numbers use English characters. Therefore, a Checksum is not necessary for detecting structural and format errors in ASR-REC either. @@ -379,15 +378,15 @@ On the contrary, ASR performs validation at the level of format, length, range, For this reason, ASR lacks a Checksum in both ASR-REC_Main and ASR-VAR, and input validation is performed through explicit standard rules and their mandatory implementation in compliant wallets. -3. Relationship between ASR-REC and ASR-VAR Variables +### 3. Relationship between ASR-REC and ASR-VAR Variables In the twelve-number ASR-REC mode: -· ASR-VAR consists of 12 English letter variables (uppercase A to Z). +- ASR-VAR consists of 12 English letter variables (uppercase A to Z). In the twenty-four-number ASR-REC mode: -· ASR-VAR consists of 24 English letter variables (uppercase A to Z). +- ASR-VAR consists of 24 English letter variables (uppercase A to Z). Each character of ASR-VAR, after conversion to a numeric value and passing through the ASR-CRC cycle, produces a four-digit output. This four-digit output is modularly combined with the corresponding value in ASR-REC, and the final result is displayed to the user as ASR-REC_Display. @@ -405,7 +404,7 @@ and: Corresponding to the increase in numeric variables of ASR-REC from 12 four-digit numbers to 24 four-digit numbers, the letter variables of ASR-VAR also increase from 12 letter variables to 24 letter variables. This increase is necessary and essential to preserve the structure, execution steps, and operation of ASR-CRC cycles, without changing the ASR architectural logic. -4. One-Way Recovery Identifiers +### 4. One-Way Recovery Identifiers To prevent direct transmission of ASR-REC_Display and ASR-VAR to the network, ASR uses two one-way identifiers: @@ -441,7 +440,7 @@ key_network is an essential component for reconstructing Final_Entropy and is ex Any attempt to bypass the network, without possessing both ASR-REC_Display and ASR-VAR variables, is strictly limited by the Rate Limiting policy. -5. NRA — Network Recovery Authorization +### 5. NRA — Network Recovery Authorization NRA (Network Recovery Authorization) means network recovery authorization. @@ -451,13 +450,13 @@ First — Enrollment Stage During Enrollment, the wallet sends the information required for account recovery — including the following — along with a signature from the account's Access Key to the network: -· ASR_Version -· ASR-REC_Display_ID -· ASR-VAR_ID -· key_network -· Recovery_Mode -· Nonce -· Enrollment_Signature +- ASR_Version +- ASR-REC_Display_ID +- ASR-VAR_ID +- key_network +- Recovery_Mode +- Nonce +- Enrollment_Signature After successful validation of the Access Key signature by network nodes and verification of other Recovery parameters, the information is recorded and stored in Core Recovery Key Network Storage. Then the network returns an NRA to the wallet. @@ -471,33 +470,33 @@ Steps for the wallet to obtain Recovery information from the network In the Recovery process, the wallet first: -· Sends ASR-REC_Display_ID and Recovery_Mode to the network. +- Sends ASR-REC_Display_ID and Recovery_Mode to the network. Then the network issues a PoW_Challenge. After solving the PoW, the wallet sends the following to the network: -· PoW_Solution -· ASR-VAR_ID +- PoW_Solution +- ASR-VAR_ID After performing the necessary checks, including: -· Validation of ASR-REC_Display_ID and matching it with the Recovery record -· Validation of Recovery_Mode and matching it with the Recovery record -· Validity and correctness of PoW -· Validity of ASR-VAR_ID -· Recording necessary values for applying Rate Limit -· Other security policies +- Validation of ASR-REC_Display_ID and matching it with the Recovery record +- Validation of Recovery_Mode and matching it with the Recovery record +- Validity and correctness of PoW +- Validity of ASR-VAR_ID +- Recording necessary values for applying Rate Limit +- Other security policies If the submitted information is correct and valid and successful, it returns the following to the wallet: -· NRA -· ASR_Version -· key_network +- NRA +- ASR_Version +- key_network The wallet then reconstructs Final_Entropy using key_local and key_network and completes the account recovery. -6. Core Recovery Key Network Storage +### 6. Core Recovery Key Network Storage key_network is stored in a protected repository called: @@ -530,14 +529,14 @@ Core Recovery Key Network Storage Field Descriptions -· ASR-REC_Display_ID = SHA-256(Canonical_ASR-REC_Display) -· ASR-VAR_ID = SHA-256(Canonical_ASR-VAR) -· ASR_Version specifies the ASR standard version used to create and recover this record. -· Recovery_Mode specifies whether the record corresponds to the 12 or 24-number mode. -· The index (ASR-REC_Display_ID, ASR-VAR_ID) allows the Recovery Service to find the corresponding record. -· Enrollment_Signature is the digital signature of the entire Canonical Enrollment message, not just the key_network signature. -· Signing_Key_ID is the identifier of the signing key. -· Nonce is the unique value of the Enrollment request to prevent Replay. +- ASR-REC_Display_ID = SHA-256(Canonical_ASR-REC_Display) +- ASR-VAR_ID = SHA-256(Canonical_ASR-VAR) +- ASR_Version specifies the ASR standard version used to create and recover this record. +- Recovery_Mode specifies whether the record corresponds to the 12 or 24-number mode. +- The index (ASR-REC_Display_ID, ASR-VAR_ID) allows the Recovery Service to find the corresponding record. +- Enrollment_Signature is the digital signature of the entire Canonical Enrollment message, not just the key_network signature. +- Signing_Key_ID is the identifier of the signing key. +- Nonce is the unique value of the Enrollment request to prevent Replay. Protection of key_network @@ -561,20 +560,20 @@ During Recovery, the wallet first receives the information needed to obtain key_ If the network confirms the information: -· The Recovery Service finds the corresponding record. -· The Recovery Service decrypts key_network in the secure infrastructure environment using the Storage encryption key. +- The Recovery Service finds the corresponding record. +- The Recovery Service decrypts key_network in the secure infrastructure environment using the Storage encryption key. After that, the network returns the following to the wallet through a secure and authenticated internal communication channel: -· NRA -· ASR_Version -· key_network +- NRA +- ASR_Version +- key_network The wallet reconstructs Final_Entropy using key_local and key_network and completes the Recovery process. This architecture makes key_network independent of the device, previous wallet installation, or wallet storage location. Therefore, if the wallet is deleted, the device is changed, or a new wallet is installed, upon successful authentication of the Recovery process, the new wallet can obtain key_network from the network's Recovery infrastructure and continue the recovery process. -7. Requirement for Access Keys Signature to Prevent Replay and Fake key_network Registration in Enrollment +### 7. Requirement for Access Keys Signature to Prevent Replay and Fake key_network Registration in Enrollment To prevent fake key_network registration and Replay attacks, every Enrollment request MUST be sent to the recovery infrastructure with a valid signature by the account's Access Keys and a unique Nonce. @@ -605,22 +604,22 @@ Enrollment Request Structure Recovery Service Checks Before Storage -· Validity of the signature on the Canonical message -· Belonging of the signing key to the Account -· The signature was produced by a valid Access Key. -· The Nonce has not been used before -· Validation of the structure of ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode -· Validation of the length and structure of key_network -· Store key_network only after all checks succeed -· Return NRA to the wallet, indicating successful registration of key_network in the network recovery infrastructure +- Validity of the signature on the Canonical message +- Belonging of the signing key to the Account +- The signature was produced by a valid Access Key. +- The Nonce has not been used before +- Validation of the structure of ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode +- Validation of the length and structure of key_network +- Store key_network only after all checks succeed +- Return NRA to the wallet, indicating successful registration of key_network in the network recovery infrastructure Therefore, the following must be observed: -· Core Recovery Key Network Storage MUST NOT store any key_network unless the corresponding Enrollment request has been authenticated with a valid signature from an authorized Access Key. -· Every Enrollment request MUST include a unique Nonce. -· The Recovery Service MUST maintain a record of used Nonces with a specified expiry window. Suggested default: 24 hours. -· Any request containing a duplicate Nonce MUST be rejected. -· key_network MUST be encrypted at rest. +- Core Recovery Key Network Storage MUST NOT store any key_network unless the corresponding Enrollment request has been authenticated with a valid signature from an authorized Access Key. +- Every Enrollment request MUST include a unique Nonce. +- The Recovery Service MUST maintain a record of used Nonces with a specified expiry window. Suggested default: 24 hours. +- Any request containing a duplicate Nonce MUST be rejected. +- key_network MUST be encrypted at rest. Necessity of Digital Signature in Enrollment @@ -632,9 +631,9 @@ This attack can appear as a destructive attack or Denial of Service against the Therefore, the Enrollment signature ensures that: -· Recovery registration must be approved by an authorized Access Key of the account. -· An attacker without access to an authorized Access Key cannot create a valid Enrollment record. -· The integrity of Core Recovery Key Network Storage data is better preserved. +- Recovery registration must be approved by an authorized Access Key of the account. +- An attacker without access to an authorized Access Key cannot create a valid Enrollment record. +- The integrity of Core Recovery Key Network Storage data is better preserved. Enrollment MUST be possible with any valid and authorized Access Key. @@ -666,13 +665,13 @@ ASR does not use this design. Instead: -· The Access Key is used in Enrollment for signing and authorization. -· key_network in Storage is protected by an independent Storage Encryption Key. -· Recovery, after meeting the necessary conditions, receives key_network from the Recovery infrastructure. +- The Access Key is used in Enrollment for signing and authorization. +- key_network in Storage is protected by an independent Storage Encryption Key. +- Recovery, after meeting the necessary conditions, receives key_network from the Recovery infrastructure. Therefore, Signature and Storage Encryption have independent roles. -8. Generation of key_network +### 8. Generation of key_network Step 1 — Generate Final_Entropy @@ -708,7 +707,7 @@ Result: ASR-REC_Main contains the necessary information to reconstruct key_local, but without key_network it is not sufficient to fully reconstruct Final_Entropy. -9. Role of XOR in the key_network Architecture +### 9. Role of XOR in the key_network Architecture XOR is one of the main components of the key_network architecture in ASR. @@ -716,8 +715,8 @@ Enrollment Stage First, two independent values are generated: -· Final_Entropy with CSPRNG -· key_network with CSPRNG +- Final_Entropy with CSPRNG +- key_network with CSPRNG Then: @@ -773,7 +772,7 @@ Security implication: If key_network is not available to the attacker, even possessing key_local is not sufficient to reconstruct Final_Entropy. -10. Role of SHA-256 +### 10. Role of SHA-256 SHA-256 is used in ASR to create one-way identifiers: @@ -799,7 +798,7 @@ The purpose of this transformation is to create a transferable and comparable id These identifiers are not secrets, and the main security of ASR does not depend on their secrecy. -11. Secure Transfer of key_network +### 11. Secure Transfer of key_network After successful completion of Recovery and issuance of: @@ -811,14 +810,14 @@ key_network must be transferred securely to the wallet. Requirements: -· key_network MUST NOT be transferred in plaintext over an insecure channel. -· The transfer MUST be through the same secure channel existing in the TRON infrastructure between the wallet and the network. -· ASR does not mandate a specific new transfer protocol at this level. -· Implementers MUST use the same secure communication infrastructure existing between the wallet and the TRON network. +- key_network MUST NOT be transferred in plaintext over an insecure channel. +- The transfer MUST be through the same secure channel existing in the TRON infrastructure between the wallet and the network. +- ASR does not mandate a specific new transfer protocol at this level. +- Implementers MUST use the same secure communication infrastructure existing between the wallet and the TRON network. ASR uses the same existing security layer of TRON and does not define a new transfer protocol. -12. Complete Process of Key Network Send and Save in Network — Enrollment +### 12. Complete Process of Key Network Send and Save in Network — Enrollment The Enrollment process in ASR consists of the following steps: @@ -826,15 +825,15 @@ Step 1 — Generate Final_Entropy The wallet generates Final_Entropy using a CSPRNG: -· 12-number mode: Final_Entropy = 156 bits -· 24-number mode: Final_Entropy = 312 bits +- 12-number mode: Final_Entropy = 156 bits +- 24-number mode: Final_Entropy = 312 bits Step 2 — Generate key_network The wallet generates an independent key_network of the same length using a CSPRNG: -· 12-number mode: key_network = 156 bits -· 24-number mode: key_network = 312 bits +- 12-number mode: key_network = 156 bits +- 24-number mode: key_network = 312 bits Step 3 — Compute key_local @@ -850,8 +849,8 @@ Step 5 — Select ASR-VAR The user selects ASR-VAR: -· In 12-number mode: 12 uppercase English letters (A–Z) -· In 24-number mode: 24 uppercase English letters (A–Z) +- In 12-number mode: 12 uppercase English letters (A–Z) +- In 24-number mode: 24 uppercase English letters (A–Z) Step 6 — Execute ASR-CRC and Generate ASR-REC_Display @@ -902,19 +901,19 @@ Step 11 — Network Validation The network checks the following: -· Validity of the Access Key signature -· Belonging of the signature to the specified Account -· Validity of Signing_Key_ID -· Nonce not used (prevention of Replay) -· Validity of the structure of ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode -· Validity of the length and structure of key_network +- Validity of the Access Key signature +- Belonging of the signature to the specified Account +- Validity of Signing_Key_ID +- Nonce not used (prevention of Replay) +- Validity of the structure of ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode +- Validity of the length and structure of key_network Step 12 — Storage After all checks succeed: -· key_network is encrypted with an independent Storage Encryption Key (belonging to the infrastructure). -· The corresponding record is stored in Core Recovery Key Network Storage. +- key_network is encrypted with an independent Storage Encryption Key (belonging to the infrastructure). +- The corresponding record is stored in Core Recovery Key Network Storage. Step 13 — Return NRA @@ -928,7 +927,7 @@ Step 15 — Display ASR-REC_Display to User The wallet displays ASR-REC_Display to the user and emphasizes that ASR-VAR MUST be kept separately. -13. Complete Process of Key Network Receive and Recovery +### 13. Complete Process of Key Network Receive and Recovery The recovery process in ASR includes a PoW layer to prevent widespread abuse and increase the cost of online attacks. @@ -944,8 +943,8 @@ The network issues a PoW_Challenge. Requirements: -· PoW_Challenge MUST be bound to the Recovery Session. -· PoW Difficulty MUST be adjustable by the network. This adjustability is essential for adapting to network conditions, available computational power, and security policies over time. +- PoW_Challenge MUST be bound to the Recovery Session. +- PoW Difficulty MUST be adjustable by the network. This adjustability is essential for adapting to network conditions, available computational power, and security policies over time. Conceptual structure of PoW_Input: @@ -977,13 +976,13 @@ The network retrieves all information related to this request through the Recove The network checks the following in order: -· Match of ASR-REC_Display_ID (through Session) -· Match of Recovery_Mode (through Session) -· Correctness of PoW_Solution -· Binding of PoW to Recovery Session -· Match of ASR-VAR_ID with Recovery Record -· Rate Limit status -· Other Recovery security policies +- Match of ASR-REC_Display_ID (through Session) +- Match of Recovery_Mode (through Session) +- Correctness of PoW_Solution +- Binding of PoW to Recovery Session +- Match of ASR-VAR_ID with Recovery Record +- Rate Limit status +- Other Recovery security policies If all items are valid, the network returns the following to the wallet: @@ -1044,7 +1043,7 @@ Final_Entropy = key_local XOR key_network After successful computation of Final_Entropy, the Recovery process is complete. -14. Rate Limiting +### 14. Rate Limiting To prevent adaptive online attacks, each Recovery request must be counted as a single attempt in the Rate Limiting policy. @@ -1052,14 +1051,14 @@ Regardless of which component of the Recovery request is incorrect, the result o Therefore, the following are all considered a type of failure in the Rate Limiting policy: -· Wrong REC + Correct VAR -· Wrong REC + Wrong VAR -· Correct REC + Wrong VAR -· Wrong REC + Changed VAR -· Invalid PoW -· Invalid REC ID -· Invalid VAR ID -· Invalid Recovery_Mode +- Wrong REC + Correct VAR +- Wrong REC + Wrong VAR +- Correct REC + Wrong VAR +- Wrong REC + Changed VAR +- Invalid PoW +- Invalid REC ID +- Invalid VAR ID +- Invalid Recovery_Mode The purpose of this design is to prevent an attacker from creating a new counter by changing one of the identifiers or Recovery parameters and bypassing the previous restriction. @@ -1083,14 +1082,14 @@ Changing Identifier and Bypassing Restriction Changing: -· ASR-REC_Display_ID -· ASR-VAR_ID -· Recovery_Mode -· IP -· VPN -· Tor -· Device -· Wallet Version +- ASR-REC_Display_ID +- ASR-VAR_ID +- Recovery_Mode +- IP +- VPN +- Tor +- Device +- Wallet Version must not be able to bypass the main Rate Limiting policy. @@ -1144,22 +1143,22 @@ Reason: If the network applies Rate Limit only for existing records, the attacke Therefore: -· Every Recovery request, regardless of whether the ASR-REC_Display_ID belongs to an existing or non-existing record, MUST be counted within the same unified Rate Limiting policy. -· The network's behavior MUST be identical in both cases (existing and non-existing record). -· This policy ensures prevention of Recovery Oracle through differences in Rate Limiting behavior. +- Every Recovery request, regardless of whether the ASR-REC_Display_ID belongs to an existing or non-existing record, MUST be counted within the same unified Rate Limiting policy. +- The network's behavior MUST be identical in both cases (existing and non-existing record). +- This policy ensures prevention of Recovery Oracle through differences in Rate Limiting behavior. This is a point that is forgotten in many systems: -· Most developers only think about existing records. -· But the attacker uses exactly the difference in behavior to discover information. -· This technique is known in security as "Timing Attack" or "Oracle Attack". +- Most developers only think about existing records. +- But the attacker uses exactly the difference in behavior to discover information. +- This technique is known in security as "Timing Attack" or "Oracle Attack". Design Goals: This design simultaneously pursues two goals: -· Preventing disclosure of the failed step or component of the Recovery process -· Preventing the use of differences in messages or behavior of validation steps to reduce and target the attacker's search space +- Preventing disclosure of the failed step or component of the Recovery process +- Preventing the use of differences in messages or behavior of validation steps to reduce and target the attacker's search space This policy is consistent with the principle of Minimum Disclosure and ensures that the Recovery Service does not provide additional information about the record status, validity of input components, or the failure step of the process to the requester. @@ -1167,7 +1166,7 @@ Security Principle: The Recovery Service MUST NOT reveal which individual recovery component failed. -15. ASR Security Principle +### 15. ASR Security Principle Neither of the two components ASR-REC_Display and ASR-VAR alone is sufficient to fully reconstruct ASR-REC_Main and Final_Entropy. @@ -1280,12 +1279,12 @@ But if the attacker has only one of the two components ASR-REC_Display or ASR-VA Also, to obtain key_local, ASR-REC_Main must first be reconstructed. And to obtain Final_Entropy, in addition to key_local, obtaining key_network from the network's Recovery infrastructure is also necessary; provided that the required information, including ASR-REC_Display_ID, ASR-VAR_ID, and Recovery_Mode, is sent according to the defined process and the request passes the network security controls, including PoW, Rate Limit, and other validation policies. -16. What is Recovery_Mode? +### 16. What is Recovery_Mode? Recovery_Mode is a simple field that specifies which recovery mode the user has chosen: -· 12 → ASR-REC mode with twelve four-digit numbers -· 24 → ASR-REC mode with twenty-four four-digit numbers +- 12 → ASR-REC mode with twelve four-digit numbers +- 24 → ASR-REC mode with twenty-four four-digit numbers Role of Recovery_Mode @@ -1305,8 +1304,8 @@ Practical Note: The real user knows whether they wrote down 12 numbers or 24 num Notes -· ASR-REC_Display_ID and ASR-VAR_ID do not inherently encode Recovery_Mode in their SHA-256 value. -· Recovery_Mode is an explicit and independent parameter used in the Recovery process for request validation and enforcement of Rate Limiting. +- ASR-REC_Display_ID and ASR-VAR_ID do not inherently encode Recovery_Mode in their SHA-256 value. +- Recovery_Mode is an explicit and independent parameter used in the Recovery process for request validation and enforcement of Rate Limiting. Ambiguous Error @@ -1334,24 +1333,24 @@ According to the Rate Limiting policy in ASR, if Recovery_Mode, ASR-REC_Display_ { Recovery Error } ``` -17. Numerical Comparison of Entropy Capacity of BIP-39 and ASR and Its Relation to NIST Reference Security Levels +### 17. Numerical Comparison of Entropy Capacity of BIP-39 and ASR and Its Relation to NIST Reference Security Levels First, precise definition of NIST security levels NIST has defined five reference security levels for evaluating the resistance of cryptographic systems against attacks. These levels are defined based on comparing the computational cost of attacks with reference operations in symmetric algorithms, including AES and SHA hash functions. -· Level 1: Difficulty equivalent to key search of a block cipher with a 128-bit key, such as AES-128. -· Level 2: Difficulty equivalent to collision search in a 256-bit hash function, such as SHA-256. -· Level 3: Difficulty equivalent to key search of a block cipher with a 192-bit key, such as AES-192. -· Level 4: Difficulty equivalent to collision search in a 384-bit hash function, such as SHA-384. -· Level 5: Difficulty equivalent to key search of a block cipher with a 256-bit key, such as AES-256. +- Level 1: Difficulty equivalent to key search of a block cipher with a 128-bit key, such as AES-128. +- Level 2: Difficulty equivalent to collision search in a 256-bit hash function, such as SHA-256. +- Level 3: Difficulty equivalent to key search of a block cipher with a 192-bit key, such as AES-192. +- Level 4: Difficulty equivalent to collision search in a 384-bit hash function, such as SHA-384. +- Level 5: Difficulty equivalent to key search of a block cipher with a 256-bit key, such as AES-256. In this classification, levels 1, 3, and 5 are respectively associated with 128, 192, and 256 bits of classical security. Levels 2 and 4 are respectively related to the collision resistance of SHA-256 and SHA-384, which NIST places in the reference categories of 128 and 192 bits, respectively. Therefore, level 1 and level 2 both fall within the 128-bit reference range, but the type of computational problem is different: -· Level 1 relates to Key Search. -· Level 2 relates to Collision Search in a hash function. +- Level 1 relates to Key Search. +- Level 2 relates to Collision Search in a hash function. Also, NIST specifies that security levels 2 and 4 require precise quantum security analysis, and merely having a certain number of entropy bits is not sufficient to attribute a system to these levels. NIST defines these categories in order of increasing reference security strength, but the type of problem and attack model are fundamental in determining the level. @@ -1359,31 +1358,31 @@ Numerical Comparison of Entropy Capacity BIP-39 with 12 words of 11 bits and number range 0000 to 2047, totaling 2048 states -· Total space: 2^132 -· Checksum: 4 bits -· Initial entropy: 128 bits -· Numerical comparison with NIST: on par with the 128-bit reference threshold of level 1 in terms of entropy capacity +- Total space: 2^132 +- Checksum: 4 bits +- Initial entropy: 128 bits +- Numerical comparison with NIST: on par with the 128-bit reference threshold of level 1 in terms of entropy capacity BIP-39 with 24 words of 11 bits and number range 0000 to 2047, totaling 2048 states -· Total space: 2^264 -· Checksum: 8 bits -· Initial entropy: 256 bits -· Numerical comparison with NIST: on par with the 256-bit reference threshold of level 5 in terms of entropy capacity +- Total space: 2^264 +- Checksum: 8 bits +- Initial entropy: 256 bits +- Numerical comparison with NIST: on par with the 256-bit reference threshold of level 5 in terms of entropy capacity ASR-REC with 12 four-digit 13-bit numbers and number range 0000 to 8191, totaling 8192 states -· Total space: 2^156 -· Checksum: none -· Nominal entropy: 156 bits, assuming uniform and independent generation of values -· Numerical comparison with NIST: above the 128-bit threshold and below the 192-bit threshold +- Total space: 2^156 +- Checksum: none +- Nominal entropy: 156 bits, assuming uniform and independent generation of values +- Numerical comparison with NIST: above the 128-bit threshold and below the 192-bit threshold ASR-REC with 24 four-digit 13-bit numbers and number range 0000 to 8191, totaling 8192 states -· Total space: 2^312 -· Checksum: none -· Nominal entropy: 312 bits, assuming uniform and independent generation of values -· Numerical comparison with NIST: above the 256-bit threshold +- Total space: 2^312 +- Checksum: none +- Nominal entropy: 312 bits, assuming uniform and independent generation of values +- Numerical comparison with NIST: above the 256-bit threshold In ASR, removing Checksum ensures that no part of the 13-bit capacity of each unit is allocated to a control value; therefore, assuming uniform and independent generation of values, all this capacity can be calculated as nominal entropy capacity. @@ -1444,10 +1443,10 @@ The ASR architecture has two independent boundaries: Result of this separation: -· Disclosure of either of the two local components (ASR-REC_Display or ASR-VAR) alone does not lead to disclosure of the entire recovery secret. -· Even simultaneous disclosure of both local components, without access to key_network, is not sufficient to reconstruct Final_Entropy. -· ASR-REC or ASR-VAR alone are not a complete recovery key. -· Local ASR information alone is not sufficient to reconstruct Final_Entropy. +- Disclosure of either of the two local components (ASR-REC_Display or ASR-VAR) alone does not lead to disclosure of the entire recovery secret. +- Even simultaneous disclosure of both local components, without access to key_network, is not sufficient to reconstruct Final_Entropy. +- ASR-REC or ASR-VAR alone are not a complete recovery key. +- Local ASR information alone is not sufficient to reconstruct Final_Entropy. ___ ___ # Additional Engineering Considerations and Security Constraints From 4b3d73a8e11a49b1da816bb3563c841c3c49468c Mon Sep 17 00:00:00 2001 From: alichatme Date: Sat, 10 Oct 2026 15:34:47 +0330 Subject: [PATCH 14/20] Update tip --- tip-asr.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 6bbc780..4be7d6f 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -16,8 +16,20 @@ ___ ___ # Introduction -One of the most significant challenges in the cryptocurrency ecosystem is the secure storage of Seed Phrases. Standard protocols like BIP-39, despite their simplicity and widespread adoption, lack any independent cryptographic layer or active defense mechanisms. -Consequently, if the seed phrase is compromised, the user’s entire assets become accessible and transferable without any security barriers. In this context, the ASR standard is introduced to eliminate this fundamental weakness. +One of the most significant challenges in the cryptocurrency ecosystem is the secure storage and safeguarding of recovery phrases. Standard protocols such as BIP-39, despite their simplicity and widespread adoption, have designed recovery as a fully offline process. As a result, conventional methods lack any independent cryptographic layer or active defense mechanisms, and rely solely on the recovery phrase itself. This design introduces a fundamental vulnerability: if the Seed phrase is compromised, the user's entire assets become accessible and transferable without any security barrier, without network oversight, and without any rate limiting. + +In this context, the ASR (Adaptive Secure Recovery) standard is introduced to eliminate this fundamental weakness. In addition to strengthening the recovery phrase itself — by increasing the entropy of each unit to 13 bits and expanding the number range to 8192 states — ASR fundamentally redefines the recovery process as a network-gated operation. This redefinition operates on two layers: + +- User Layer: The user's recovery data is split into two independent components — ASR-REC_Display, which the user maintains as recovery data, and ASR-VAR, which is kept in the user's memory or in a location separate from ASR-REC_Display. +- Entropy Layer: Final_Entropy is split into two independent shares — key_local, which is encoded into the ASR-REC_Main structure, and key_network, which is independently generated by the wallet and stored in a protected form within the network's recovery infrastructure. + +The wallet requires both shares, key_local and key_network, to reconstruct Final_Entropy. + +The security objective of ASR is that possessing only one of the recovery components is, by itself, insufficient to reconstruct key_local; and reconstructing Final_Entropy is impossible without network access and obtaining key_network from the recovery infrastructure. + +ASR is not a cryptographic layer added on top of existing standards; it is a paradigm shift in how digital assets are designed, managed, and protected. + +ASR is not limited to expanding the space of recovery values; rather, through a recovery-management-based architecture, it redefines cryptographic credentials by separating local and network shares and applying independent controls throughout the recovery process. ___ ___ # Rationale From 526b069f2ab9dee9ecb92587ef711795297123b7 Mon Sep 17 00:00:00 2001 From: alichatme Date: Sun, 11 Oct 2026 20:58:45 +0330 Subject: [PATCH 15/20] Update tip-asr.md --- tip-asr.md | 43 ++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 40 insertions(+), 3 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 4be7d6f..bb508b5 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -34,10 +34,47 @@ ___ ___ # Rationale -ASR is a standard that ensures the user’s digital currency account assets are not at risk, even if the recovery data is lost or stolen. -This is because the recovery process in ASR, in addition to a numerical variable, depends on a private keyword variable. This variable is stored in the user’s memory or in a separate location from the numerical variable and acts as the key for recovery. It consists of only 12 English letters, which are easy to remember or can be stored separately from the numerical variable to ensure that even if the numerical recovery data is fully exposed, recovery without the keyword is practically impossible. +The ASR standard is designed to reduce the risk of unauthorized recovery of cryptocurrency accounts and to prevent offline attacks on recovery data. This standard is intended for scenarios in which part of the recovery data is lost, disclosed, or stolen. -ASR is not a static recovery mechanism; rather, it is a network-dependent, account-state-dependent, and Core security policy-dependent recovery system. This design transforms asset recovery from a single point of failure into a multi-stage, auditable, and adaptive attack-resistant process. +By employing independent protection layers (the user layer and the network layer), the ASR architecture shifts account recovery dependence from a single phrase to a set of complementary data, and moves account security beyond reliance on a single data set. + +- The user layer is responsible for preventing unauthorized disclosure of local recovery data (ASR-REC_Display and ASR-VAR). +- The network layer is responsible for preventing offline recovery and limiting unauthorized attempts by an attacker, in scenarios where the attacker has access to only one of the two components of the data required for account recovery. + +The recovery process in ASR depends on two components in the user layer: + +- ASR-REC_Display, which — depending on the user's choice — has two modes: 12 or 24 four-digit 13-bit numbers; and +- ASR-VAR, which — corresponding to the same prior user choice (12 or 24 four-digit 13-bit numbers) — consists respectively of 12 or 24 uppercase English letters, and acts as the recovery key for the user. + +The user must store these two components separately from each other; for example, ASR-VAR may be kept in the user's memory, or in a location separate from ASR-REC_Display (i.e., the numerical data). + +The dependence of the recovery process on the two components in the user layer means that, if one of the components is disclosed, completing the recovery process without access to the other component is possible only by guessing the second component or through computational search. + +By making the recovery process dependent on the network, the ASR architecture strictly limits an attacker's guessing or computational search via the Rate Limiting policy. The ASR recovery architecture is not a static recovery mechanism. In addition to dependence on the two components in the user layer, it features a network-centric system for detecting unsuccessful and suspicious recovery attempts, and for detecting attempts to recover an account using incomplete recovery data. + +When the attacker lacks access to one of the recovery components in the user layer, every attempt by the attacker to recover the account is detected by the network and — under Rate Limiting policies — recorded, reported, and limited. + +Dependence on the network makes the following actions by the network possible when one component of the account's recovery data is disclosed: + +1. Detection of account recovery attempts in scenarios where the attacker, possessing one of the recovery components in the user layer, is forced to guess or use computational search to obtain the second component. + +2. Limiting the attacker's repeated recovery attempts through the Rate Limiting policy. + +3. The network, by sending an alert message to the active wallets associated with the same account, informs the owner of the recovery attempt. If the user has previously enabled the delayed account activation option, the attacker will be unable — even with a correct guess and after passing the Rate Limiting policy — to transfer assets before the period specified by the owner has elapsed. + +In this architecture, completion of the recovery process first requires, in the user layer, the numerical variable ASR-REC_Display and the lexical variable ASR-VAR, as well as the execution of ASR-CRC cycles for local reconstruction of ASR-REC_Main and derivation of key_local. + +Completion of the recovery process — through reconstruction of Final_Entropy — depends on the wallet having access to key_local from the user layer, and access to key_network from the network layer (i.e., the network recovery infrastructure). These two components are necessary and essential for reconstructing Final_Entropy and completing the account recovery process. + +Final_Entropy is reconstructed through the XOR operator between key_local and key_network. Consequently, completing the recovery process requires the wallet to have access to both shares — key_local (user layer) and key_network (network layer). The XOR operator in this structure ensures that neither share alone is sufficient to reconstruct Final_Entropy. + +key_network is generated independently by the wallet at backup time and is stored in a protected form within the network recovery infrastructure. + +At recovery time, the only way for the wallet to obtain key_network is to send both recovery components as ASR-REC_Display_ID and ASR-VAR_ID to the recovery infrastructure, and to pass the network's security controls. These controls include recovery request validation, the Proof-of-Work challenge (PoW), the unified Rate Limiting policy, and protection of key_network. The goal is for repeated or unauthorized recovery attempts — and unauthorized recovery — to be detected and limited by the network. Issuance of recovery authorization takes place only after successful passage through the defined controls. + +In addition, the ASR architecture supports alert mechanisms and supplementary protective measures. In the alert system of this architecture, upon detecting an unsuccessful or suspicious recovery attempt, the network recovery infrastructure first limits unauthorized attempts through Rate Limiting policies, and then sends alerts to the active wallets associated with the same account. + +After receiving the alert, the account owner may — depending on the level of the identified threat — activate capabilities such as protective delay in account activation, or transfer of assets to a secure account. ___ ___ # Overall ASR Architecture From 26082b7bc9fe540c8b04ee891ca75331ecf603ef Mon Sep 17 00:00:00 2001 From: alichatme Date: Tue, 13 Oct 2026 23:10:41 +0330 Subject: [PATCH 16/20] Update tip-asr.md --- tip-asr.md | 124 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 124 insertions(+) diff --git a/tip-asr.md b/tip-asr.md index bb508b5..4e8ef01 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -1498,6 +1498,130 @@ Result of this separation: - Local ASR information alone is not sufficient to reconstruct Final_Entropy. ___ ___ +# Account Activation Delay Option + +The ASR standard supports an optional feature called Account Activation Delay. This feature is disabled by default for every account. + +The user can, at any time, select a delay period from 1 to 125 days and send and register the activation and the configured delay duration with an Access Keys signature to the network recovery infrastructure. These settings can be changed or disabled for the account at any time. + +Wallets MUST provide the owner with the ability to view the current status of the Account Activation Delay feature, the configured delay duration, and to change its settings. + +### Periodic Recovery Status Inquiry + +To enhance account security, it is recommended that the owner periodically inquire about the status of pending activation requests, in proportion to the configured delay duration, by sending a signed query (Signed Query) to the network recovery infrastructure. + +This periodic inquiry helps the owner promptly identify suspicious requests and potential threats and provides an appropriate security response window before the activation delay period for new accounts expires. Periodic inquiry alone does not guarantee asset security; rather, it is a defensive and complementary layer that, alongside other security controls, helps protect the user's assets. + +Viewing the Number of Requests: + +Wallets MUST provide the owner with the ability to view — the number of activation requests — the delay period, and the remaining time for each request. This query MUST include a valid signature from one of the account's authorized Access Keys and be sent to the Recovery Service via the secure channel available in the TRON infrastructure. The Recovery Service MUST validate the signature and the authorization of the signing key, and only upon successful validation, return the number of pending requests and the remaining time for each to the requesting wallet. + +### Purpose of the Feature + +The purpose of creating a delay in the activation of new accounts is to create a time window for the owner to react in situations such as disclosure of recovery information, information theft, or other related security threats. + +When the owner, through periodic inquiry or by receiving a notification from the recovery infrastructure, encounters a new recovery request — which they did not initiate or manage themselves — they identify this message as suspicious activity or a potential attempt by an attacker to gain unauthorized access to the account's assets. In this situation, the delay period gives the owner the opportunity to take necessary protective actions before the configured delay expires and before the recovery process for the new request is completed. + +Protective actions available to the owner include: + +- Increasing the delay duration up to the maximum allowed (125 days) +- Transferring assets to a secure account +- Changing the account's Owner Key through the network permission mechanism (Permission) — provided that this action invalidates the previous recovery data, and consequently, renders the stolen recovery data (which maps to the old key) unusable. In this case, due to the change in recovery data, the owner MUST back up the account again. + +If the delay feature is enabled and a new activation request begins, the network recovery infrastructure MUST send a notification or alert about the start of the new activation request to the previously active wallets associated with the same account. + +### Reset Mechanism + +Any change in the delay settings — including re-enabling or disabling and changing the delay duration — is only possible by resending the settings along with an Access Keys signature of the account to the network recovery infrastructure. + +This change MUST apply to all account activation requests — including requests currently undergoing the delay period. + +The network recovery infrastructure MUST apply the new settings as a complete reset (and not as a continuation of previous processes) for all activation requests of the same account. The delay duration is recalculated from the time of successful registration of the new settings, regardless of the time elapsed in the previous period. The new delay period, for all requests, starts from the time the changes are registered, and its end time is calculated based on the new valid duration. + +The network recovery infrastructure MUST send and notify the new delay status and time — via notification or message — to the associated active wallets and activation requests that are awaiting the completion of the configured delay and recovery completion. + +### Status of the New Account During the Delay Period + +The new wallet, during the delay period, due to not receiving key_network and consequently being unable to reconstruct Final_Entropy, cannot reconstruct the account keys through the ASR recovery process. In this state, and without the account keys, the wallet will not be able to sign transactions or transfer the account's assets. + +If the delay option is enabled, the network recovery infrastructure MUST, after successful validation of the recovery request, provide the Activation_Resume_Token along with general account information including: + +- Account identifier or public address +- Delay status +- End time of the period + +— without disclosing key_network — to the wallet. + +During this period, the new account is only capable of: + +- Viewing the balance and general account information through the public blockchain infrastructure +- Viewing the timer and remaining time until the end of the delay period +- Resending the recovery completion request using the Activation_Resume_Token after the delay period ends, to the network recovery infrastructure, along with the required information and following the defined process. + +### Delayed Account Activation Process + +1. The wallet initiates the recovery request according to the ASR protocol. In the first step, Recovery_Mode along with ASR-REC_Display_ID is sent to the network recovery infrastructure. + +2. The network recovery infrastructure creates a Proof-of-Work challenge (PoW_Challenge) and sends it to the wallet. + +3. After solving the Proof-of-Work challenge, the wallet returns the solution (PoW_Solution) along with ASR-VAR_ID to the network recovery infrastructure. The ASR-REC_Display_ID and the Recovery_Mode value MUST also be associated with this request through a valid Recovery Session. + +4. The network recovery infrastructure checks the Proof-of-Work response, its connection to the current Recovery Session, the validity of the recovery identifiers, and other necessary security controls. If the recovery request is successfully validated — and the Account Activation Delay is enabled for the account — the network recovery infrastructure identifies the account associated with the recovery information and returns the recovery status response to the wallet without disclosing key_network. This response includes only the account identifier or public address, the delay status, the configured period end time, and the Activation_Resume_Token (to be used for the continuation mechanism at the end of the configured delay period). + +5. Upon receiving the account address associated with the recovery request, the wallet displays the balance and general information of that account to the user through the public blockchain infrastructure. + +Until the end of the configured delay period, the network recovery infrastructure MUST refrain from delivering key_network to the wallet. Consequently, the wallet cannot compute Final_Entropy and reconstruct the account keys through the ASR recovery process. Without completing the recovery process and reconstructing the account keys, the user or wallet cannot sign transactions or transfer the account's assets. + +6. By displaying a countdown of the remaining time until the end of the delay period, the wallet shows the user the allowed time for sending the recovery completion request to the network recovery infrastructure. The start and end times of this period MUST be recorded and controlled in the network recovery infrastructure. Therefore, the wallet's display timer is solely for user information and MUST NOT be the reference for determining the end of the configured delay period. + +The network recovery infrastructure MUST send notifications regarding the start, change, or end of the delay period to all active wallets and activation requests associated with the same account — i.e., wallets that have sent an activation request to the network infrastructure. These notifications are for informational purposes, and the execution of security controls MUST NOT depend on their successful sending or receipt. + +7. After the delay period ends, the wallet, at the user's request, initiates the recovery completion process again. This request, in the first step, MUST include returning the Activation_Resume_Token (to use the continuation mechanism), along with ASR-REC_Display_ID and Recovery_Mode. After the PoW_Challenge is sent by the network recovery infrastructure, the wallet sends the PoW_Challenge response along with ASR-VAR_ID to the recovery infrastructure, and upon final approval, receives NRA, key_network, and ASR_Version from the recovery infrastructure. + +The wallet first selects the ASR-CRC algorithm corresponding to that version using the received ASR_Version. Then, using ASR-REC_Display and ASR-VAR received from the user and executing ASR-CRC cycles, it reconstructs ASR-REC_Main. Afterwards, by decoding ASR-REC_Main, it extracts key_local. Finally, by combining key_local (local share, reconstructed from the user layer) and key_network (network share, received from the recovery infrastructure) via the XOR operator, it computes Final_Entropy and completes the account recovery process. + +If the owner has validly disabled the delay feature, the wallet, regardless of the Activation_Resume_Token, can send the recovery completion request without waiting for the delay period to end; however, the network MUST still re-execute all necessary validation steps and security controls. + +### Confidential Continuation Token (Activation_Resume_Token) + +To properly manage activation requests during the delay period, the network must be able to associate the continuation of a request with the same registered process. For this purpose, the use of a confidential token is proposed. + +Token Generation and Delivery: + +When the Account Activation Delay option is active for an account and the wallet has sent all required information for the recovery request to the network recovery infrastructure, if all checks and security controls — for the recovery request — are successful, the network recovery infrastructure MUST provide the wallet with basic information including the account address, delay status, and remaining time until the end of the delay period, along with a random and confidential token named Activation_Resume_Token. + +This token MUST be generated using a cryptographically secure pseudo-random number generator (CSPRNG) with sufficient length and entropy. + +The wallet MUST securely protect this token and, after the configured delay period ends, in the first step to complete the recovery process, send the Activation_Resume_Token along with ASR-REC_Display_ID and Recovery_Mode to the network recovery infrastructure, and by continuing the steps, without change, according to the ASR architecture, the wallet and network complete the account recovery. + +### Cancellation of Delay Period by Owner + +If the delay period is disabled — by the owner — by sending new settings to the network recovery infrastructure, the time restriction is removed. + +With the time restriction removed, activation requests can begin the recovery completion process without needing the Activation_Resume_Token and without waiting for the delay period to end. The steps are as follows: + +1. The wallet sends Recovery_Mode and ASR-REC_Display_ID to the network recovery infrastructure. + +2. The network recovery infrastructure issues a Proof-of-Work challenge (PoW_Challenge) and sends it to the wallet. + +3. After solving the challenge, the wallet returns its solution (PoW_Solution) along with ASR-VAR_ID to the network recovery infrastructure. + +4. The network recovery infrastructure checks the validity of the request, the correctness of the PoW, and other security controls. Upon successful approval, it sends NRA, ASR_Version, and key_network to the wallet. + +5. The wallet first selects the ASR-CRC algorithm corresponding to that version using the received ASR_Version. Then, using ASR-REC_Display and ASR-VAR received from the user and executing ASR-CRC cycles, it reconstructs ASR-REC_Main. Afterwards, by decoding ASR-REC_Main, it extracts key_local. + +6. Finally, by combining key_local (local share) and key_network (network share) via the XOR operator, it computes Final_Entropy, extracts the account's private key, and completes account activation. + +### Security Considerations + +- Enabling or disabling, as well as changing the delay duration, is only permitted with the owner's valid and authorized signature via Access Keys and registering the request in the network recovery infrastructure. +- The reference for the start and end of the delay period for a request is the network recovery infrastructure; therefore, changing the device's clock or date is ineffective in bypassing this time restriction. +- Repeated and multiple recovery requests MUST NOT be able to shorten the configured delay or alter the protective status. +- The end of the delay period alone is not sufficient for delivering key_network. The network infrastructure MUST, in addition to the deadline, re-receive, check, and confirm the status of the activation process and the validity of the final request (including the values ASR-REC_Display_ID and ASR-VAR_ID). +- The start, change, and end of the delay period MUST be recorded in the network recovery infrastructure. +- Notification to other active wallets associated with the account, if eligible wallets exist, SHOULD be sent; however, applying settings and calculating the end time MUST NOT depend on the successful delivery of the notification. +___ +___ # Additional Engineering Considerations and Security Constraints 1. Intentionally Underdetermined Recovery From f1e3a56ada5f2ae38d4d2f9d2b9de68679ecac24 Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 14 Oct 2026 00:18:00 +0330 Subject: [PATCH 17/20] Update tip-asr.md --- tip-asr.md | 150 +---------------------------------------------------- 1 file changed, 1 insertion(+), 149 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 4e8ef01..eb866a6 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -1622,136 +1622,7 @@ With the time restriction removed, activation requests can begin the recovery co - Notification to other active wallets associated with the account, if eligible wallets exist, SHOULD be sent; however, applying settings and calculating the end time MUST NOT depend on the successful delivery of the notification. ___ ___ -# Additional Engineering Considerations and Security Constraints - -1. Intentionally Underdetermined Recovery - -In ASR, Seed reconstruction is deliberately underdetermined. Even with full possession of ASR-REC and ASR-VAR and complete execution of ASR-CRC, the solution space does not collapse to a single value. -The final degree of mathematical freedom required to determine the Seed is provided exclusively by the network Core and is outside the wallet’s control. - -2. Explicit Separation of Local Computation and Final Recovery Control - -All cryptographic operations -- ASR-CRC execution -- Recovery Proof generation -- ASR-VAR processing -are performed locally in the wallet. -However, these computations alone never produce the Seed or private key. - -Final recovery control depends exclusively on the issuance of Network Recovery Authorization. - -3. Fundamental dependence of recovery on network authorization (Network-Gated Recovery) - -Completion of the recovery process in ASR is subject to receiving a Network Recovery Authorization (NRA), which: - -- Without owner signature -- Without smart contracts -- Without fees or gas -- Only while online - -Without NRA, Seed reconstruction is cryptographically and engineering-wise -impossible. - -4. Preventing Adaptive Online Attacks by Stabilizing the Recovery Context - -To prevent adaptive online brute-force attacks, the wallet is required to generate a Recovery Context Identifier derived from ASR-REC before any combination of ASR-REC with ASR-VAR and before executing ASR-CRC. - -This identifier: - -- Is independent of ASR-VAR -- Is independent of variable cryptographic outputs -- Remains constant for all recovery attempts of a single account - -Network policies such as rate limits, delays, and attempt counters are applied based on this identifier, not based on the Proof or cryptographic variables. - -5. Ineffectiveness of Attacker Variable Changes Changing any of the following does not create a new recovery context: - -- ASR-VAR -- Wallet client or version -- IP, VPN, Tor, or network source -- Recovery Proof - -All these attempts are mapped to a single Recovery Context and will be subject to network restrictions. - -6. Minimum Disclosure Principle During recovery The network, during the recovery process - -- Has no access to ASR-VAR -- Does not store Seeds or private keys -- Does not interpret Recovery Proof contents - -The network only issues or denies recovery authorization based on account state and security policies. - -7. Absolute Prohibition of Offline Recovery - -Unlike BIP-39, ASR provides no valid offline recovery path. - -Lack of network access definitively prevents recovery. - -This is a fundamental design requirement, not an implementation flaw. - -8. Deterministic Recovery Context Derivation - -To prevent adaptive online brute-force attacks and any attempt to bypass network rate-limiting policies, the wallet is required to generate a unique identifier called the Recovery Context Identifier (RCID) before receiving ASR-VAR from the user and before any cryptographic processing, ASR-CRC execution, or Recovery Proof generation. - -This identifier must have the following characteristics: - -- Derived deterministically and ONLY from the raw ASR-REC data -- Completely independent of: - - ASR-VAR - - ASR-CRC outputs - - Recovery Proof - - Wallet version, client, IP, or network conditions -- Remains constant for all recovery attempts associated with a fixed, unchanging ASR-REC -- Generated before any user interaction with the cryptographic process - -To state it more explicitly: - -RCID must be a function solely of ASR-REC, with no other variable involved in its generation. - -Requirement to map all attempts to a single context - -The wallet is required to send the generated RCID along with the Network Recovery Authorization (NRA) request to the network. - -The network applies all security policies, including: - -- Rate Limit -- Delay -- Attempt counters -- Progressive time-based restrictions - -based on the RCID, not on cryptographic variables, Proof, or user inputs. - -Consequently, changing any of the following by an attacker: - -- Changing ASR-VAR -- Changing Recovery Proof -- Changing IP, VPN, Tor, or network source -- Changing wallet/client version or type - -will not create a new recovery context. - -All such attempts are considered by the network as attempts to recover a single account and will be subject to the same security restrictions. - -Security implication of RCID design - -This design ensures that an attacker cannot bypass network rate-limiting policies by changing input variables or the execution environment. - -As a result: - -Adaptive online brute-force attacks in ASR become practically and temporally impossible. - -Because the network, instead of rate-limiting "cryptographic attempts", rate-limits the "recovery target". - -This pattern, known as account-centric rate limiting, is considered one of the most advanced defense patterns in financial and banking systems. - -Implementation MUST - -In wallet implementation: - -- RCID generation must be performed before receiving any user input and before any cryptographic processing. -- Any dependency of RCID on ASR-VAR, CRC output, Proof, or execution conditions is considered a violation of ASR security requirements. - -## Responsibilities +# Responsibilities ### User Responsibilities Maintain ASR-VAR and ASR-REC separately @@ -1775,25 +1646,6 @@ The wallet: This limitation is a fundamental security constraint in the ASR design, not an implementation flaw. -### Role and Responsibilities of the Core Network in the ASR Recovery Process - -The Core network in ASR does not act as a "computing engine" or "Seed holder". Instead, it is responsible for providing the final degree of freedom necessary to complete the recovery. - -Network responsibilities are limited to the following: - -- Evaluating account status and active security policies -- Applying rate limits, delays, and attempt counters based on the Recovery Context -- Issuing or denying the Network Recovery Authorization (NRA) - -The network: - -- Has no access to ASR-VAR -- Does not store or reconstruct the Seed or private key -- Does not participate in the wallet's local cryptographic computations - -However, without issuing the NRA, the Seed reconstruction process is cryptographically and engineering-wise impossible to complete. -This dependency is not an ownership control mechanism, but a network‑centric security constraint to prevent unauthorized recovery and adaptive attacks. - ### ASR Network Layer Responsibilities - No smart contracts From b092361fde074ba6d3d80047dd3321c7dd34fdb5 Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 14 Oct 2026 00:30:19 +0330 Subject: [PATCH 18/20] Update tip-asr.md --- tip-asr.md | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index eb866a6..9d9c4bd 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -1757,23 +1757,6 @@ The recovery process is only completed when: Without these four steps, recovery is impossible. -## Checksum in ASR -The Checksum in the ASR standard is used solely to detect typographical errors in the recovery data entered by the user and has no security or cryptographic role in the recovery process. - -The Checksum is generated as a value derived from the ASR-REC data using the SHA-512/256 function, but this value: - -- Does not by itself indicate the correctness of ASR-REC -- Does not enable full or definitive validation of the recovery data -- Does not reduce the cryptographic search space - -Final validation of recovery data in ASR is inherently network‑dependent and occurs only within the framework of the online recovery process, after verification of account status and Core network security policies. - -Consequently: - -- The Checksum in ASR is merely a user‑experience aid -- It provides no valid path for offline verification of recovery data -- It does not enable recovery or validation independent of the network in any way - ## Role of KDF and Seed in ASR The Key Derivation Function (KDF) and Seed are still generated before ASR. From d89f45ac789adf9cee4681900d67d2f68d61a7c8 Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 14 Oct 2026 00:34:29 +0330 Subject: [PATCH 19/20] Update tip-asr.md --- tip-asr.md | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 9d9c4bd..60fe087 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -1785,18 +1785,6 @@ transforms the recovery layer from a single point of failure into a multi-stage, This precise positioning introduces ASR as an independent, complementary layer in cryptographic wallet architecture, not a replacement for key generation standards. ___ ___ -# Absolute Prohibition of Offline Recovery in ASR - -Unlike BIP-39, where recovery is completely offline, ASR is fundamentally designed to be network‑dependent. - -Executing ASR-CRC and mapping to ASR-REC alone does not result in the reconstruction of the Seed or private key. -The output of all ASR components is only an intermediate recovery value. - -Full recovery is conditional upon receiving a Network Recovery Authorization (NRA) from the Core network. - -In the absence of NRA, recovery is engineering‑wise impossible. -___ -___ # Threat Model The ASR standard is designed to protect the account recovery process against threats related to the disclosure of recovery data, and not to counter full compromise of the user's execution environment. From 8dbd509de4dd78c6ff84de1928d836f7a2e505af Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 14 Oct 2026 00:53:22 +0330 Subject: [PATCH 20/20] Update tip-asr.md --- tip-asr.md | 34 ---------------------------------- 1 file changed, 34 deletions(-) diff --git a/tip-asr.md b/tip-asr.md index 60fe087..372dd56 100644 --- a/tip-asr.md +++ b/tip-asr.md @@ -1656,40 +1656,6 @@ This limitation is a fundamental security constraint in the ASR design, not an i - Mandatory: When a restriction is applied, a countdown timer must be displayed to the user, indicating the remaining waiting time. ___ ___ -# Delayed Account Activation Option - -When viewing recovery data, the user can enable the Delayed Account Activation option (disabled by default). -The user can select a delay period from 1 to 94 days and register it with the owner’s signature on the network. - -If this option is enabled, whenever a **Network Recovery Authorization (NRA)** is issued by the network and account recovery succeeds, the newly recovered account will remain inactive until the end of the delay period. - -### Displaying Recovered Devices with a Single RCID and the Ability to Terminate Previous Sessions: - -- It should be possible to view active and inactive devices associated with an RCID, as well as to terminate previous sessions for ASR accounts. -- Limitation for newly recovered accounts: -A newly recovered account will not be able to terminate previous sessions for 30 days after activation. - -### Status during the delay period: -- Assets are view‑only. -- No signed operations by the owner are permitted before the delay ends. -- A countdown timer shows the remaining time to the user. -- Notifications are sent to previously active wallets. - -### Security note: -If the owner still has access to a previously active wallet, they can, upon detecting suspicious activity or a potential attack, stop the new account activation process before the delay ends by providing a valid signature. - -### Definition of “Owner Activity” -Any valid on-chain transaction signed by the owner that changes network state, including but not limited to - -- Asset transfers -- Voting -- Freeze/unfreeze -- Stake/unstake -- Reward withdrawal -- Direct smart contract calls - -Receiving assets without owner signature is not considered activity. - ## Position of ASR in the Key Generation to Recovery Chain (Engineering Placement of ASR) To accurately understand the ASR standard, it is necessary to clearly define its position in the engineering chain from cryptographic key generation to the account recovery process.