Posted by coldtest-berlin
Aug 21, 2026/09:39 UTC
The strategy discussed involves ensuring that encrypted outputs are consistently 108 characters long without the need for padding. This is achieved through rejection sampling, where a new salt/initialization vector (IV) is generated if the base58-encoded length does not meet the target. On average, this process may require approximately 1.3 attempts to hit the ceiling length, making it an efficient method in terms of computational overhead, especially when compared to the cost of using Argon2id for password hashing.
The benefit of this approach is its simplicity and reliability for end-users, particularly in scenarios involving inheritance of encrypted data. By maintaining a uniform length of 108 characters, it simplifies the verification process; any deviation from this length can immediately be identified as a transcription error. This method enhances security and user confidence as it provides a straightforward pre-Key Derivation Function (KDF) check solely based on the length of the encrypted string.
Furthermore, there is a possibility of integrating a full checksum as Additional Authenticated Data (AAD) in future iterations. This would be part of a shared header in a broader BIP (Bitcoin Improvement Proposal), potentially augmenting the security framework and interoperability of the encryption method discussed here. Such developments could pave the way for standardized secure data handling practices within the cryptographic community.
Thread Summary (8 replies)
Aug 6 - Aug 23, 2026
9 messages
TLDR
We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project.
Give Feedback