Encryption Spec Requirements
Posted: Sun Nov 09, 2014 6:14 am
So, this has been talked about a lot on IRC, but I figure it's good to gather all in one place:
Encryption of name/value data is useful for preventing automated scraping of data which users may not want to be entirely public. For example, I might not want my e-mail address or phone number to be available to the world, but I might still want certain people to be able to verify them as legitimate without exchanging out-of-band.
This is *not* the same proposal as the ZK-based proposal which Ryan proposed, which would require all name/value data to be hidden and would prevent enumeration of names. This is just a voluntary measure, which name owners can enable/disable freely.
There are three main use cases here: hiding part of a value, hiding an entire value, and hiding a name with its value.
I hold that hiding an entire value can be a subcase of hiding part of a value. So, this leaves 2 main new features:
===
Feature 1: an "enc" JSON field.
The "enc" JSON field has a value of encrypted data (probably base64). When a name is accessed which contains "enc" (or which imports a name that contains "enc"), NMControl will try to decrypt it with all keys/passphrases available. If none work, then NMControl asks the user for a key and/or passphrase. A key works if it produces data of the form "<Header><JSON>", where <Header> is a constant hardcoded string in NMControl, and <JSON> is a valid JSON string. <JSON> is then imported into the current context, using the same rules as "import".
This allows values to be encrypted with strong keys/passphrases, while still advertising the name and possibly other data in the value.
Feature 2: Store names as hashes.
3 new name script opcodes are introduced: Name New Hash, Name First Update Hash, and Name Update Hash. These behave the same as their existing counterparts, except that their "name" field consists of a hash of the name, and their "value" field consists of an encrypted value with a key of the unencrypted name. The internal name index is modified to compare hashes rather than unencrypted names, so it is not possible for Hash(X) and X to be two different names at the same time.
This allows names and values to be obfuscated (and possibly strongly hidden if the name is high-entropy), without needing to provide a key/passphrase other than the name itself.
No enforcement is performed to verify that a hash is in fact a hash of some known name, or that value data is in fact encrypted properly. Accessing malformed names will fail with a default client.
===
I don't have the expertise to define the spec exactly... maybe Ryan can help there?
Thoughts?
Encryption of name/value data is useful for preventing automated scraping of data which users may not want to be entirely public. For example, I might not want my e-mail address or phone number to be available to the world, but I might still want certain people to be able to verify them as legitimate without exchanging out-of-band.
This is *not* the same proposal as the ZK-based proposal which Ryan proposed, which would require all name/value data to be hidden and would prevent enumeration of names. This is just a voluntary measure, which name owners can enable/disable freely.
There are three main use cases here: hiding part of a value, hiding an entire value, and hiding a name with its value.
I hold that hiding an entire value can be a subcase of hiding part of a value. So, this leaves 2 main new features:
===
Feature 1: an "enc" JSON field.
The "enc" JSON field has a value of encrypted data (probably base64). When a name is accessed which contains "enc" (or which imports a name that contains "enc"), NMControl will try to decrypt it with all keys/passphrases available. If none work, then NMControl asks the user for a key and/or passphrase. A key works if it produces data of the form "<Header><JSON>", where <Header> is a constant hardcoded string in NMControl, and <JSON> is a valid JSON string. <JSON> is then imported into the current context, using the same rules as "import".
This allows values to be encrypted with strong keys/passphrases, while still advertising the name and possibly other data in the value.
Feature 2: Store names as hashes.
3 new name script opcodes are introduced: Name New Hash, Name First Update Hash, and Name Update Hash. These behave the same as their existing counterparts, except that their "name" field consists of a hash of the name, and their "value" field consists of an encrypted value with a key of the unencrypted name. The internal name index is modified to compare hashes rather than unencrypted names, so it is not possible for Hash(X) and X to be two different names at the same time.
This allows names and values to be obfuscated (and possibly strongly hidden if the name is high-entropy), without needing to provide a key/passphrase other than the name itself.
No enforcement is performed to verify that a hash is in fact a hash of some known name, or that value data is in fact encrypted properly. Accessing malformed names will fail with a default client.
===
I don't have the expertise to define the spec exactly... maybe Ryan can help there?
Thoughts?