PQ-single-address-backup - BIP-38 for P2MR (bc1z) - 104-char encrypted backup format

This encrypted backup employs a base58-encoded format, including components such as a salt, initialization vector, ciphertext, and tag, resulting in a total of 76 bytes that convert to 104 characters using the Bitcoin adapted Base58 alphabet. The security process incorporates PBKDF2-HMAC-SHA256 with 200,000 iterations for key derivation and AES-256-GCM for encryption. The seeds are stored without a version byte, aligning with FIPS-205 and BIP-360 draft specifications, which ensure the seed remains a pure 32-byte sequence. An essential component of this system is an offline HTML file designed to operate without Wi-Fi, enhancing security during encryption and decryption. The file supports the generation of a bc1z address requiring a mandatory password for access. A working prototype and detailed specifications for this backup strategy have been made available in this repository, along with a live demonstration here.

Recent adjustments in BIP-360 have removed specific references to prefixes like bc1z and bc1r, broadening the compatibility to include both P2MR and P2QRH types without limiting the protocol to prior prefix constraints. These modifications aim at enhancing the flexibility and future-proofing of the cryptographic standards involved. This update has also led to an enhancement in the user experience for recovery procedures, ensuring features like checksum validation and typo detection are implemented before executing Key Derivation Functions (KDFs). Moreover, new test vectors will address different failure scenarios to improve robustness and reliability for paper-based backups.

Further advancements are being considered for version 2 of the PQ-SAB, where internal restructuring will move versioning information within the authenticated payload. This change allows for a more reliable decoding process that can effectively reject incorrect wrappers due to unsupported versions or wrong passwords. The inclusion of human-readable identifiers for algorithms and encryption processes outside the encrypted portion remains a critical feature. Additionally, maintaining a 104-character limit facilitates easier scanning and transcription, incorporating a checksum within this character count to aid in typo detection before decryption processes begin.

Finally, the proposed encryption method suggests maintaining an output length of 108 characters through rejection sampling, ensuring uniformity that simplifies verification processes for end-users. This method not only boosts security but also enhances user confidence by allowing straightforward pre-Key Derivation Function (KDF) checks based solely on the length of the encrypted string. Future improvements might involve integrating a full checksum as Additional Authenticated Data (AAD) within a broader Bitcoin Improvement Proposal (BIP), potentially enhancing the overall security framework and interoperability of the method. These developments point toward standardized, secure data handling practices within the cryptographic community, emphasizing user-friendly approaches to key management and recovery.