After recently speaking with a peer in this space (@adam-th), he brought up an interesting perspective on randomizing wallet addresses. Pivoting off of NIST's 800-57 “The estimated time period during which data protected by a specific cryptographic algorithm (and key size) remains secure is called the algorithm security lifetime. During this time, the algorithm may be used to both apply cryptographic protection (e.g., encrypt data) and to process the protected information (e.g., decrypt data); the algorithm is expected to provide adequate protection for the protected data during this period. Information protected by cryptographic mechanisms is secure only if the algorithms remain strong, and the keys have not been compromised.”
An idea he had was implementing two controls:
Two controls that would be far more reasonable while effectively achieving the same end would be for future standards to consider an explicit “cryptoperiod” for private keys used to store digital assets and a recommended value limit per blockchain address. Meaning, private key X should be rotated every 365 days unless there is evidence of a compromise. Additionally, the public blockchain address associated to private key X should not have a value in excess of $1mm USD. If the value increases beyond $1mm USD, a new private key and corresponding public blockchain address should be created and the value in excess of $1mm USD be moved to that second address. This should be continued to make as small as possible the fault boundary of a private key.
Thought this could be an interesting thing to add as changing addresses for each transaction is mandatory for a high level grade in CCSS.
After recently speaking with a peer in this space (@adam-th), he brought up an interesting perspective on randomizing wallet addresses. Pivoting off of NIST's 800-57 “The estimated time period during which data protected by a specific cryptographic algorithm (and key size) remains secure is called the algorithm security lifetime. During this time, the algorithm may be used to both apply cryptographic protection (e.g., encrypt data) and to process the protected information (e.g., decrypt data); the algorithm is expected to provide adequate protection for the protected data during this period. Information protected by cryptographic mechanisms is secure only if the algorithms remain strong, and the keys have not been compromised.”
An idea he had was implementing two controls:
Two controls that would be far more reasonable while effectively achieving the same end would be for future standards to consider an explicit “cryptoperiod” for private keys used to store digital assets and a recommended value limit per blockchain address. Meaning, private key X should be rotated every 365 days unless there is evidence of a compromise. Additionally, the public blockchain address associated to private key X should not have a value in excess of $1mm USD. If the value increases beyond $1mm USD, a new private key and corresponding public blockchain address should be created and the value in excess of $1mm USD be moved to that second address. This should be continued to make as small as possible the fault boundary of a private key.
Thought this could be an interesting thing to add as changing addresses for each transaction is mandatory for a high level grade in CCSS.