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>/.
NIP-06 Basic key derivation from mnemonic seed phrase draft optional
BIP39 is used to generate mnemonic seed words and derive a binary seed from them.
BIP32 is used to derive the path m/44'/1237'/<account>'/0/0 (according to the Nostr entry on SLIP44 ).
A basic client can simply use an account of 0 to derive a single key. For more advanced use-cases you can increment account, allowing generation of practically infinite keys from the 5-level path with hardened derivation.
Warning unrecommended: deprecated in favor of NIP-27 NIP-08 Handling Mentions final unrecommended optional
This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of text_notes.
Clients that want to allow tagged mentions they MUST show an autocomplete component or something analogous to that whenever the user starts typing a special key (for example, “@”) or presses some button to include a mention etc – or these clients can come up with other ways to unambiguously differentiate between mentions and normal text.
NIP-09 Event Deletion Request draft optional
A special event with kind 5, meaning “deletion request” is defined as having a list of one or more e or a tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a k tag for the kind of each event being requested for deletion.
The event’s content field MAY contain a text note describing the reason for the deletion request.
NIP-11 Relay Information Document draft optional
Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay’s websocket.
When a relay receives an HTTP(s) request with an Accept header of application/nostr+json to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure.
2015: Let’s Encrypt Root CA Initial Setup In 2015, Let’s Encrypt have three CA certificates:
ISRG Root X1 Certificate Let’s Encrypt Intermediate X1 CA Certificate Let’s Encrypt Intermediate X2 CA Certificate Let’s Encrypt will issue certificates to subscribers from its intermediate CAs, allowing Let’s Encrypt to keep root CA safely offline. IdenTrust will cross-sign Let’s Encrypt intermediates. This allow our end certificates to be accepted by all major browsers while Let’s Encrypt propagate its own root.
Zero Trust Architecture in Microsoft By 2020, Microsoft identified four core scenarios to achieve zero trust. These scenarios satisfy the requirements for strong identity, enrollment in device management, and device health validation. It also made way for alternative access for un-managed devices and validation for application health.
The initial scope for implementing zero trust focused on common corporate services used in the Microsoft enterprise by information workers, employees, partners, and vendors.
What is BIP-39 BIP is abbreviation of Bitcoin Improvement Proposals. See full list of at https://github.com/bitcoin/bips BIP-39 describes the implementation of a mnemonic code or mnemonic sentence – a group of easy to remember words – for the generation of deterministic wallets.
It consists of two parts: generating the mnemonic and converting it into a binary seed.
BIP-39 mnemonic phrase (a group of easy to remember words) to serve as a back up to recover your wallet and coins in the event your wallet becomes compromised, lost, or destroyed.
Introduction To gain access to enterprise resources, the traditional solution architecture is use VPN. For today’s cloud services, there is also zero trust architecture.
If you have on-premises resources, using a traditional VPN-based remote access architecture is one way of balancing remote usability with the risk of compromise.
If you have few or no on-premises services, the VPN may not required, the zero trust architecture can be very effective.
If you are designing a new network, consider following the zero trust network approach instead.
Certificate Transparency (CT) Introduction Certificate Transparency (CT) is a technology developed to improve the security and trustworthiness of digital certificates. It aims to provide a transparent and auditable way of monitoring digital certificates, enabling domain owners to detect malicious or fraudulent certificates issued for their domains. However, like any technology, Certificate Transparency has its own vulnerabilities and flaws that can be exploited by cybercriminals. In this article, we will discuss the history of Certificate Transparency vulnerability and its associated events.
A single java file to query Certificate Transparency log records and verification.
Introduction Certificate Transparency (CT) depends on independent, reliable logs because it is a distributed ecosystem. Built using Merkle trees, logs are publicly verifiable, append-only, and tamper-proof.
Logs are publicly available and monitored.
How CT works Certificates are deposited in public, transparent logs Certificate logs are append-only ledgers of certificates. Because they’re distributed and independent, anyone can query them to see what certificates have been included and when.
GDPR and CCPA Introduction The EU General Data Protection Regulation (Regulation (EU) 2016/679) (GDPR) took effect on May 25, 2018 and replaced the EU Directive and its member state implementing laws.
On June 28, 2018, California became the first U.S. state with a comprehensive consumer privacy law when it enacted the California Consumer Privacy Act of 2018 (CCPA), which becomes effective January 1, 2020, with some exceptions (Cal. Civ. Code §§ 1798.
There are 12 principles for securing devices from The EUD Security Framework 1, published in 2013, all of which must be considered when deploying a particular solution. These principles provide the basis for guidance for securing devices.
Data-in-transit protection Data should be protected as it transits from the end user device to any services the end user device uses. IPsec VPNs provide the most standards-compliant way of doing this, but TLS VPNs or per-app TLS connections can also be used.
CCPA Introduction California Consumer Privacy Act of 2018 (CCPA), which becomes effective January 1, 2020, with some exceptions (Cal. Civ. Code §§ 1798.100-1798.199). Given their comprehensiveness and broad reaches, each law may have significant impact on entities that collect and process personal data.
The CCPA grants California resident’s new rights regarding their personal information and imposes various data protection duties on certain entities conducting business in California. While it incorporates several GDPR concepts, such as the rights of access, portability, and data deletion, there are several areas where the CCPA requirements are more specific than those of the GDPR or where the GDPR goes beyond the CCPA requirements.
What Is the GDPR? The General Data Protection Regulation (GDPR) is a major law established in 2018 by the European Union (EU) to protect personal data. The law in the European Economic Area (EEA)—that’s the EU plus Iceland, Liechtenstein, and Norway—recognizes data protection as a fundamental right. The GDPR is the most comprehensive data protection law in the world, and it applies to every company that is based in the EEA and/or offers its goods or services to or monitors the behavior of individuals in the EEA.
Right To Non-Discrimination Per California Consumer Privacy Act (CCPA), Businesses cannot deny goods or services, charge you a different price, or provide a different level or quality of goods or services just because you exercised your rights under the CCPA.
However, if you refuse to provide your personal information to a business or ask it to delete or stop selling your personal information, and that personal information or sale is necessary for the business to provide you with goods or services, the business may not be able to complete that transaction.
Introduction What Is Privacy by Design? Today, privacy is not only an ethical imperative, but also a basic human right. And Privacy by Design is a way of reinforcing that human right.
Privacy by Design is the concept of building privacy into everything we do. In our interconnected world, where personal information is shared freely, privacy is more important than ever.
Inherent in the concept of Privacy by Design is the feature of Privacy by Default, which means that the strictest privacy settings should apply by default to business activities and processes, without any action required from the end user.
CRL Introduction CRLs (Certificate Revoke List) are signed data structures that contain a list of revoked certificates. The integrity and authenticity of the CRL is provided by the digital signature appended to the CRL. The signer of the CRL is typically the same entity that signed the issued certificate.
CRL is defined in RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile CRL File Format CRL encode in X509 format, CRL v2 structure as below:
OCSP Introduction The Online Certificate Status Protocol ( OCSP) is documented in the RFC 6960: X.509 Internet Public Key Infrastructure Online Certificate Status Protocol.
OCSP is a relatively simple request/response protocol useful in determining the current status of a digital certificate without requiring CRLs.
OCSP encoded in ASN.1.
OCSP Request An OCSP request contains the following data:
protocol version (currently only Version 1 is defined). service request. one or more target certificate identifier.
Everything you should know about End-to-end encryption.
What is End-to-end encryption End-to-end encryption (E2EE) is a system of communication where only the communicating users can read the messages. In principle, it prevents potential eavesdroppers – including telecom providers, Internet providers, and even the provider of the communication service – from being able to access the cryptographic keys needed to decrypt the conversation.
In many messaging systems, including email and many chat networks, messages pass through intermediaries and are stored by a third party, from which they are retrieved by the recipient.
Introduction Shadowsocks-libev is a lightweight secured SOCKS5 proxy for embedded devices and low-end boxes.
Shadowsocks-libev can run on OpenWRT routers, raspberrypi.
Simple-obfs is a simple obfuscating tool, designed as plugin server of shadowsocks. It can pretend your shadowsocks traffic as http traffic and not recognized by firewall.
This article show how to install Shadowsocks-libev and Simple-obfs on raspberrypi buster. It should also apply to all Debian Linux running on Buster.
Introduction With end to end encrypted cloud storage, file is encrypted before upload to cloud service provider. Only you hold the key to decrypt your files, even service provider can not decrypt your files.
Note: Due to natural of end to end encryption, if you lost your key, there is no way to recover and you can not decrypt your encrypted files.
Hint: If the end to end encryption service provide provide a way to restore your password, that means the service provider store your encryption key somewhere, to avoid data leak avoid those service providers.
Introduction Email encryption makes sure that your private emails can only be read by yourself and the intended recipient.
With end to end encryption, All emails are encrypted before sending and stored in encrypted format. Even email provider cannot decrypt and read your emails.
Recommended Services/Apps App Country Free Premium Open Source GDPR-compliant Clients Two Factor Ad Tutanota Germany 1GB 1GB. €12/year with custom domains, 5 alias. Yes Yes Web, Android, iOS Yes No ProtonMail Switzerland 500MB 5GB.
What is End to End Encrypted Messaging Apps End-to-end encrypted messaging apps are a category of communication platforms that employ advanced encryption techniques to ensure the privacy and security of messages exchanged between users. Unlike traditional messaging services, where messages might be stored and processed on the service provider’s servers, end-to-end encryption ensures that only the sender and intended recipient can access the content of the messages.
In this system, messages are encrypted on the sender’s device and remain encrypted as they traverse the communication channel until they are decrypted on the recipient’s device.
Free end to end encrypted notes apps.
Standard Notes Standard Notes is a free, open-source, and completely encrypted notes app.
It has Web, Mac, Windows and Linux desktop app, Android, iOS app.
100% Private.
AES-256 encryption. Your notes are encrypted and secured so only you can decrypt them. No one but you can read your notes.
Markdown format.
Free Features AES-256 encryption. No one but you can read your notes. Easy to use, open-source apps on Mac, Windows, iOS, Android, and Linux Automatic sync with no limit on data capacity Unlimited devices Web access Offline access Joplin Joplin is a free, open source note taking and to-do application, which can handle a large number of notes organised into notebooks.
VPN (Virtual Private Network) is a connection between two computers or other endpoints in which packets sent over a shared network, for example, the Internet, are automatically encrypted and decrypted by the endpoints. Although the packets are carried on a shared network, their contents are protected from unauthorized access between the endpoints. Virtual private networks are commonly used to connect branch offices to a headquarters when the cost of a physically separate communications link cannot be justified, or to allow workers to access their company network across the Internet when they are not on the premises.
NIPs NIPs stand for Nostr Implementation Possibilities.
They exist to document what may be implemented by Nostr -compatible relay and client software.
List Event Kinds Message Types Client to Relay Relay to Client Standardized Tags Criteria for acceptance of NIPs Is this repository a centralizing factor? How this repository works Breaking Changes License List NIP-01: Basic protocol flow description NIP-02: Follow List NIP-03: OpenTimestamps Attestations for Events NIP-04: Encrypted Direct Message — unrecommended: deprecated in favor of NIP-17 NIP-05: Mapping Nostr keys to DNS-based internet identifiers NIP-06: Basic key derivation from mnemonic seed phrase NIP-07: window.
