? Editing: Post:21.body Save Delete Cancel
Initial sync in progress...

Newest topics

Follow in NewsfeedFollowing
+ Start new topic
Loading...
stickied

Title

Body
^1 ^2 added ━ started by user_name
More topics

 

Follow in NewsfeedFollowing

The primary key problem

Role of the primary key in the functioning of the site

What I call the primary private key is a private key, that matches to the site address.

If the primary private key is leaked or lost, that is an emergency without solution, and the control over the site is lost forever.

For that reason, the primary key should be kept in a way as secure as possible and be used only in absolutely critical situations. In the everyday work, secondary keys should be used, so if they leaked or lost, new secondary keys can be created and signed with the primary key. Unfortunately, the commonly used ways of working with zites now are very careless about the primary key.

The current status

Here are some steps we can take for the better security at FZNC sites:

  • The moderation should be done using the moderators' own keys, not the primary key.
    Status: totally possible.
    We already do that.

  • Appointment and removal of moderators (and supermoderators) should not require the primary key.
    Status: not implemented, but looks possible.
    We need an intermediate data/content.json, that lies between the root content.json and data/users/content.json.

  • The engine updates should not require the primary key.
    Status: more investigation is required; the implementation may have some difficulties.
    All the engine files should be placed in a separate subdirectory, so that a separate content.json can be used for signing. What can be a trouble is index.html, since his name and location is fixed on the level of the ZeroNet engine. That file should probably be a simple proxy to the real entry point and have no code that can require update.

  • Changing internal site settings should not require the primary key.
    Status: not yet implemented.
    Some engines, including ZeroTalk, make use of the root content.json to save settings. Those settings should probably be moved to data/data.json and controlled by the intermediate data/content.json.

  • Changing the site metadata should not require the primary key.
    Status: currently impossible, modification of ZeroNet engine is required.
    Metadata, such as the site title and description (and maybe some other in the future) are saved in the root content.json. We do need the primary key to modify the title, displayed in the "Hello ZeroNet" UI.

Possible emergencies and their consequences

In the case of an ideal separation of tasks of the primary and secondary keys, the following situations and their consequences are possible:

Primary key Secondary key Result
okay lost The secondary key is dropped and a new one is created.
okay leaked The secondary key is dropped and a new one is created. The site is restored from a backup, if there was some damage.
lost okay The site keep working.
lost lost The site keep working, but any management and moderation is not possible.
lost leaked The site most likely be destroed; exclusive control over the address is lost.
leaked (irrelevant) The site most likely be destroed; exclusive control over the address is lost.
^3 ^4 geekless posted on Feb 01, 2019
Please sign innew comment
Sign in as...
Submit comment
You are running out of your allowed space, please contact the site's admin at unknown to raise your limit.
user_nameadded ^1 ^2
Reply
Body
quantumworldon Feb 06, 2019 ^1 ^2
Reply

geekless: Not sure, what you mean. The secondary key can sign the data in the appropriate subfolder only. It cannot be used to sign content.json of the parent folder.

Oh, Never mind.. Sorry I was thinking they were all in the same folder. Ok this is good..

geeklesson Feb 06, 2019 ^1 ^2
Reply

quantumworld: How do you keep the secondary key from overriding the primary key if there was a malicious attack from one of the parties that had the key?

Not sure, what you mean. The secondary key can sign the data in the appropriate subfolder only. It cannot be used to sign content.json of the parent folder.

quantumworldon Feb 06, 2019 ^1 ^2
Reply

How do you keep the secondary key from overriding the primary key if there was a malicious attack from one of the parties that had the key?

caryosceluson Feb 03, 2019 ^1 ^2
Reply

leaked
The site most likely be destroed; exclusive control over the address is lost.

Too lazy to write a proper 0net feature request atm, so i'll just leave a comment here for the future: it should be possible to create a "kill switch" mechanism which would disable all updates from a compromised key (technically, after a message ala "This key was compromised" was signed with a key). While this would not restore any damage already done, it would at least let users know (and hopefully even preserve the site in lucky cases)

This page is a snapshot of ZeroNet. Start your own ZeroNet for complete experience. Learn More