This is wrong, doing own research in every area prevents humanity progress and is in general dangerous. Thats why we have social systems of trust often times accompanied by a set of regulations. Yet of course every professional who dedicates their life to specific area is reassured that everyone MUST be a specialist on this area, because thinks its easy for everyone since its easy for them (like you think its easy to DYOR consuming information on internet)
- when suddenly your stomach starts to burn with pain do you DYOR or blindly trust doctors its appendicitis that must be removed immediately and believe they have experience since they work in the hospital and you donāt have to check their knowledge?
- when you want to repair your car do you DYOR on what employees do and how good and you 100% understand each part of the process or you believe reputation institute and let them do their work?
- when you buy something from supermarkets, so you DYOR that food is not poisoned, fresh and actually is what is claims to be or you used to take govt licenses for granted and forget some professionals already did research for you
There are too many areas in life that you trust somebody and donāt DYOR yet you think internet is exceptional area, well you are not alone, every professional in his area believes the same :)
By this time, many of you may have either given up on a new standard for encrypting notes to emerge, or entirely forgotten that there was one. Well, I have good news ā we've received the [audit report](https://cure53.de/audit-report_nip44-implementations.pdf) from [Cure53](https://cure53.de/) on the NIP 44 encryption spec, and the results are good! This post will be a summary of the findings, and some hints on what lies ahead.
# The results
The assets in scope for the audit can be found on Paul Miller's [NIP 44 repository](https://github.com/paulmillr/nip44). Included is the full text of the spec, as well as implementations in Typescript, Rust, and Go.
Overall, here's what Cure53 had to say:
> The Cure53 team succeeded in achieving very good coverage of the WP1-WP4 targets. All
ten findings spotted by the testers were classified as general weaknesses with limited
exploitation potential. In other words, no vulnerabilities were detected within the inspected
components.
In other words, no vulnerabilities were found, but there are things we can do to harden the implementations. Cure53 elaborates:
> The fact that Cure53 was not able to identify any exploitable vulnerabilities can be
interpreted as a positive sign in regard to the security of the NIP44 specification and
implementations. Nevertheless, even though the spotted problem can all be seen as general
weaknesses and hardening advice, they should not be ignored. It is known that weaknesses
may serve as entry points for more severe vulnerabilities in the future. Cure53 strongly
recommends swift resolution of all reported flaws.
These weaknesses and recommendations each have their own code, prefixed by "NOS-01", which is our audit number. Here's a quick summary of the individual points:
- NOS-01-001 describes a weakness related to naive secp256k1 implementations, which may accept public keys with both x and y coordinates instead of just x and a sign-bit. This can result in the compromise of a sender's private key if the sender can be tricked into encrypting a message with an invalid public key. This is known as a "twist attack". Cure53 recommends some additional test vectors to make sure that uncompressed keys are not accepted.
- NOS-01-002 includes a handful of minor recommendations, including specifying the initial counter for ChaCha20, nailing down key formats, and a few other things which they go into more depth on elsewhere.
- NOS-01-003 provides some additional test vectors to prevent twist attacks and out of bound errors.
- NOS-01-004 suggests using a constant time equality function to prevent timing side-channel attacks, along with some code samples.
- NOS-01-005 identifies missing range checks in the Go implementation which should be addressed in order to avoid crashes.
- NOS-01-006 addresses the lack of provisions for forward secrecy in the NIP 44 spec. They suggest introducing sender-side forward secrecy by deriving the session key using ephemeral keys and a KDF.
- NOS-01-007 explains that using the same key for multiple purposes can lead to unexpected compromises when taken together. Best practice is to use a different key for signing and for encryption, which nostr violates. While the particular curves we use aren't vulnerable to this exploit, Cure53 recommends deriving an encryption key from a user's main key using a KDF in order to reduce the impact of a leaked encryption key.
- NOS-01-008 identifies an incorrect use of the salt parameter in calls to HKDF (an HMAC-based Key Derivation Function allows us to prove that an encrypted payload was not forged). Currently, the salt is generated randomly every time, but the security definition of HKDF specifies that it be static. This is likely not exploitable, but should be fixed. Cure53 suggests switching the nonce and salt when calling the HKDF, and deriving a static salt using something like `SHA256(pubA, pubB, "nip-44-v2")`.
- NOS-01-009 demonstrates that the Message Authentication Code (MAC) tag is currently computed without a nonce. This doesn't compromise the encryption, and authentication is covered by event signatures as specified in NIP 01, but it does prevent the MAC from being useful on its own.
- NOS-01-010 suggests using clearer boundaries when constructing the HMAC payload.
The takeaway here is that with a few minor changes, the spec itself is sufficient to "provide a simple way for the users to communicate privately". There are, however, a number of edge cases which can compromise implementations, so for any developers out there porting the spec to new languages, be sure to take a look at Paul's test vectors.
> In the end, the NIP44 specification and implementations appear to have already achieved the security goal of providing users with a way to communicate privately. Miscellaneous issues identified by Cure53 during NOS-01 correspond to further hardening of the current version and/or suggestions for future versions. Following these suggestions could provide more advanced security guarantees.
They also clarify that:
> Importantly, the lack of certain security guarantees, such as forward secrecy, post-compromise security, deniability, and post-quantum, had been known to the development team prior to NOS-01.
Since this is the case, it's important that client developers be absolutely clear with their users about what NIP 44 is good for, and what it's not. This is a "simple" way to communicate privately ā users with more advanced privacy requirements should use something like MLS or SimpleX.
# What's next?
NIP 44 isn't quite ready for widespread use just yet, but it shouldn't take long to incorporate all the adjustments mentioned in the audit. Then there are several NIPs which rely on the encryption in NIP 04 which should eventually be migrated individually. Beyond that, a whole world of affordances for encrypted data becomes available on nostr.
First and most anticipated, we can finally deprecate NIP 04 and stop leaking DM metadata. Vitor's [Sealed Gift Wraps](https://github.com/nostr-protocol/nips/pull/686) are an excellent alternative to NIP 04 DMs, and add support for small group chats, which will be a big improvement to client UX.
Other more ambitious specifications targeting larger groups exist as well, including my [Closed Communities](https://github.com/nostr-protocol/nips/pull/875) draft spec. This NIP makes it possible to extend NIP 72 communities with a private component, which can be useful for publishers or real-life communities.
There are lots of other things NIP 44 might be used for as well, for example:
- The ability to share your location only with certain people
- Private calendar events, product listings, or streams
- Private tags ā instead of encrypting an entire event, it should be possible to encrypt only a single tag's value. This allows senders to attach private data to public events.
# Conclusion
There's lots of work still to be done, but I think this marks a huge milestone for nostr. So thank you to Paul Miller for his work on the spec and the audit, and to OpenSats for funding the audit!
Thanks Paul :)
I never believed in saying āif a person is genius in one, he is a genius in everythingā
But getting older I start believing in āif a person is load and stupid in one, he is stupid in everythingā
Totally agree that nostr is a 90% a social challenge rather than technical.
And one way to solve it is for people to change their views and expectations on social networks
However, I personally think their is another solution - keep things as close as possible to what they are right now in order to avoid having to change people minds and just do what we have now but slightly better and a bit differently
I think changing people minds is impossible but making nostr look more like a standard social network is not a popular opinion here :)
So whats your expectations then? Doesnāt sound too positive, does it?
I only see hopium that everything will just work because good enthusiasts would implement best client software once for free that doesnāt require operational costs and design the network in the way that it only requires couple of thousands of very cheap relays (5-100$ a month) to operate relays which were already implanted. And in this way relay operational costs would be cover by the same enthusiasts running tor relays or lightning nodes
I donāt think its viable and I canāt imagine any system in social network (in terms of what a regular user expects from the term āsocial networkā today) that doesnāt mostly exist off of ads
Do you expect every regular non technical user to pay some fee for using a social network? Like twitter is trying to achieve and fails?
What other options do you see to keep clients developing and relays at least operating?
Yeah, its complex indeed and I donāt even see yet all the necessary features. Finishing core logic soon and gonna start UI, maybe it would be better for you to think about it once PoC ready
Yeah, thats for advanced companies/services Iād say. The idea is:
1) deploy this service (relaynet) and granularly decide which events from which events you want to save to which destination (all using UI, no code)
2) next create your services that will sort those events somehow (say, AI/ML processing or group by pubkey), thats outside of what Iām doing, at least some code should be developed here
3) when you have different sets of events you want to store on different relays, deploy saltivka relay which will soon have subrelays feature and upload your events to desired once using its API
The easiest example if you want to grab events from 3 relays, split them by languages using AI/ML and deliver to different relays say en.saltivka.org, es.saltivka.org etc
So there are basically 2 most important use cases:
1) being able to monitor relays on the network you are interested from zero upto entire network bringing functionality similar to nostr.watch
2) collect and deduplicate events and stream them to destination of your choice, say database of kafka etc
Imagine a tool that lets you add a relay. You then setup different settings for that relay i.e default filters, should it get latest events, should it scan for past events? Should it scan for past events once again once all already scanned, should it provide auth by default or by some ruleā¦. And many more
Once you check that relay as active it begins to process all events from this relay. This tool ensures every event will only be processed ones. When processed - it populates internal database with relays found in event (say kind 10002 from nip65, p tags, e tags etc), which by default are inactive but you can make them be active as soon as they added
This tool also lets you monitor reconnects, errors, logs etc #relaynet
How is it counted? For instance, when I need to test something in a new cliebt I click āsignup skip skipā and get a new user. Ive prolly got like thousand of these - do they all count?
š·nostr.wine now supports NIP-50 Search!
filter.nostr.wine has offered NIP-50 for 6 months now and our main relay was starting to fell left out.
We also offer search via our free web API. Learn more here: https://docs.nostr.wine/api/search
Do I understand correctly that this is an HTTP API with search capabilities and not nostr native websocket NIP-50 compatible with NIP-01 filters?
Thanks for very detailed explanation, but I still donāt see the answer to my simple question. I can rephrase: ādo you want the majority of population to use nostr or do you only want people with the same vision as yours?ā
Is this a question you refuse to answer?
In case you want to answer, I can follow it up with next question to make it clear why Iām asking: āif it happens you want everyone to use nostr, then do you want to adapt nostr to their needs or make them change their world views to embrace new nostreality?ā
And lastly, if you want to also answer this one too and you are also realist as I am and donāt believe that you can change minds of billions of people then the question is āhow we all build tools for others to build their own social networks with bans and whores in order to attract billions of people and keep those networks interoperability?ā
P.S. it doesnāt matter at all how everyone understands āwhat nostr isā: is it a new protocol, a protocol over websockets, http or tcp, does it include nips other than nip1ā¦ the ONLY thing matters - is what community WANTS it to be and in what direction it builds it.
As an example, see ābitcoinā, āethereumā
and ācryptocurrencyā ā definitions which often times used interchangeably and there are a lot of debates on what is what. But the communities visions are what actually make them different. Ver/Write also believed their definitions of bitcoin were true at sole point. Doesnāt matter at all. Community and vision. What is your vision?
I still donāt see what you are debating against since Iāve asked you a core question to this and you hwve refused to answer.
But I can do it again. Do you want to build nostr to be worldwide social network for everyone or do you want it to be another niche tool for āfree speech absolutistsā?
Iāll just leave it here and consider that the problem is in my understanding of english. Sorry, wasnāt going to hurt your feelings 
It seems to me like you want to check initial post or this convo and see that nostr:npub1qqqqqqyz0la2jjl752yv8h7wgs3v098mh9nztd4nr6gynaef6uqqt0n47m is against providing users with freedoms to block, mute, ban, moderate etc
Yeap, Iām pretty new, only since 1997 so yeah I have much homework to do, thanks for patience
You can stop genocide promotion on internet. Not make it disappear to the extent that it doesnāt exist at all, but stop it so that it makes almost no real impact. That is how todays social media work.
Unfortunately along with stopping genocide on internet (and other bad stuff) they also block a lot of good content/people because they only care about their interests, along with stopping inappropriate
Ans if you are not satisfied with those things (you probably are if you are on nostr) ultimately you have 2 ways:
1) try to do it differently hence better
2) assume its better to do nothing than doing something imperfectly
Point 2) is childish, naive and amateur. I would be very glad if it would work, but I am realist. Iām here for 1)