From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 01 Oct 2026 10:07:53 -0700 Received: from mail-ot1-f64.google.com ([209.85.210.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1xCKG8-0005RW-GW for bitcoindev@gnusha.org; Thu, 01 Oct 2026 10:07:53 -0700 Received: by mail-ot1-f64.google.com with SMTP id 46e09a7af769-820ce3bbaa8sf2917569a34.3 for ; Thu, 01 Oct 2026 10:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1790874466; x=1791479266; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to:content-type; bh=3nXrnqji0LNIbzG1rOyc1e3/CThvOUnh1NSeXfRHA8A=; b=V093eknDuksuFkvZxkY71f2wBqDPxyg9CXuZBwBeIZaprJFXfmdXtWY4bfT6Tc2HqG 0plLvfLjqOO/0GGQuTDqTFvyqLGWOm2TIetJWk5NyluWtXGOoiI2EnK3AFmeMC8E2rcl Wew1sm1yMm1RB2ohShmamtQ+KIuQJ/pT53aYpRdyI+CqZUPVUzXBQEpYUnayBJNFP5QI rgwwIj/p4A6GBbrgeTaw+NZDBGp1YHbYPH7s+RZWOxWJbieq17obAf42bwl2L88RkEm9 TP9diFvIT7m4KRqp2yIMXBCstxsX2vt3MNsWiSeH1EpkJ7B5qU1Dsk0dyTIGqmcdPq1c y/VA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1790874466; x=1791479266; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=3nXrnqji0LNIbzG1rOyc1e3/CThvOUnh1NSeXfRHA8A=; b=Zy6HbCRvoZSV6knCApPsXOAIHsxigNerpFKTr28aipT94aIrIsmNIBffe4lljMHiS6 /yK8C6iW7aftgjONTl8gzADVuRvG696A2aIykFOLJpwvHN7dd2+tjkCjpgv0wcy20342 IF7XGmZdD2vc5WAsKzHwR3ziGDxEvjAI5G5mtKl8W2hZCoH+l0Z1bCUyNd34adDqItM2 yN030WkcOLCfB1ED9mvMf7Panr9v4/ta8fadSIV9d1gZGWyKiHZGTtZZFv5b6gTnehDb MHsosbHlCbBKlIOhmDfhjymA7iyEsc6HCWW5lzHV9RRyO3mdvV+7o+QRpXXbT7QWLbUI aMQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1790874466; x=1791479266; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:content-type :mime-version:subject:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to:content-type; bh=3nXrnqji0LNIbzG1rOyc1e3/CThvOUnh1NSeXfRHA8A=; b=PNZJ9aFF0PmUbeKVNMl9wN6BX5Qw8FBF9qAfCn2ssSebaPxT6rEdasKZxezgxMhBgB Mug/5eGfa3NmWU2okK+Y+5pdBjDsyjAB/3u0MQ5SPCx2N4RbByiDP7imK9q0Xut4AZ7a 2f02vu/lBsCIHt2yp0OdagD2FNEOsVpw7A9e/rzj2uU/Rk0eGXiIGUsLRVp9tndLFk/5 z7JtNX35a09pcpgPmJcO+vJT9aXIYC6rK9cwlwhZ4ul2wcM9de4Xdh//gztA7iZqXKIs 1nsppUzFhOYAtA6hIfW+8bC+3rjZDhjOGjxly9fVXEB2bohw0kEieeMvazWZLhpTa/q5 ozPw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AKwUvBwLr7v4ziNUQID6tllMLusWABJMf6UUCCgXBZHamAIm7HaHswdz49wkTczWTvSSFe1d/SDGN18w3Ua8@gnusha.org X-Gm-Message-State: AFuF++mBu2eyjDifFgsqh22c5nk+cFLAgQalkzun6CytJ2HPKV4FO5U3 7NSP7xGn5lb+NhTUtMtdyr7t77QVWmxacKyRrsB4RN3i8VviN5aUHTOs X-Received: by 2002:a05:6820:1787:b0:6c8:fb02:527e with SMTP id 006d021491bc7-6dcf505208dmr5122747eaf.39.1790874466095; Thu, 01 Oct 2026 10:07:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="ATskLdcK4jYWGHKOO+dc3zPf69isOHd6X0rKEnmclVSklJfpOw==" Received: by 2002:a05:6871:bd0c:b0:494:b4b7:86b4 with SMTP id 586e51a60fabf-49df0ded4b8ls910274fac.0.-pod-prod-04-us; Thu, 01 Oct 2026 10:07:34 -0700 (PDT) X-Received: by 2002:a05:6808:1161:b0:4f4:3088:e536 with SMTP id 5614622812f47-4f430983f82mr1335658b6e.16.1790874454304; Thu, 01 Oct 2026 10:07:34 -0700 (PDT) Received: by 2002:a05:690c:c18b:b0:89f:e265:68a9 with SMTP id 00721157ae682-8ac44ba2c36ms7b3; Thu, 1 Oct 2026 09:46:01 -0700 (PDT) X-Received: by 2002:a05:690c:399:b0:890:659e:3c84 with SMTP id 00721157ae682-8ac93c002c1mr32923937b3.57.1790873160831; Thu, 01 Oct 2026 09:46:00 -0700 (PDT) Date: Thu, 1 Oct 2026 09:46:00 -0700 (PDT) From: Sergei Semenov To: Bitcoin Development Mailing List Message-Id: <7917c5ea-82f2-4ce5-a5e4-b7415cca7441n@googlegroups.com> Subject: =?UTF-8?Q?=5Bbitcoindev=5D_MHFE=3A_memory=2Dhard_encryption_of_BIP39_b?= =?UTF-8?Q?ackups_into_24_words_=E2=80=94_request_for_review?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_46038_593718960.1790873160463" X-Original-Sender: mrssv2022@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_46038_593718960.1790873160463 Content-Type: multipart/alternative; boundary="----=_Part_46039_881337677.1790873160463" ------=_Part_46039_881337677.1790873160463 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, I=E2=80=99m sharing *MHFE (Memory-Hard Feistel Encryption)*, an experimenta= l=20 specification for encrypting an existing English BIP39 mnemonic with a=20 password into another checksum-valid, 24-word BIP39 mnemonic=E2=80=94the *c= ontainer* . It is designed for *offline cold-storage backups*, particularly existing=20 metal plates and capsules. Recovery restores the exact original phrase: no= =20 funds move, and the wallet remains unchanged. An existing BIP39 passphrase= =20 stays separate and is applied after recovery as before. - Specification, design analysis and test vectors=20 - Reference implementation: Rust library, CLI and WebAssembly=20 A reference implementation is available as a Rust library, CLI and=20 WebAssembly package, alongside public test vectors and an independent=20 OpenSSL-based verification script. An offline HTML interface is also=20 available in the MHFE tab of Wallet Deriver, maintained in my separate=20 Multi-Chain Wallet Tools repository on Github. One aspect I find particularly elegant is how the construction uses the=20 space left by shorter mnemonics. Their entropy occupies less than the=20 container=E2=80=99s 256-bit state. MHFE fills the remaining space with a re= covery=20 verifier derived from SHA-256. Its leading bits are exactly the original=20 BIP39 checksum; the rest extend that same digest: Original mnemonic -> source entropy + recovery verifier: 12 words -> 128 bits + 128 bits 15 words -> 160 bits + 96 bits 18 words -> 192 bits + 64 bits 21 words -> 224 bits + 32 bits 24 words -> 256 bits + no recovery verifier The entire state is then encrypted and encoded as 24 BIP39 words with the= =20 container=E2=80=99s own checksum. *The recovery check therefore requires no= =20 additional backup words.* This verifier is distinct from a BIP32 wallet=20 fingerprint. For someone creating a new wallet, this provides an explicit choice: *a=20 shorter original with an internal recovery check, or a 24-word original=20 with all 256 bits devoted to entropy and no internal password confirmation.= *=20 For an existing wallet, its original length determines the layout. Verifier= =20 matches can occur by chance and do not authenticate the container or=20 establish wallet identity; a trusted receiving address can check the=20 recovered wallet for either layout. There is also *plausible deniability through prepared decoy wallets*. The= =20 container itself opens as an ordinary BIP39 wallet. Additionally,=20 decrypting it with a different password and selecting 24 words produces=20 another valid mnemonic; the permutation under that password maps it back to= =20 the same container. That alternative wallet can be funded and used=20 beforehand, allowing a working disclosure even when MHFE use is known. The supplement=20 =20 includes formal experiments and proofs for this deniability claim within=20 its stated model, including an adversary-advantage bound in the=20 random-oracle model. These depend on assumptions about password selection,= =20 wallet history and external evidence. In particular, knowing that the real= =20 original was shorter than 24 words defeats this alternative disclosure. The= =20 proof has not received independent expert review and does not guarantee=20 that a coercer will believe the response or stop. The construction uses a *12-round balanced Feistel permutation*. Each round= =20 performs Argon2id with a state-derived salt. Defaults are *2 GiB, 12 passes= =20 and four lanes per call*, with twelve sequential calls reusing memory.=20 Recovery takes roughly one to two minutes on the reference=20 laptop=E2=80=94deliberately expensive for an operation performed rarely. A = strong,=20 independently generated password remains essential. The salts aim to prevent reuse of expensive password computations across=20 independently generated source phrases. The analysis discusses SLIP-0039=20 and other related constructions, and documents an eleven-call password=20 filter when both source and container are known. Claims about the cheapest= =20 attacks remain conjectures. The fixed-size format has costs: it is deterministic, unauthenticated, and= =20 carries no salt, version or settings fields. Long-term recovery therefore= =20 needs compatible software and knowledge of any non-default settings.=20 Entering the container directly into a normal wallet opens an unrelated=20 wallet; MHFE recovery must come first. I would especially welcome feedback on: - *Cryptanalysis:* cheaper password filters, amortized attacks or=20 overlooked related constructions. - *Deniability:* weaknesses or missing assumptions in the formal model. - *Recovery and interoperability:* whether preserving exactly 24 backup= =20 words justifies the tradeoffs, and what wallet developers would need=20 clarified. The specification was developed with substantial ChatGPT and Claude=20 assistance, as disclosed in the document. It remains experimental and has= =20 not received independent expert cryptographic review. I would appreciate any technical feedback. Thank you for your time.=20 Best regards,=20 Sergei Semenov --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 7917c5ea-82f2-4ce5-a5e4-b7415cca7441n%40googlegroups.com. ------=_Part_46039_881337677.1790873160463 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi everyone,

I=E2=80=99m sharing MHFE (Memory-Hard Feistel= Encryption), an experimental specification for encrypting an exis= ting English BIP39 mnemonic with a password into another checksum-valid, 24= -word BIP39 mnemonic=E2=80=94the container.

It is designed f= or offline cold-storage backups, particularly existing met= al plates and capsules. Recovery restores the exact original phrase: no fun= ds move, and the wallet remains unchanged. An existing BIP39 passphrase sta= ys separate and is applied after recovery as before.

A r= eference implementation is available as a Rust library, CLI and WebAssembly= package, alongside public test vectors and an independent OpenSSL-based ve= rification script. An offline HTML interface is also available in the MHFE = tab of Wallet Deriver, maintained in my separate Multi-Chain Wallet Tools r= epository on Github.

One aspect I find particularly elegant is how th= e construction uses the space left by shorter mnemonics. Their entropy occu= pies less than the container=E2=80=99s 256-bit state. MHFE fills the remain= ing space with a recovery verifier derived from SHA-256. Its leading bits a= re exactly the original BIP39 checksum; the rest extend that same digest:

Original mnemonic -> source entropy + recovery verifier:
12 words -> 128 bits + 128 bits
15 words -> 160 bits + =C2=A0= 96 bits
18 words -> 192 bits + =C2=A064 bits
21 words -> 22= 4 bits + =C2=A032 bits
24 words -> 256 bits + no recovery verifier<= /div>

The entire state is then encrypted and encoded as 24 BIP39 words wi= th the container=E2=80=99s own checksum. The recovery check therefo= re requires no additional backup words. This verifier is distinct = from a BIP32 wallet fingerprint.

For someone creating a new wallet, t= his provides an explicit choice: a shorter original with an interna= l recovery check, or a 24-word original with all 256 bits devoted to entrop= y and no internal password confirmation. For an existing wallet, i= ts original length determines the layout. Verifier matches can occur by cha= nce and do not authenticate the container or establish wallet identity; a t= rusted receiving address can check the recovered wallet for either layout.<= /p>

There is also plausible deniability through prepared decoy wa= llets. The container itself opens as an ordinary BIP39 wallet. Add= itionally, decrypting it with a different password and selecting 24 words p= roduces another valid mnemonic; the permutation under that password maps it= back to the same container. That alternative wallet can be funded and used= beforehand, allowing a working disclosure even when MHFE use is known.

=

The supplement includes formal experiments and pr= oofs for this deniability claim within its stated model, including an adver= sary-advantage bound in the random-oracle model. These depend on assumption= s about password selection, wallet history and external evidence. In partic= ular, knowing that the real original was shorter than 24 words defeats this= alternative disclosure. The proof has not received independent expert revi= ew and does not guarantee that a coercer will believe the response or stop.=

The construction uses a 12-round balanced Feistel permutatio= n. Each round performs Argon2id with a state-derived salt. Default= s are 2 GiB, 12 passes and four lanes per call, with twelv= e sequential calls reusing memory. Recovery takes roughly one to two minute= s on the reference laptop=E2=80=94deliberately expensive for an operation p= erformed rarely. A strong, independently generated password remains essenti= al.

The salts aim to prevent reuse of expensive password computations= across independently generated source phrases. The analysis discusses SLIP= -0039 and other related constructions, and documents an eleven-call passwor= d filter when both source and container are known. Claims about the cheapes= t attacks remain conjectures.

The fixed-size format has costs: it is = deterministic, unauthenticated, and carries no salt, version or settings fi= elds. Long-term recovery therefore needs compatible software and knowledge = of any non-default settings. Entering the container directly into a normal = wallet opens an unrelated wallet; MHFE recovery must come first.

I wo= uld especially welcome feedback on:

  • Cryptanalysis: cheaper password filters, amortized attacks or overlooked related const= ructions.
  • Deniability: weaknesses or missing assum= ptions in the formal model.
  • Recovery and interoperability:<= /strong> whether preserving exactly 24 backup words justifies the tradeoffs= , and what wallet developers would need clarified.

The specific= ation was developed with substantial ChatGPT and Claude assistance, as disc= losed in the document. It remains experimental and has not received indepen= dent expert cryptographic review.

I would appreciate any technical fe= edback.=C2=A0 Thank you for your time.=C2=A0

Best r= egards,=C2=A0

Sergei Semenov

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/7917c5ea-82f2-4ce5-a5e4-b7415cca7441n%40googlegroups.com.
------=_Part_46039_881337677.1790873160463-- ------=_Part_46038_593718960.1790873160463--