Oddbean new post about login | logout I’m leaning toward this for the hashed phone number that you could optionally share on your profile so that damus could automatically find all your friends. It would really hard to build a rainbow table for this with a high argon2 security parameter. What do you think @Vitor Pamplona, @Fabian, any other mobile nostr devs ? Should we get a NIP going ? nostr:note1q8kxrrtlat9ezh6evwnqce4mhcqnt6xm5k5vn5xqwmmpeuqa0xusuzl6nc
I would be surprised if people haven’t thought of this before. We should definitely do some more research before we standardize on anything too early. This could be very sub optimal, it’s just the simplest thing that looks like it could work.
Called in some big brains for backup https://x.com/jb55/status/1772959015363915902?s=46
Will never use this. Let the legacy surveillance state die. Don't tie your keys to your phone number. nostr:nevent1qqsgxwajktcpwftkjp3cqt7h0atrye4wktl4yrxmqvxl5qc3jjre08spz3mhxue69uhhyetvv9ujuerpd46hxtnfdupzqvhpsfmr23gwhv795lgjc8uw0v44z3pe4sg2vlh08k0an3wx3cj9qvzqqqqqqynamzun
This doesn’t tie your key to your phone number
i think it technically does in a reverse search way tho but i also think that it has utility if you can find a way to do it that is vague enough in its matches to make it a requirement the user scan through a few dozen possible matches, that it isn't completely terrible ultimately if you are privacy focused you aren't gonna put such a hash on the network, it's for normies with a lower sense of the importance of privacy
This is why I’m trying to come up with a way that makes it computationally infeasible to reverse it.
unfortunately i think that's the thing, the less it leaks metadata the more candidates you are gonna turn up, which defeats the purpose but i do think, regardless, that for building DVMs able to find any kind of data that this kind of cryptography is the way to make it possible for someone with a sufficiently high entropy clue set to match it up to a highly obfuscated data point broaden your concept of how to generate the match set and balance your expectations with the idea that people who will publish such hashes are maybe putting a bullseye on their backs
Phone numbers are poop, I don't think there should be poop on our nips
Please don't do this.
Is the idea to save the hash publicly on kind0 and then search by it? Because then anyone can just copy the hash and "impersonate" phone numbers. It would be nice to add some proof that they actually control the number.
yea that is a problem :/
Sms4sats.com has an API https://image.nostr.build/56cf2a7e964729d44c8a06f14fc8686a9ed79321f2596cb206b91b5b25761d7d.png
Although signal would carry more privacy benefits, I think, than sms verification
If we rely on a service for verification we might as well do contact lookup via the purple api I think signal did something with sgx? Could have swore they solved this problem.
What if the hashed phone number is stored as an event signed with a unqiue private key? That private key is stored on the user's behaf by the app which published the event. The app or service that finds matching phone number hashes then publishes a connect request event to the phone numbers public key, signed using the requesting user's private key. The phone number user can then see the connection request, and choose to accept or deny. I've been thinking about building the general use case for this in AKA Profiles, where badges are always published using a unique private key, allowing badges to be discoverable, but not directly attributable to a user's public key without their permission.
argon2 won a security competition when research in this field was rapidly changing, and subsequently at least the several cryptographers I talked to said it wouldn't win it again if it was run again, that the original scrypt (tarsnap by perceival) was actually better. That is why I chose it for ncryptsec over argon2. Tiny tiny nitpick, either would work very well.
I’m open to the idea but I can’t think of good solutions. Maybe something along the lines of a published list of hash(own number x other number), but it doesn’t feel right having that whole list out there. Maybe there also needs to be a relay spec where you can only query for a match but not retrieve the whole list.
We should operate under assumption that the whole list can be accessed by a bad actor, since it is easy to have a relay that would collect the info or get hacked to get the list. It’s probably impossible to have something timelessly secure and accessible at the same time 🐶🐾🫡
Since we're trying to get rid of phone numbers and they’re becoming obsolete with IP calls etc. could it be also an email address or other identification string item?
The whole point is that it would be something in your phone contacts, number is most common. Email could work too. I haven’t figured out a decentralized scheme that is private enough yet though 😞
Could you do something with Hash (pubkey + phone /email) Generate new pubkey+phone private key. Sharing that private key would allow friends on nostr to see your pubkey+phone private key. Then if receiver of pubkey+phone private key can take normal pubkey+receiver contacts to see if there is a match. If that key matches any in contacts you could link?
The solution will have to piggy back off pubkeys.
How are you going to lookup people based on their number with that approach? 🐶🐾🤔
If user receives pubkey+phone private key. They can take pubkey from user + address book to generate private keys and if there is a private key match they know they are friends. It would require call it pubkeyphone private key for user A to share. If user B can take pubkey + any address in contacts, hash it and generate the same pubkeyphone private key and match it to user A they know they are friends.
(Phone number share) User A wants to share phone number. Private key of User A is generated using Npub+ phone number. User A shares that private key. User B wants to see if they are friends with anyone. User B takes friend list Npub + phone number list and hashes it (might be lots of random guessing but possible) If user B generates the same key as user A shared they know they are friends.
I think the idea was not to share but to find the npub of your friends who’s phone number you know. 🐶🐾🫡
Innit interesting that we can’t access some major services unless we have a number form a major wireless carrier. #fraud
