Subnostr

Giftwrap is nip-44?

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

Reply to this note

Please Login to reply.

Discussion

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.