Encryption Spec Requirements

Post Reply
biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Encryption Spec Requirements

Post by biolizard89 »

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?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Encryption Spec Requirements

Post by virtual_master »

biolizard89 wrote: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?
This could enhance Namecoins usability if implemented properly.

- May be it is not the best option to have all name/values encrypted.
Why not ? Some people want to use the block-explorer to advertise their business and want to have their contact details available for everybody.

- Using to much options could be confusing and counterproductive also.
Encrypting part of the value field with a deterministic encryption wouldn't be very useful also if using obvious keys for that context. Using 'email' or 'telephone' as key to encrypt the value and storing instead 'email' 'Hash(email)' wouldn't be very hard to decrypt also. :)
This wouldn't stop anybody to encrypt part of the value field with a symmetric key known only by shared partners.

- So I would suggest just two options:
  • - unencrypted
    - name hashed and registered and value encrypted with the name
This type of deterministic encryption would help for those who wish not to be collected by spammers in an easy way.
As more unpredictable will be the name as more secure the data. A reasonable protection cannot be expected by id/alex or id/joe.
However if the name is very unpredictable then this will reduce it's practical use as it will be difficult to remember id/alice3cs8fyld9.
Using for ID a combination of first name and family name would give some protection against mass collection but not for those who are knowing which person they are searching.
id/jackhunter or id/jack_hunter wouldn't be difficult to guess for those knowing the name of the targeted person.

------------

Best protection for the name/value entries would give a group based access to the encrypted value.
However this would contradict(or enhance :D ) the Namecoin definition of an open name/value database.
A reasonable solution is also not easy to be implemented.
For ex. some domains could define a group of IDs who can access to the value(containing a domain address - changed from time to time)
There must be a key transmission system to the id owners.
That could be automatically in the blockchain with a message encrypted with a public key stored in every id.
(this could be used also to send encrypted messages to name owners - as I already proposed for domain trading https://forum.namecoin.info/viewtopic.p ... 021#p13021)
No hardfork, protocol change would be necessary. Just an implementation on the client level.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Encryption Spec Requirements

Post by biolizard89 »

virtual_master wrote:This could enhance Namecoins usability if implemented properly.

- May be it is not the best option to have all name/values encrypted.
Why not ? Some people want to use the block-explorer to advertise their business and want to have their contact details available for everybody.
Right, this proposal does not encrypt all name/value data; it's completely opt-in, and you can partially opt-in for certain subsets of the data as well (e.g. you could have an id/ name where the name and your Twitter handle are public but your e-mail address and phone number are encrypted).
virtual_master wrote:- Using to much options could be confusing and counterproductive also.
Encrypting part of the value field with a deterministic encryption wouldn't be very useful also if using obvious keys for that context. Using 'email' or 'telephone' as key to encrypt the value and storing instead 'email' 'Hash(email)' wouldn't be very hard to decrypt also. :)
This wouldn't stop anybody to encrypt part of the value field with a symmetric key known only by shared partners.
I'm not sure I follow. It wouldn't be using obvious keys, the proposal is to use user-specified passphrases and/or keys. No one would be using "email" or "telephone" as a key.
virtual_master wrote:- So I would suggest just two options:
  • - unencrypted
    - name hashed and registered and value encrypted with the name
This type of deterministic encryption would help for those who wish not to be collected by spammers in an easy way.
As more unpredictable will be the name as more secure the data. A reasonable protection cannot be expected by id/alex or id/joe.
However if the name is very unpredictable then this will reduce it's practical use as it will be difficult to remember id/alice3cs8fyld9.
Using for ID a combination of first name and family name would give some protection against mass collection but not for those who are knowing which person they are searching.
id/jackhunter or id/jack_hunter wouldn't be difficult to guess for those knowing the name of the targeted person.
Right, if you're trying to hide the existence of a name itself, then you need to make it high-entropy. This is not always what users will want, so allowing value encryption using arbitrary passphrases/keys will be preferable in some cases.
virtual_master wrote:Best protection for the name/value entries would give a group based access to the encrypted value.
However this would contradict(or enhance :D ) the Namecoin definition of an open name/value database.
A reasonable solution is also not easy to be implemented.
For ex. some domains could define a group of IDs who can access to the value(containing a domain address - changed from time to time)
There must be a key transmission system to the id owners.
That could be automatically in the blockchain with a message encrypted with a public key stored in every id.
(this could be used also to send encrypted messages to name owners - as I already proposed for domain trading https://forum.namecoin.info/viewtopic.p ... 021#p13021)
No hardfork, protocol change would be necessary. Just an implementation on the client level.
Key exchange is out of the scope of this proposal.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Encryption Spec Requirements

Post by virtual_master »

biolizard89 wrote: I'm not sure I follow. It wouldn't be using obvious keys, the proposal is to use user-specified passphrases and/or keys. No one would be using "email" or "telephone" as a key.
Taking the example from the Namecoin wiki:

$ namecoind name_show "id/khal"
{
"email": "khal@dot-bit.org",
"bitcoin": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4",
"namecoin": "N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"
}

I was meaning a partial encryption for "khal@dot-bit.org" with "email" does it have little sense as it is easily predictable however if you are meaning to use the name "khal" from the "id/khal" then it have more sense but only if the name is registered as hash.
However I am not sure if it is worth the confusion even in this case.
But if the hash of the name is registered what sense does it have to leave parts of the value unencrypted.
So in the above case

$ namecoind name_show "id/hashed_value(of a name)"
{
"email": "EncryptedText",
"bitcoin": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4",
"namecoin": "N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"
}

what sense would it have ?

If the not encrypted parts of the value doesn't contain a hint to the name owner then it would be of no value to leave them unencrypted as nobody could use it.
If it contains the name owner then it is also not difficult to find out the name if elected memorable.

So this are the considerations why I consider to have practical sense only the full encrypted and the non-encrypted value versions.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Encryption Spec Requirements

Post by biolizard89 »

Roughly what I was thinking of was:

{
"enc": "fch843fhjdfgh29rjdcdfvifjer8esjcfvre9r"
"bitcoin": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4",
"namecoin": "N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"
}

Where for some secret decryption key, "fch843fhjdfgh29rjdcdfvifjer8esjcfvre9r" decrypts to:

{"email": "khal@dot-bit.org"}

If the viewer possesses the decryption key, then the email field is reconstructed and merged with the rest of the data. If not, then the email field (both existence and value) is secret.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

virtual_master
Posts: 541
Joined: Mon May 20, 2013 12:03 pm
Contact:

Re: Encryption Spec Requirements

Post by virtual_master »

biolizard89 wrote:Roughly what I was thinking of was:

{
"enc": "fch843fhjdfgh29rjdcdfvifjer8esjcfvre9r"
"bitcoin": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4",
"namecoin": "N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"
}

Where for some secret decryption key, "fch843fhjdfgh29rjdcdfvifjer8esjcfvre9r" decrypts to:

{"email": "khal@dot-bit.org"}

If the viewer possesses the decryption key, then the email field is reconstructed and merged with the rest of the data. If not, then the email field (both existence and value) is secret.
Of course having some encrypted text inside of the value field is up of the name owner. It cannot be stopped whatever he puts in. But I wouldn't consider this a separate case from the unencrypted value field.
Having supported decryption automatically with a user key by the wallet would be a separate case with a good security. But what practical application could it have at all without a key exchange ?
Users who could decrypt parts of a value field for names registered by another user as in the above example need to receive the key somehow and with that occasion they could receive the email address also(or whatever it contains).
Of course I cannot totally exclude that this type of encryption for part of the value field could have eventually an application with sense but a key distribution protocol would enhance this usability.
http://namecoinia.org/
Calendars for free to print: 2014 Calendar in JPG | 2014 Calendar in PDF Protect the Environment with Namecoin: 2014 Calendar in JPG | 2014 Calendar in PDF
BTC: 15KXVQv7UGtUoTe5VNWXT1bMz46MXuePba | NMC: NABFA31b3x7CvhKMxcipUqA3TnKsNfCC7S

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Encryption Spec Requirements

Post by biolizard89 »

virtual_master wrote:
biolizard89 wrote:Roughly what I was thinking of was:

{
"enc": "fch843fhjdfgh29rjdcdfvifjer8esjcfvre9r"
"bitcoin": "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4",
"namecoin": "N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"
}

Where for some secret decryption key, "fch843fhjdfgh29rjdcdfvifjer8esjcfvre9r" decrypts to:

{"email": "khal@dot-bit.org"}

If the viewer possesses the decryption key, then the email field is reconstructed and merged with the rest of the data. If not, then the email field (both existence and value) is secret.
Of course having some encrypted text inside of the value field is up of the name owner. It cannot be stopped whatever he puts in. But I wouldn't consider this a separate case from the unencrypted value field.
Having supported decryption automatically with a user key by the wallet would be a separate case with a good security. But what practical application could it have at all without a key exchange ?
Users who could decrypt parts of a value field for names registered by another user as in the above example need to receive the key somehow and with that occasion they could receive the email address also(or whatever it contains).
Of course I cannot totally exclude that this type of encryption for part of the value field could have eventually an application with sense but a key distribution protocol would enhance this usability.
The advantage of only having to distribute a key compared to the email address itself is that (1) when the email address updates, no additional out-of-band communication is necessary, and (2) it is verifiable that the email address is endorsed by the name owner, and (3) having it in the blockchain preserves compatibility with applications that check the blockchain, e.g. you could encrypt an IP address for a d/ name and it would still work with NMControl and FreeSpeechMe if the user has the key.

Distributing keys is an entirely separate (and orthogonal) problem that this proposal does not try to solve. But, pubkey distribution could probably be done via id/ if desired.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Encryption Spec Requirements

Post by biolizard89 »

Can we get some more review of this? Right now it's mentioned in the GSoC ideas page, and I'd like to have it vetted a bit more before we submit to Google.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

indolering
Posts: 801
Joined: Sun Aug 18, 2013 8:26 pm
os: mac

Re: Encryption Spec Requirements

Post by indolering »

I just don't understand why you want to put this into Namecoin value fields, why wouldn't you just link to your encrypted blob? Then you can have arbitrarily large encrypted payloads and we don't have to support a complex scheme directly within Namecoin software. I just don't see this as a major use case.
DNS is much more than a key->value datastore.

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: Encryption Spec Requirements

Post by biolizard89 »

indolering wrote:I just don't understand why you want to put this into Namecoin value fields, why wouldn't you just link to your encrypted blob? Then you can have arbitrarily large encrypted payloads and we don't have to support a complex scheme directly within Namecoin software. I just don't see this as a major use case.
For the same reason that other data isn't required to be linked. Lookups are faster and self-contained when embedded in the name.

It is a real use case. DNSSEC is widely criticized because it makes names enumerable. I find it hard to believe that all the people making that criticism aren't a major use case.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply