From 521e2626db24b794eb55f4434c2f4fb34856eafb Mon Sep 17 00:00:00 2001 From: shafemtol Date: Mon, 27 Feb 2023 22:21:28 +0000 Subject: [PATCH 1/2] Add NIP-93: Secret Events --- 93.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) create mode 100644 93.md diff --git a/93.md b/93.md new file mode 100644 index 0000000000..e06d98d897 --- /dev/null +++ b/93.md @@ -0,0 +1,46 @@ +NIP-93 +====== + +Secret Events +------------- +`draft` `optional` `author:shafemtol` + +A secret event is an event with encrypted contents and no distinguishable +metadata apart from its `kind`, `created_at` value and the length of its +contents. Its `pubkey` is a unique key not used on any other event. + +A stored secret event has kind `9993`, while an ephemeral secret event has kind +`29993`. + +`content` MUST be the base64 encoded string of the ciphertext with no added +whitespace. The raw ciphertext MUST be indistinguishable from random binary data +to anyone except those who have the secret to decrypt it. The length of the raw +ciphertext MUST be on the form `5n * 2**k`, where `n` is in `(12,14,16,18,21)` +and `k` is a non-negative integer. Equivalently, the length of the `content` +string MUST be on the form `8n * 2**k`, with no base64 padding. + +`tags` SHOULD be an empty list. + +`created_at` SHOULD be generated independently of any timestamp within the +encrypted data. + +A relay MAY explicitly indicate support for this NIP as per `NIP-11`. If it +does, it SHOULD check for and reject secret events that do not meet the +requirements given in this NIP. In particular, it SHOULD reject secret events +where `pubkey` is known to be already associated with another event, where +`content` is not a base64-encoded string with a valid length, or where `tags` is +not empty. + + +Rationale +--------- + +The purpose of secret events is to enable storage and delivery of secrets with +minimal public metadata. Applications include secure messaging and storage of +private notes and settings. + +Restricting content length to a small set of allowed values limits the leakage +of information about message size. The parameters are chosen such that for sizes +down to 52 bytes, the maximum overhead is 16.7% and the average overhead is +7.5%. By making the length a multiple of 5 bytes, no characters in the base64 +encoding are wasted on base64 padding. From 85b6bd5e9f83ae2e78249469830d2d43e05554c6 Mon Sep 17 00:00:00 2001 From: shafemtol Date: Sun, 5 Mar 2023 21:49:06 +0000 Subject: [PATCH 2/2] NIP-93: Fix byte length calculations Previous calculations assumed base-32 encoding rather than base-64. --- 93.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/93.md b/93.md index e06d98d897..fe8fd3edcc 100644 --- a/93.md +++ b/93.md @@ -15,9 +15,9 @@ A stored secret event has kind `9993`, while an ephemeral secret event has kind `content` MUST be the base64 encoded string of the ciphertext with no added whitespace. The raw ciphertext MUST be indistinguishable from random binary data to anyone except those who have the secret to decrypt it. The length of the raw -ciphertext MUST be on the form `5n * 2**k`, where `n` is in `(12,14,16,18,21)` +ciphertext MUST be on the form `3n * 2**k`, where `n` is in `(12,14,16,18,21)` and `k` is a non-negative integer. Equivalently, the length of the `content` -string MUST be on the form `8n * 2**k`, with no base64 padding. +string MUST be on the form `4n * 2**k`, with no base64 padding. `tags` SHOULD be an empty list. @@ -41,6 +41,6 @@ private notes and settings. Restricting content length to a small set of allowed values limits the leakage of information about message size. The parameters are chosen such that for sizes -down to 52 bytes, the maximum overhead is 16.7% and the average overhead is -7.5%. By making the length a multiple of 5 bytes, no characters in the base64 +down to 31 bytes, the maximum overhead is 16.7% and the average overhead is +7.5%. By making the length a multiple of 3 bytes, no characters in the base64 encoding are wasted on base64 padding.