Subnostr

giftwraps is a word that hides the fact that what it means is it uses a one time key to send it, using NIP-4 DM encryption, and the recipient is visible in the tag but the sender is not, it is part of the content field inside the encryption

this means that clients can't see them after sending them unless they store those one time keys, and that precludes cross-device accessibility

it's only half a solution for the metadata leak problem... the whole solution requires both sides to be online, which is impractical for many reasons

an equally half solution would be for relays to ALL require NIP-42 and only give out DMs and other privileged messages to users whose key appears in the event either sender or tagged receivers or mentions

neither solve the problem that only being online simultaneously solves, and no, simplex et al don't solve this problem, they cache the messages in a middleman situation and they additionally don't have multi-device capability so actually the problem is not wholly solvable, but devs making relays are not doing anything about making what solutions CAN be made, ie, NIP-42, and on the client side, the situation is just as bad

and almost in no case can you count on having even one end of a connection actually capable of inbound connections... wireguard VPNs would solve this problem also, and could be bundled with a paid relay service to further increase privacy

you simply cannot have an async message delivery system without a middle man, and that is a privileged position that cannot be avoided without direct connection and the internet's routing setup still doesn't allow direct connections to be established from all points on the network - most users are behind routers that do not automate giving out port forwards to clients and so there has to be rendezvous services for all peer to peer systems that don't have at least one side able to listen for inbound connections

because there's not a lot we can do about this, we are stuck with the also half-solution of using Tor network, which is an absurdly low bandwidth system and just like this problem with DMs in nostr, clients that support actual p2p direct connections via hidden services basically don't exist and there used to be one called torchat but they changed the API and nobody was funding the maintenance of the project so it was abandoned

it's a big problem, and we are still stuck with trusting someone

i'd trust a nostrich and bitcoiner any day over google and amazon, and i'd trust a little data centre in the boondocks that accepts bitcoin long before i'd trust those cloud providers, and this is possible, right now

i'm not a "means to an end" kinda guy nor am i complacent about the fact that the situation is shit but there is things we can do about this, and the apathy is appalling

#whinge #devstr #security #privacy

Reply to this note

Please Login to reply.

Discussion

Parkin 1y ago

"Wow, that was a deep dive into the complexities of message encryption and privacy issues. It's definitely a challenge to find a perfect solution, but it's great to see people thinking about these important issues. Keep pushing for better solutions! #privacyconcerns #encryptionstruggles"

elsat 1y ago

Giftwrap is nip-44?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

nip-44 is just a new, overly complicated, and poorly written encryption scheme, and the reference implementation for #golang doesn't compute the HMAC properly (no idea how it passed the so called security audit)

giftwraps are not even formally specified in any ratified NIP, you can search the nips repo for the word "giftwrap" and everything is in a PR that hasn't made it into a NIP-XX.md file

if you read this: https://github.com/nostr-protocol/nips/blob/master/04.md you can see that it does not exclude the use of a one-time key, nip-44 only specifies a new encryption algorithm, which is supposed to be stronger

giftwrap is just the nostr in-word for using a one time sender key to encrypt a two layer message that inside contains the sender key encrypted with a second layer of encryption inside it

it's not formally specified, and unfortunately it doesn't seem to me there is a great deal of competence in the field of authentication and encryption security in the contributors to the NIP repo

from my knowledge of encryption, it is basically much the same, for the type of data (mostly about the volume of it) the advantage of ChaCha-20 for security has more to do with how much data it can encrypt without requiring a rekey, so if AES-GCM, for example, with a 12 byte nonce and 256 bit secret, is good for 4 gigabytes of data then obviously there is no great extra benefit for mere kilobytes of data - but long term i suppose you can say that a bigger nonce shields the secret for longer

the secrets are a static, permanent value generated by ECDH using two key pairs (priv1 | pub2 == pub1 | priv2) and as with all encryption methods there is a cleartext "nonce" which seeds the generated secret to prevent a recurrance of the cipher bit stream (or blocks)

all the talk about forward secrecy and post-breach security is irrelevant in a protocol that involves a middleman like a relay, you are stuck with trusting the relay to not share your DMs with random or potentially malicious parties, nor is there any discussion about how to effectively validate that a relay implementation and deployment are actually respecting user privacy

and it's sad that they even bother to mention "post quantum cryptography" because that is a bunk field of hype and misinformation, the simple fact is that if bitcoin mining is boiling the oceans, then quantum computers are going to boil the whole solar system, the amount of energy required to cool qbits is really that incredibly vast

jb55 1y ago

I very much agree with both of these posts, thanks for summarizing the concerns accurately

jb55 1y ago

The only other thing I would mention is that switching over to nip44 or nip44 + giftwraps now is an unnecessary hardfork of DMs and is only going to cause people to leave the protocol.

This desire to hardfork core communication functionality all the time is concerning. I already saw a thread of people getting frustrated that people aren’t getting DMs from amethyst users.

You could argue noone should use nip04 dms anyways because of metadata leakage, but replacing it nip44 doesn’t even fix that. giftwraps are complex and are not obviously the solution either.

My preferred route would have been keep nip04 for as long as possible until we have a really secure protocol extension that solves private communications in a robust way. A solution that is so obviously better and simple to implement that everyone would switch to it. Not sure if thats possible, but I would have at least liked to see ratcheting (OMEMO ?) in the v2 DM spec.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

oh yeah, ratcheting... so, as i see it, the problem is that for the most part, #nostr is a stateless protocol

all techniques of forward privacy require a state, this is easy in an interactive protocol because it is ephemeral but async state has to be stored somewhere to be available in future and on different devices independently

you need to create a secure method of securing state, and simply, application specific data can always be encrypted in each case to a different counter-key that is thrown away afterwards anyway, and in that state can be stored information about things like next-keys to use in a ratcheting protocol, even a multi user ratchet protocol like MLS the state has to be stored somewhere

jb55 1y ago

I think on-device keys is fine and inevitable. Even on signal switching to new devices will lose your comms history. Nostr wouldn’t have any issues with this.

ChipTuner 1y ago

Well, first. I will be submitting a C "reference" library for all nostr cryptography operations including nip44 to paulmillr hopefully in the next few months, that maybe they can include in the repo.

Yes I agree the nip44 spec can be quite confusing, and build heavily assuming managed runtime with extensive libraries are used. I found it difficult to translate the operations into binary and allocation free, (I would like to target hardware signers in the future)

I think I'm missing your concerns. Are you arguing mainly for the lack of privacy that encrypted messages could theoretically be distributed to whoever asks a relay nicely. Then yeah, concern for me to, but I believe that's the intention of the network at the moment. I believe you also are concerned with "metadata" regarding the nip-01 "wrapper" message containing the PM?

Finally, would have to think some more, but I would argue removing the relay portion would remove the "nostr" part altogether. I don't believe we intend to assume nostr PMs are meant to be ultimately private, but rather a reliable and ideally uncensored way to get private message content to others. I'd argue there is very little privacy in the entire nostr protocol, it's not in the design yet.

I agree nip42 is just trusting the relay. Not a good solution for end-user privacy. I want more privacy but man I can barely keep up as it is. I'm generally a low/no dependency dev, I get nervous when discussing technically complex solutions as wrappers. It allows for easy mistakes and common configuration errors. I think if we come up with a "solution" it should be part of the protocol, not relying to heavily on other "complex" oss communities. I know that sounds bad, but lately imo awesome lists are probably 60-70% abandon-ware and it's getting sad out there for oss. I've had to overhaul plenty of projects in just the past 4 years because I used a "popular" library that became abandoned. Seems way more common in front-end.