I'm currently working on a custodial multisig thing with email-based recovery and login for the normies. Would love any thoughts on the spec, especially with regard to possible security/privacy problems:
Discussion
yo hodlbod, custodial multisig for normies is spicy territory 😎 few q's off the bat:
- what's the email custody model? do you actually store the keys server-side or just email auth twofactor style? centralized kye storage = honey pot vibes
- rejection proofs for recovery? how do you stop a compromised email from instantly draining wallets?
- can users verify the multisig policy themselves? normies need simple ui but we need paranoid mode for those who want it
- any plans for nostr dm recovery as backup? email blows for privacy
cool project tho, lookin forward to see where ya take it!
would it be safe to say this is similar to keycast, but with multi-sig? or something different?
Yes, very similar to keycast, but instead of OAuth it's headless, and uses multisig to secure keys instead of trusting a backend
it seems like multi-sig would be better here. love it. thank you.
Is there a working instance of keycast I can play with? I tried with divine, but signups are turned off. One other difference is that my understanding of KMS is that it doesn't allow users to take custody of their keys, I'm not sure if that's correct though.
what is keycast?
nostr:npub1zuuajd7u3sx8xu92yav9jwxpr839cs0kc3q6t56vd5u9q033xmhsk6c2uc made it a while ago and nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 modified it for diVine
Uh, but what it *is* is a oauth frontend on key storage
a custodial signing api?
Yes, it's the new gold rush
We are running a version of keycast at login.divine.video. I don’t think custodial keys are something most nostr users would like to use. And I think it’s vital that any nostr app works with non-custodial keys. The goal is to make it easier to onboard users. Think of it as the bitcoin exchange that bridges to tradfi.
We generate a bunker url so you should be able to use the custodial key to access most nostr apps. And you can take your key and ask the service to delete it. Yeah you’d need to trust the keycast server operator to actually delete it and not use it. But this is the same thing users face in any service that uses traditional non-key based accounts.
Yeah, I'm working on something similar but also different. I'm skipping nip46 because bunker urls are unfamiliar, but I am using multisig to make it more secure. And I'm allowing the user to recover their key and login via email just in case they lose their backup. For the normies!
Protonmail has recovery by email, phone and seed phrase and iirc you can verify the code, maybe a root starting place?
いいね👍
Pretty cool. I had Frost in mind when we started working on Openbunker https://openbunker.opencollective.xyz/, and now you are looking into it. Besides privacy/security also keep UX in mind, which of course it already does as e-mail helps improving it, but still... Is it working fast?! If one of the bunkers is down, does it still work (backup bunkers?) Does the user understand the payload information compared to a simple pin and can they easily work with this cross-device?! Keep up the good work 🚀 ⚡
Good points. What stroke me is that the network delay should be made visible from the beginning together with a little friendly nag message/tooltip that if the user takes his private key down from the "cloud", and becomes a responsible nostrich, he'll save that much time on every signing.
yo Viktor here
custodial email recovery is always gonna be the weakest link - email providers love reading ur mail or gettin subpoenaed, so maybe add visual warnings about ^that^ instead of the delay time itself. normies hate feeling dumb, so frame it like "boom ur txs auto-sign in 0.3s" once they grab their keys, ya know? sweeten the sovereignty deal while hitting both UX pain points.
also lol if ur normie flow = "remember password" then multisig becomes useless - 2/3 setup with shared seeds across mail providers? gross but maybe only choice, just be upfront
otherwise spec looks cool, p2p hangs tight
Yeah, all of this is on my radar. There are still some gross parts in my design (copying a base58 encrypted blob from an email), but it's decently close. I can probably make the OTP part better.
that not using email breaks the purpose of 'us'? because if you still use an email, then the account is not really yours.
It's intended to be a stopgap for people who don't understand keys. Once they're ready, they can export their keys and go full sovereign. The email that does that is not a single point of failure, because the user provides a key to encrypt with, so your email provider can't steal your keys.
I’m also implementing third-party login — Apple, Google, or X. But in your implementation, do you need to deploy your own email server?
No, the user actually specifies one (so signers can coordinate/deduplicate emails). What is your project?
I see, but in that case it still depends on a special email service.
My project is Chuchu, and I plan to add third-party logins.
https://github.com/nsnjx/chuchu
My idea is to derive a unique private key from:
1)the unique secret obtained from third-party login, and
2)a user-provided passcode,
so that no dedicated server is needed.
So the user has to remember their passcode still? Is there a way to recover the secret from storage if they lose it? How do they sign things, is their encrypted key returned to the client to sign with? I'm interested in the details.
The passcode is optional, but strongly recommended. Without a passcode, a third-party service(apple/google) could recover your key based on the derivation rules.
Of course, you can also choose not to remember it and store the passcode in your iOS/Android device’s secure storage—then your key can be directly recovered on the same device.
Note that this is not a signing service; it’s a key recovery solution. Once recovered, the key is stored on the client, and signing is done locally on your client.
Hi, also working on this but different angle. What are you pulling from the JWT for Google?
`sub`
Gotcha. I saw below you said the passcode was optional, just wanted to make sure you were aware `sub` is global. User signs in to my app after yours, I get the same `sub`. (Apple is pairwise pseudonymous though.)
Where can I read more about your project? I don't understand passkeys very well, and I'm not sure end users will either, but they do seem like a very good solution to the key storage problem.
We're doing pure social sign in (Sign in with Google) or else SSO (sign in with your company-issued corp account), in such a way that the Nostr keypair is abstracted away entirely, so from a user perspective it's no different to signing in to anything else, you don't have to ever hear the word "key".
In the end what you get are keys that only the owner of the Google (or Auth0 or whatever) account can command, but that are essentially beyond the event horizon of an enclave (enclaves have that execution space which Passkeys, Yubikeys, etc., do not) and all this hidden away from the user. It's more for B2B settings.
If you're interested in ways that don't involve big tech then this wouldn't be very helpful I'm afraid. But if you're looking for normie-friendly compromises that do use big tech then happy to jump on a call or a chat group if there is one for such things.
Yeah, definitely interested in the normie compromise at this moment. Is the key recoverable for migration to self hosting?
Yes, but we're doing that with a smart contract, again tied to the Google (or other) sign in. So a user can pull out their key if and when they're ready, and in such a way that the key can't be intercepted by a malicious backend. There are zk proofs in the mix also. The zk and smart contract stuff is also all abstracted away for the end user, for them it's just a request and delivery. (They can look under the hood if they really want, or in our case the corporate IT team can.)
So yeah, not only Google (and Auth0, Okta, etc.) but also AWS, and also another chain for the smart contract and zkproof stuff. Guess you can say it's a mix that's highly antithetical to the OG Nostr narrative, but there are only so many ways to get to that kind of a user experience, and in the end the user can be left with their key in hand.
Sounds great to me, how are you planning to productize it? Libraries and and API?
We're doing this with frontline workers in Southeast Asia in mind. Nostr as it happens is a very good parts bin for communications tools for frontline workers (factory workers, drivers, hospitality workers, etc.) You can put together something Nostr-based that is much more attractive to the enterprise IT team than are the frontline licenses from Microsoft 365 or Google Workspace. But these are isolated, centralised deployments, not relying on any of the decentralisation aspects of Nostr, more the raw simplicity, also zaps are a good way to increase adoption (the big problem for all these companies is adoption, it's *always* adoption.)
Then it's just knocking on doors and old-fashioned B2B sales.
For a Nostr client in the wild this would be a pretty heavy technical lift, and also the question of how to cover infra costs without B2B revenue to offset (Nitro enclaves and zk-proving servers not so cheap). You can't really ask users themselves to pay to sign in with Google.
Very cool, sounds like an interesting project fueled by some very specific experience in the industry. I just followed you, and I'll let you know if I want to dive more deeply into the passkeys approach (email based is getting increasingly painful as I flesh the spec out, but I'm still going to see if I an complete it)
Sure happy to chat. Just to be clear passkeys we concluded are a dead end (as in FIDO passkeys, what you use with Touch ID, etc.). They've no execution space, and curve issues too. It's JWTs which are the auth vehicle in the world of SSO and social sign in. A lot of things get confused between JWTs, FIDO passkeys, on-device enclaves (like for iOS), cloud enclaves, chip enclaves (intel TDX), etc.
Ah that actually makes way more sense, you can do a lot with a JWT. I had read quite a while ago that passkeys weren't the way forward, but I've never done my homework on it
Yes, not the way forward IMO. Passkeys are just private keys that sign challenges from within the secure enclave on your iOS device, or from keychain, a TPM, Yubikey, even cross-platform third-party password managers. And with specific protocol scaffolding around them (WebAuthn/FIDO2).
Often when people say they’re doing something with passkeys for nostr it’s not actual passkey passkeys (not WebAuthn/FIDO2), it’s more like “passkey-inspired design". Because passkeys themselves are too limited.
I'd zap you if I could. I was just thinking about how we need more practical bridges for normies
Looks good, my main concern is if there are only a few big signers they can collude to reveal all users keys, if they are greater than threshold T, non colluding signers will not even know that keys are compromised, even the user will never know if no obvious signatures are made, and they will go on using their key as if its good, while all their private comms could be decrypted.
It's still better than relying on one server, it's just the worst case scenario I could think of.
yo, hodlbod - love the hustle, but i'm side-eyeing that email hinge lol
biggest red flag: email auth + custodial = honey pot combo platter 🍯
google/outlook can rug or leak, corcle social can subpoena, and yeah if >T/2 signers whisper it's game over for privacy.
maybe cheat & slip in optional nostr DMs as 2fa recovery instead of email? at least escape Big Tech's dragnet.
Vector does vibey group chats w/ Perfect-Forward Secrecy via MLS… no custodial middlemen, *Privacy by Principle*.
check our https://docs.vectorapp.io sometime if you ever want to prototype an uncustodial version ;)
gm djynqn, keep those cypherpunk sweatshops grindin'
Yeah, that's part of the threat model. Users could choose do do a higher threshold, like 4/5 or something, or even 3/3 and hold one shard, but that's the tradeoff.
Have you looked AT FROSTR? nostr:npub1s9etjgzjglwlaxdhsveq0qksxyh6xpdpn8ajh69ruetrug957r3qpklxzl
I have, I may steal some code from the project, but the UX design goals are very different
Hey nostr:npub1s9etjgzjglwlaxdhsveq0qksxyh6xpdpn8ajh69ruetrug957r3qpklxzl nostr:npub1gg5uy8cpqx4u8wj9yvlpwm5ht757vudmrzn8y27lwunt5f2ytlusklulq3 I'd love to get in touch to talk about how I might be able to adapt frostr to my use case. You'll probably hate it for its non-purism but I think it'll be useful to new users
一般層向けにメールベースのリカバリーとログインを備えた仕組みらしいです。これはどうでしょうか？