Repository navigation
Conversation
The gate required 24+ characters AND upper, lower, digit and symbol. That rejects a 7-word Diceware passphrase (~90 bits) while passing "Aaaaaaaaaaaaaaaaaaaaaa1!". NIST SP 800-63B recommends length over composition rules. The existing rule is unchanged (and still what Generate produces). A second way to pass is added: 24+ characters made of 6+ different words of 3+ letters, separated by spaces, hyphens or underscores. Repeated words and single-letter 'words' do not count. Hint text, the rejection message and the README are updated to match. site/index.html and SHA256SUMS.txt are the rebuilt artifacts.
…ator from the built-in BIP-39 list The password is cleared after encrypting and is the only way back in, so a typo was discovered when the file was needed, months later. Encrypt mode now has a second field: red while it differs, green once it matches, and Encrypt refuses on a mismatch or an empty repeat. Both generators fill both fields, since a generated password was never typed and has no typo to catch; the notice to save it carries that weight. A 32-character random string cannot be remembered or written down reliably. The page already carries the BIP-39 list, and 2048 = 2^11, so eleven raw bits index it with no bias: eight words carry 88 bits at zero cost to the file. Eight is deliberately not a valid mnemonic length, so no wallet accepts the result as a seed, and the notice says so. Accepted by the strength rule from seQRets#44 (6+ distinct words, 24+ chars). Verified in the browser: mismatch and empty repeat each refuse with their own message and encrypt nothing; a match encrypts and clears both fields; ten generated passphrases are 8 BIP-39 words each, all distinct, mirrored into the repeat field, green border; decrypt mode hides both the repeat field and the Passphrase button. test:crypto 91/91.
This was referenced Oct 7, 2026
Contributor
Author
|
Also available merged with every other review PR, in dependency order and verified together, as #57 — merge that or the individual PRs, not both. |
Owner
|
Thank you, Dean. This one is built on #44, which I'm not taking, and its passphrase generator depends on that rule. The concern behind typing the password twice is now covered differently in v3.0.15: encrypting requires ticking "I have saved this password somewhere safe" first. I'm keeping the file as small as possible, so I'm closing this. Please keep the suggestions coming! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #44 (the passphrase strength rule is what lets the generated passphrase through). Two features; both are product calls, so feel free to take one without the other.
1. Type the password twice before encrypting
The password is cleared after encrypting and is the only way back in — so a typo in it is discovered when the file is needed, months later, with no recourse. Every archiver asks twice for exactly this reason. Encrypt mode now has a Repeat the password field under the first: red while it differs, green once it matches, nothing while empty. Encrypt refuses on a mismatch ("The two passwords do not match…") and on an empty repeat ("Repeat the password in the second field…"), each with its own message, before anything is derived or written. Both fields are cleared afterwards and by Clear; decrypt mode hides the field.
Both generators fill both fields: a generated password was never typed, so there is no typo to catch — the "save this now" notice carries that weight, as before.
2. An 8-word passphrase generator, at zero cost to the file
A 32-character random string cannot be remembered or written down reliably. The page already embeds the BIP-39 list for SeedQR work, and 2048 = 2¹¹, so eleven raw bits index it with no bias (same argument My-Seed-Phrase makes). Eight words = 88 bits, readable, writable by hand, and the file grows by nothing.
Eight is deliberately not a valid mnemonic length (12/15/18/21/24), so no wallet will ever accept the result as a seed; the notice says so explicitly: "It is a password, not a wallet seed: no wallet accepts an 8-word phrase." I considered embedding the EFF list instead (as My-Passphrase does) and rejected it for +60 KB on a file whose size is a feature.
Verified
Driven in the browser: mismatch → refused, nothing encrypted; empty repeat → refused with its own message; match → encrypts, both fields cleared. Ten generated passphrases: 8 words each, all in
BIP39_INDEX, all distinct, mirrored into the repeat field, green border. Decrypt mode hides the repeat field and the Passphrase button.test:crypto91/91.