Overview

Introduction

The security of stored content is fundamentally an offense and defense game between the storage party, the user and the hacker; from a defensive point of view, we should assume:

• The storage party is completely reliable;

• The user's encryption key is strong enough;

• The encryption process is sufficiently secure;

How to make this assumption a reality? Before proceeding to the following discussion, we need to define three initial entropy values:

vaultName: The name used to identify the user's storage space, which requires user input; for example, you can use an impressive verse, one of your anniversaries, the ID of one of your documents, or even one of your most-used websites login name, etc.;

label: The alias used to mark each storage object, which can theoretically be any value and requires user input; such as card-secret, some-privkey, etc.;

password: The starting password value used by the user to generate the key, which needs to be provided by the user, but this value will not be used directly as the encryption key value; the real encryption key will be processed by combining the vault name, label and password. Column encryption logic operation, and randomly add salt value to the result to form the final encryption key.

vaultName and password need to be backed up by the user. If these two values ​​are forgotten, the stored content will never be available;

Each Label of the user will become an input parameter of the ratchet algorithm to assist in deriving the final key;

The storage is completely reliable

The content storage party here is a storage party in a general sense. It includes common centralized cloud storage, native disk storage, hardware wallet storage, paper storage, decentralized storage and even brain memory, etc. Similarly, we need to define reliability:

As long as the user completes the storage behavior, the original content that is indistinguishable from the stored content can be obtained at any subsequent time and place.

Therefore, it is the core requirement that it is always accessible and the content is indistinguishable;​ Based on the definition of storage reliability, in contrast to the above-mentioned numerous storage parties, there will always be more or less potential threats to reliability, which cannot reach 100%; ​

Considering that seedlist is oriented to the storage of small-volume content (even if it is encrypted, it will remain at a few hundred bytes), at present, the contract storage area of ​​Ethereum can fully meet the above reliability requirements;

Encryption Strength

Generally speaking, under the premise that the encryption algorithm is reliable, the encryption strength depends on two aspects:

1) Key length: that is, the number of bits of the common input key;

When processing the key length, length verification is required to prompt the user 
to reach a certain length;
From the point of view of the encryption process, the seedlist will make the final 
encryption key reach a reliable encryption length by adding salt value confusion;

2) The complexity of the key: that is, the input key should contain various characters as much as possible, such as Chinese and English case, numbers, characters, etc.;

The complexity of the key, the encryption process of the seedlist will add a number of 
characters based on a random algorithm by confusing the salt value to ensure the 
complexity;

The seedlist adopts slow hash delay processing in the key derivation process, and delays one key derivation to more than 1 second; it can be calculated: Calculated by 1 second, when the password&vault ame has only 6 digits and contains numbers and letters, if the password&vault name is not case sensitive, it will take 69 years to explode; if it is sensitive, it will take 1801 years to explode; [shown]

Encryption Process

The seedlist project itself, based on the three initial entropies (vaultName, label, password) defined at the beginning of this article, provides a rigorous encryption process for the community. For details, please refer to the Eencryption strategy section; this version of the encryption process is on the front end of the UI, will be reflected in the 2022 version, as follows:

At the same time, adhering to the principle of openness, any individual or organization can develop a new source code for the encryption process. Under the premise of meeting security and privacy requirements, the source code will be encouraged to be merged into the main seedlist library;

SeedList Implemented Features

1. Allocate an independent storage contract for each user;

2. Users can only operate their own storage contracts, and any actions of the storage contracts will be authenticated inside the contract;

3. The ratchet deduces the encryption key, and the key for each stored content is different;

4. The key derivation process is one-way and irreversible;

5. Double-layer encryption is performed on the storage content, the inner layer is AES encryption, and the outer layer is asymmetric encryption; the keys are derived;

6. The key derivation process, storage content and personal storage contract address have nothing to do with the current operating wallet;

7. No centralized server, pure dWeb application;