The most famous OpenSSL vulnerabilities OpenSSL is a widely used open-source cryptography library that provides secure communication for many websites and applications. Despite its widespread use, OpenSSL has suffered from a number of critical vulnerabilities over the years, exposing sensitive information and putting the security of millions of users at risk. In this article, we’ll take a look at some of the most famous OpenSSL vulnerabilities.
Heartbleed (2014) - One of the most famous OpenSSL vulnerabilities of all time, Heartbleed allowed attackers to steal sensitive information, including passwords and encryption keys, from memory.
The most famous BoringSSL vulnerabilities BoringSSL is a fork of OpenSSL, created by Google, that aims to provide a more secure and performant cryptography library. Despite its focus on security, BoringSSL has suffered from a number of critical vulnerabilities over the years, exposing sensitive information and putting the security of millions of users at risk. In this article, we’ll take a look at some of the most famous BoringSSL vulnerabilities.
WhatsApp is a popular cross-platform instant messaging app that has over two billion monthly active users. It is known for its end-to-end encryption, which promises to protect the privacy of users’ messages and calls. However, the security of WhatsApp has been called into question after several data breaches have been reported in recent years.
One of the most significant data breaches involving WhatsApp occurred in May 2019, when it was revealed that spyware was used to infiltrate the phones of human rights activists and journalists.
NIP-50 Search Capability draft optional
Abstract Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. Specifics of the search algorithms will differ between event kinds, this NIP only describes a general extensible framework for performing such queries.
search filter field A new search field is introduced for REQ messages from clients:
{ // other fields on filter object... "search": <string> } search field is a string describing a query in a human-readable form, i.
Apple is known for its strong commitment to privacy and security, with the company often highlighting these features as a selling point for its products. Despite this reputation, there have been several high-profile data breaches involving Apple over the years. In this article, we’ll take a look at some of the most well-known data breaches affecting Apple, what information was leaked, and what you can do to protect your privacy.
NIP-33 Parameterized Replaceable Events final mandatory
Renamed to “Addressable events” and moved to NIP-01 .
Source: nostr-protocol/nips/33.md version: ca3c52e 2024-08-20T12:56:05-03:00
NIP-45 Event Counts draft optional
Relays may support the verb COUNT, which provides a mechanism for obtaining event counts.
Motivation Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey only to count them. The result may be cached, either by a client or by a separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr.
NIP-18 Reposts draft optional
A repost is a kind 6 event that is used to signal to followers that a kind 1 text note is worth reading.
The content of a repost event is the stringified JSON of the reposted note. It MAY also be empty, but that is not recommended.
The repost event MUST include an e tag with the id of the note that is being reposted. That tag MUST include a relay URL as its third entry to indicate where it can be fetched.
NIP-42 Authentication of clients to relays draft optional
This NIP defines a way for clients to authenticate to relays by signing an ephemeral event.
Motivation A relay may want to require clients to authenticate to access restricted resources. For example,
A relay may request payment or other forms of whitelisting to publish events – this can naïvely be achieved by limiting publication to events signed by the whitelisted key, but with this NIP they may choose to accept any events as long as they are published from an authenticated user; A relay may limit access to kind: 4 DMs to only the parties involved in the chat exchange, and for that it may require authentication before clients can query for that kind.
NIP-19 bech32-encoded entities draft optional
This NIP standardizes bech32-formatted strings that can be used to display keys, ids and other information in clients. These formats are not meant to be used anywhere in the core protocol, they are only meant for displaying to users, copy-pasting, sharing, rendering QR codes and inputting data.
It is recommended that ids and keys are stored in either hex or binary format, since these formats are closer to what must actually be used the core protocol.
NIP-40 Expiration Timestamp draft optional
The expiration tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays.
Spec tag: expiration values: - [UNIX timestamp in seconds]: required Example { "pubkey": "<pub-key>", "created_at": 1000000000, "kind": 1, "tags": [ ["expiration", "1600000000"] ], "content": "This message will expire at the specified timestamp and be deleted by relays.\n", "id": "<event-id>" } Note: The timestamp should be in the same format as the created_at timestamp and should be interpreted as the time at which the message should be deleted by relays.
NIP-36 Sensitive Content / Content Warning draft optional
The content-warning tag enables users to specify if the event’s content needs to be approved by readers to be shown. Clients can hide the content until the user acts on it.
l and L tags MAY be also be used as defined in NIP-32 with the content-warning or other namespace to support further qualification and querying.
Spec tag: content-warning options: - [reason]: optional Example { "pubkey": "<pub-key>", "created_at": 1000000000, "kind": 1, "tags": [ ["t", "hastag"], ["L", "content-warning"], ["l", "reason", "content-warning"], ["L", "social.
NIP-35 Torrents draft optional
This NIP defined a new kind 2003 which is a Torrent.
kind 2003 is a simple torrent index where there is enough information to search for content and construct the magnet link. No torrent files exist on nostr.
Tags x: V1 BitTorrent Info Hash, as seen in the magnet link magnet:?xt=urn:btih:HASH file: A file entry inside the torrent, including the full path ie. info/example.txt tracker: (Optional) A tracker to use for this torrent In order to make torrents searchable by general category, you SHOULD include a few tags like movie, tv, HD, UHD etc.
NIP-28 Public Chat draft optional
This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.
It reserves five event kinds (40-44) for immediate use:
40 - channel create 41 - channel metadata 42 - channel message 43 - hide message 44 - mute user Client-centric moderation gives client developers discretion over what types of content they want included in their apps, while imposing no additional requirements on relays.
NIP-27 Text Note References draft optional
This document standardizes the treatment given by clients of inline references of other events and profiles inside the .content of any event that has readable text in its .content (such as kinds 1 and 30023).
When creating an event, clients should include mentions to other profiles and to other events in the middle of the .content using NIP-21 codes, such as nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg.
Including NIP-10 -style tags (["e", <hex-id>, <relay-url>, <marker>]) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.
NIP-26 Delegated Event Signing draft optional
This NIP defines how events can be delegated so that they can be signed by other keypairs.
Another application of this proposal is to abstract away the use of the ‘root’ keypairs when interacting with clients. For example, a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root pubkey, where the root keypair is stored in cold storage.
NIP-25 Reactions draft optional
A reaction is a kind 7 event that is used to react to other events.
The generic reaction, represented by the content set to a + string, SHOULD be interpreted as a “like” or “upvote”.
A reaction with content set to - SHOULD be interpreted as a “dislike” or “downvote”. It SHOULD NOT be counted as a “like”, and MAY be displayed as a downvote or dislike on a post.
NIP-22 Comment draft optional
A comment is a threading note always scoped to a root event or an I-tag.
It uses kind:1111 with plaintext .content (no HTML, Markdown, or other formatting).
Comments MUST point to the root scope using uppercase tag names (e.g. K, E, A or I) and MUST point to the parent item with lowercase ones (e.g. k, e, a or i).
{ kind: 1111, content: '<comment>', tags: [ // root scope: event addresses, event ids, or I-tags.
NIP-15 Nostr Marketplace draft optional
Based on Diagon-Alley .
Implemented in NostrMarket and Plebeian Market .
Terms merchant - seller of products with NOSTR key-pair customer - buyer of products with NOSTR key-pair product - item for sale by the merchant stall - list of products controlled by merchant (a merchant can have multiple stalls) marketplace - clientside software for searching stalls and purchasing products Nostr Marketplace Clients Merchant admin Where the merchant creates, updates and deletes stalls and products, as well as where they manage sales, payments and communication with customers.
NIP-14 Subject tag in Text events draft optional
This NIP defines the use of the “subject” tag in text (kind: 1) events. (implemented in more-speech)
["subject": <string>] Browsers often display threaded lists of messages. The contents of the subject tag can be used in such lists, instead of the more ad hoc approach of using the first few words of the message. This is very similar to the way email browsers display lists of incoming emails by subject rather than by contents.
NIP-07 window.nostr capability for web browsers draft optional
The window.nostr object may be made available by web browsers or extensions and websites or web-apps may make use of it after checking its availability.
That object must define the following methods:
async window.nostr.getPublicKey(): string // returns a public key as hex async window.nostr.signEvent(event: { created_at: number, kind: number, tags: string[][], content: string }): Event // takes an event object, adds `id`, `pubkey` and `sig` and returns it Aside from these two basic above, the following functions can also be implemented optionally:
NIP-13 Proof of Work draft optional
This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence.
difficulty is defined to be the number of leading zero bits in the NIP-01 id.
NIP-10 On “e” and “p” tags in Text Events (kind 1) draft optional
Abstract This NIP describes how to use “e” and “p” tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event.
Marked “e” tags (PREFERRED) ["e", <event-id>, <relay-url>, <marker>, <pubkey>]
Where:
<event-id> is the id of the event being referenced. <relay-url> is the URL of a recommended relay associated with the reference.
NIP-01 Basic protocol flow description draft mandatory
This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here.
Events and signatures Each user has a keypair. Signatures, public key, and encodings are done according to the Schnorr signatures standard for the curve secp256k1 .
The only object type that exists is the event, which has the following format on the wire:
NIP-02 Follow List final optional
A special event with kind 3, meaning “follow list” is defined as having a list of p tags, one for each of the followed/known profiles one is following.
Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or “petname”) for that profile (can also be set to an empty string or not provided), i.
NIP-03 OpenTimestamps Attestations for Events draft optional
This NIP defines an event with kind:1040 that can contain an OpenTimestamps proof for any other event:
{ "kind": 1040 "tags": [ ["e", <event-id>, <relay-url>], ["alt", "opentimestamps attestation"] ], "content": <base64-encoded OTS file data> } The OpenTimestamps proof MUST prove the referenced e event id as its digest. The content MUST be the full content of an .ots file containing at least one Bitcoin attestation.
Warning unrecommended: deprecated in favor of NIP-17 NIP-04 Encrypted Direct Message final unrecommended optional
A special event with kind 4, meaning “encrypted direct message”. It is supposed to have the following attributes:
content MUST be equal to the base64-encoded, aes-256-cbc encrypted string of anything a user wants to write, encrypted using a shared cipher generated by combining the recipient’s public-key with the sender’s private-key; this appended by the base64-encoded initialization vector as if it was a querystring parameter named “iv”.
NIP-05 Mapping Nostr keys to DNS-based internet identifiers final optional
On events of kind 0 (user metadata) one can specify the key "nip05" with an internet identifier (an email-like address) as the value. Although there is a link to a very liberal “internet identifier” specification above, NIP-05 assumes the <local-part> part will be restricted to the characters a-z0-9-_., case-insensitive.
Upon seeing that, the client splits the identifier into <local-part> and <domain> and use these values to make a GET request to https://<domain>/.
