We will use BIP85 for password generation, using BASE85, which provides more entropy per character than BASE64 (defaulted to by other wallets in the space). We will default to a length of 21, but both the length and the Index will be adjustable in the Advanced Settings, and the Password filed here will be read only (for obvious reasons, but worth pointing out)
You can currently add a Password manually if you need freeform text input, but I hear you that it is not the most comfortable one for long texts or lists (we added scrolling for text fields in 1.3.0 as well). A standalone notes app is already in the backlog (SFT-2433), but is regrettably not ready for the upcoming version. We have been prioritizing the readiness of the SDK so anyone could build apps for Passport Prime (see our documentation page for developers), hoping this will yield in a wider app variety for our users. Someone might even vibecode a secure notes app before we ship a first party app for that too! Hope not, but this is an open platform where anyone can build anything, so who knows haha.
This is in fact in our short term plans! I can’t commit to any deadlines, but you should see us announcing this in a not too distant future.
Believe it or not, this is one of the reasons why we were delayed. While it’s true that we now have even non technical team members writing production code and applying fixes (this is why the KeySO 1.3.0 and Envoy 2.3.0 release notes will be so bulky), these AI tools also helped us identify a ton of underlying problems of varying urgency that needed patching and absorbed a lot of technical work time that delayed the release of both KeyOS 1.3.0 and Envoy 2.3.0. So instead of moving faster with the flashy new apps and features, we spent a lot of time making sure the underlying software is rock solid and stable.
Thank you! We are a relatively small team but are aiming high, so please bear with us while we smooth out all the rough edges =)
“We will use BIP85 for password generation, using BASE85, which provides more entropy per character than BASE64 (defaulted to by other wallets in the space)”
Please please also make sure we atleast have the option to use BASE64 so that we have the ability to restore BIP85 passwords from other vendor devices and so that the paranoid can verify they are being created the same way across vendors and be absolutely sure we don’t have to worry about vendor lock in. I want to be able to recreate the same passwords from the same seed from both Passport Prime and Coldcard at the very least before i can feel like its safe for me to rely on it for lots of passwords. If Coldcard only uses BASE64, I’d like the option to choose to generate BASE64 passwords on Passport Prime even if the default of BASE85 is superior.
As far as unique features that Passport Prime may be first to release, can we have the option to make FIDO keys using BIP85 so they can be recreated deterministically from just a seed if need be? (so you don’t have to worry about your FIDO keys being lost if for some reason you ever lose access to the data backups…would love the option of knowing i will always be able to recreate offline my FIDO key that I use to SSH into different computers as long as i have the seed…i realize that some websites won’t like if they see a reset nonce, but there are still reasons it’d be nice to be able to deterministically recreate your non-discoverable key(s))
Hey @happy our first implementation will not have BASE64. Allowing this would open the door to 99% of the users that don’t want to compare to Coldcard to create weaker passwords. OTOH, know that Coldcard allows for BASE85 generation, but you have to go into advanced settings or something, but you should be able to compare both passwords. Keep in mind the length should match for you to be able to compare both (but afaik they don’t allow varying the passwords length).
Passport’s Keys are already deterministically derived from the master seed! We don’t follow BIP85 because BIP85 does not cover security keys, so we had a custom derivation path for these:
Oh cool didn’t know Coldcard would let me switch to Base85, nice! That’s awesome, thank you…it’ll atleast be able to verify that I get the same result if the password is the same length.
"Passport’s Keys are already deterministically derived from the master seed! We don’t follow BIP85 because BIP85 does not cover security keys, so we had a custom derivation path for these:
Ah, wasn’t sure if BIP-85 was also a general protocol or ruleset that has the flexibility be applied to the creation of any type of key because it just acts as a source of initial random key material. Like if you copied and pasted that derivation path you just share into a generic BIP-85 hardware wallet device if it would be able to recreate the same outputs if using the same seed. I’m just wondering if it’s most likely that the Passport Prime will likely be the only hardware wallet type device that will ever be able to recreate these or if it’s being designed to be what’s likely to get adopted by other manufacturers? (I understand since it’s open source technically a user could find a copy of the source code and try to run it on an air gapped computer, but that’s much more difficult and not realistic for most…instead I hope other hardware wallets eventually follow whatever standard you guys go with)
You can see bip85 here. You can see it defines sections for passwords, gpg, dice… but nothing for FIDO keys, so we came up with our own.
As you mentioned, this is fully open sourced so anyone can come and implement the same way of deriving keys in their app. With LLMs we will probably see something like this coming sooner than later, just ask claude or codex to take a look at our repo and build it in your app. But yeah in any case, we invite anyone to take a look at this and implement it in their hardware wallets! The broader the implementation the better for the entire ecosystem for sure.
I can tell you that targeted QA has finished (we tested over 220 individual changes ), we have been pens down for a week and we are currently testing upgrades from 1.2.1 on production units.
Release Candidate 1 has been built, but we are regrettably finding some update issues we did not expect and we don’t want you to hit, so we are investigating them as we speak. This will of course delay us a bit, likely to next week, but we are almost there, I promise =)