Introduction OpenSSL and LibreSSL are two popular open-source cryptographic libraries that provide essential security features for various applications and protocols. While both libraries serve a similar purpose, they differ in their origins, philosophies, and approaches to security. In this article, we will explore the history, security, and performance aspects of OpenSSL and LibreSSL, shedding light on their similarities and differences.
OpenSSL and LibreSSL History OpenSSL OpenSSL is a widely adopted and mature cryptographic library that originated in 1998 as a fork of the SSLeay library.
NIP-52 Calendar Events draft optional
This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are addressable and deletable per NIP-09 .
Unlike the term calendar event specific to this NIP, the term event is used broadly in all the NIPs to describe any Nostr event. The distinction is being made here to discern between the two terms.
Calendar Events There are two types of calendar events represented by different kinds: date-based and time-based calendar events.
NIP-89 Recommended Application Handlers draft optional
This NIP describes kind:31989 and kind:31990: a way to discover applications that can handle unknown event-kinds.
Rationale Nostr’s discoverability and transparent event interaction is one of its most interesting/novel mechanics. This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions.
Parties involved There are three actors to this workflow:
Crypto AG Introduction Crypto AG, a Swiss company founded in 1952, holds a unique place in the annals of cryptography. For several decades, it played a prominent role in supplying encryption machines to governments, militaries, and intelligence agencies around the world. However, behind its façade of secure communication, a complex web of intrigue and controversy unfolded. This article delves into the fascinating story of Crypto AG and its significant implications for global cryptography.
NIP-32 Labeling draft optional
This NIP defines two new indexable tags to label events and a new event kind (kind:1985) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.
New Tags:
L denotes a label namespace l denotes a label Label Namespace Tag An L tag can be any string, but publishers SHOULD ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation.
NIP-31 Dealing with unknown event kinds draft optional
When creating a new custom event kind that is part of a custom protocol and isn’t meant to be read as text (like kind:1), clients should use an alt tag to write a short human-readable plaintext summary of what that event is about.
The intent is that social clients, used to display only kind:1 notes, can still show something in case a custom event pops up in their timelines.
NIP-30 Custom Emoji draft optional
Custom emoji may be added to kind 0, kind 1, kind 7 (NIP-25 ) and kind 30315 (NIP-38 ) events by including one or more "emoji" tags, in the form:
["emoji", <shortcode>, <image-url>] Where:
<shortcode> is a name given for the emoji, which MUST be comprised of only alphanumeric characters and underscores. <image-url> is a URL to the corresponding image file of the emoji. For each emoji tag, clients should parse emoji shortcodes (aka “emojify”) like :shortcode: in the event to display custom emoji.
NIP-98 HTTP Auth draft optional
This NIP defines an ephemeral event used to authorize requests to HTTP servers using nostr events.
This is useful for HTTP services which are built for Nostr and deal with Nostr user accounts.
Nostr event A kind 27235 (In reference to RFC 7235 ) event is used.
The content SHOULD be empty.
The following tags MUST be included.
u - absolute URL method - HTTP Request Method Example event:
NIP-47 Nostr Wallet Connect draft optional
Rationale This NIP describes a way for clients to access a remote Lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol.
Terms client: Nostr app on any platform that wants to pay Lightning invoices. user: The person using the client, and want’s to connect their wallet app to their client.
NIP-39 External Identities in Profiles draft optional
Abstract Nostr protocol users may have other online identities such as usernames, profile pages, keypairs etc. they control and they may want to include this data in their profile metadata so clients can parse, validate and display this information.
i tag on a metadata event A new optional i tag is introduced for kind 0 metadata event defined in NIP-01 :
{ "id": <id>, "pubkey": <pubkey>, "tags": [ ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"], ["i", "twitter:semisol_public", "1619358434134196225"], ["i", "mastodon:bitcoinhackers.
NIP-51 Lists draft optional
This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be public or private.
Public items in a list are specified in the event tags array, while private items are specified in a JSON array that mimics the structure of the event tags array, but stringified and encrypted using the same scheme from NIP-04 (the shared key is computed using the author’s public and private key) and stored in the .
NIP-94 File Metadata draft optional
The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by “social” clients that deal with kind:1 notes or by longform clients that deal with kind:30023 articles.
Event format This NIP specifies the use of the 1063 event type, having in content a description of the file content, and a list of tags described below:
NIP-78 Arbitrary custom app data draft optional
The goal of this NIP is to enable remoteStorage -like capabilities for custom applications that do not care about interoperability.
Even though interoperability is great, some apps do not want or do not need interoperability, and it wouldn’t make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a “bring your own database” way, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.
NIP-58 Badges draft optional
Three special events are used to define, award and display badges in user profiles:
A “Badge Definition” event is defined as an addressable event with kind 30009 having a d tag with a value that uniquely identifies the badge (e.g. bravery) published by the badge issuer. Badge definitions can be updated.
A “Badge Award” event is a kind 8 event with a single a tag referencing a “Badge Definition” event and one or more p tags, one for each pubkey the badge issuer wishes to award.
NIP-46 Nostr Remote Signing Changes remote-signer-key is introduced, passed in bunker url, clients must differentiate between remote-signer-pubkey and user-pubkey, must call get_public_key after connect, nip05 login is removed, create_account moved to another NIP.
Rationale Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface.
This NIP describes a method for 2-way communication between a remote signer and a Nostr client.
NIP-57 Lightning Zaps draft optional
This NIP defines two new event types for recording lightning payments between users. 9734 is a zap request, representing a payer’s request to a recipient’s lightning wallet for an invoice. 9735 is a zap receipt, representing the confirmation by the recipient’s lightning wallet that the invoice issued in response to a zap request has been paid.
Having lightning receipts on nostr allows clients to display lightning payments from entities on the network.
NIP-56 Reporting optional
A report is a kind 1984 event that signals to users and relays that some referenced content is objectionable. The definition of objectionable is obviously subjective and all agents on the network (users, apps, relays, etc.) may consume and take action on them as they see fit.
The content MAY contain additional information submitted by the entity reporting the content.
Tags The report event MUST include a p tag referencing the pubkey of the user you are reporting.
NIP-23 Long-form Content draft optional
This NIP defines kind:30023 (an addressable event) for long-form text content, generally referred to as “articles” or “blog posts”. kind:30024 has the same structure as kind:30023 and is used to save long form drafts.
“Social” clients that deal primarily with kind:1 notes should not be expected to implement this NIP.
Format The .content of these events should be a string text in Markdown syntax. To maximize compatibility and readability between different clients and devices, any client that is creating long form notes:
NIP-65 Relay List Metadata draft optional
Defines a replaceable event using kind:10002 to advertise preferred relays for discovering a user’s content and receiving fresh content from others.
The event MUST include a list of r tags with relay URIs and a read or write marker. Relays marked as read / write are called READ / WRITE relays, respectively. If the marker is omitted, the relay is used for both purposes.
In today’s digital world, privacy and security are more important than ever. As the amount of sensitive information being stored and transmitted electronically continues to grow, it’s essential to have tools that can protect this information from being intercepted and misused. One such tool is GPG, an encryption program that has been at the forefront of secure communication for over 25 years. In this article, we’ll take a look at the history of GPG, from its early days as PGP to its current form as GnuPG.
Introduction Jailbreaking an iOS device involves removing the restrictions imposed by Apple and gaining root access to the underlying operating system. While jailbreaking can provide users with more freedom and customization options, it also comes with significant security risks. In this article, we will discuss the security implications of jailbreaking an iOS device and provide some recommendations for keeping your device secure.
Jailbreaking iOS Device Risks One of the main security risks associated with jailbreaking is that it exposes the device to malware and other malicious software.
In today’s digital age, the internet has become an integral part of our lives. From online shopping and banking to social media and messaging, we rely on the internet for almost every aspect of our personal and professional lives. With this increased reliance on the internet comes the need for better protection of our sensitive information. This is where end-to-end encryption comes in.
End-to-end encryption (E2EE) is a method of secure communication that protects the privacy of the message being sent.
In January 2021, a massive data leak of Twitter user information was discovered. The leak affected over 330 million Twitter users, and included sensitive information such as email addresses, phone numbers, and locations. The source of the leak was a hacker group that claimed to have gained access to Twitter’s internal systems.
The Twitter data leak is a stark reminder of the vulnerability of personal information in the digital age. With the increasing use of social media and other online platforms, our personal data is being stored in vast quantities by companies and organizations.
In recent years, Facebook has been at the center of several high-profile data breaches, which have resulted in the personal information of millions of users being exposed. These breaches have raised serious concerns about the security of personal information in the digital age and the potential dangers of sharing sensitive data on social media.
The most notable of these breaches was the Cambridge Analytica scandal in 2018, where the personal data of 87 million Facebook users was harvested and used for political advertising purposes.
In recent years, there have been several high-profile data breaches involving Google, one of the largest tech companies in the world. These breaches have raised serious concerns about the security of personal information and the potential dangers of using online services.
One of the most notable data breaches involving Google was the exposure of personal data of hundreds of thousands of Google+ users in 2018. The breach was caused by a software vulnerability, which allowed third-party developers to access sensitive information such as name, email address, occupation, and gender.
Cryptocurrency has taken the world by storm and Bitcoin is one of the most widely used virtual currencies. Despite its growing popularity, Bitcoin and other cryptocurrencies have faced several data breaches, which have raised concerns about the security of digital currencies. In this article, we’ll take a look at some of the most significant Bitcoin data breaches and the impact they have had on the cryptocurrency market.
Mt. Gox Mt. Gox was one of the largest Bitcoin exchanges in the world, handling over 70% of all Bitcoin transactions at its peak.
NIP-21 nostr: URI scheme draft optional
This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network.
The scheme is nostr:.
The identifiers that come after are expected to be the same as those defined in NIP-19 (except nsec).
Examples nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9 nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm Source: nostr-protocol/nips/21.md version: 0c1dfa9 2024-07-28T15:36:31-04:00
In 2013, Yahoo experienced one of the largest data breaches in history, resulting in the personal information of over 3 billion users being exposed. This breach was a major wake-up call for users about the dangers of sharing personal information online and the importance of online privacy.
The Yahoo data breach was caused by a state-sponsored hacker who gained access to the company’s systems and stole sensitive information such as names, email addresses, phone numbers, dates of birth, and security questions and answers.
In the world of technology, data breaches are becoming more and more common. From large corporations to small businesses, no one is safe from the prying eyes of cybercriminals. In this article, we’ll take a wild ride through some of the most famous data breaches of all time and see just how much information was stolen. Buckle up and let’s get started!
Yahoo (2013) - This massive breach affected all 3 billion of Yahoo’s user accounts.
OpenSSL and BoringSSL are two of the most widely used cryptography libraries in the world, both providing essential encryption and secure communication services to millions of websites, applications, and devices. While both libraries are widely trusted, they differ in important ways when it comes to security and performance. In this article, we’ll take a closer look at the two libraries and compare them in terms of vulnerabilities, performance, and source code.
