safe · encrypted channels ... communication is hopelessly out of date. it is based on the minimum...

SAFE.ADEnd-To-End Encrypted Email & File Storage

https://safe.ad/ico

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Problems of modern e-mail systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Our solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Token economics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Tokens distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Cryptographic methods we use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Encrypted channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Invites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Blockchain and decentralization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Authenticity of the recipient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Authenticity of the sender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Business card and new asymmetric RSA keys . . . . . . . . . . . . . . . . . . . . . . . 20

Password change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Three stages of message authenticity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Grouping emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Automatic sorting of incoming messages . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Two-level search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Sending to external addresses in encrypted format . . . . . . . . . . . . . . . . . . . 26

File storage module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Competition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Volume of the business email market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Risk factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Legal notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

TABLE OF CONTENTS

Safe.ad а Decentralized Mail Service аnd Cloud Storage with End-To-End Encryption 03

ABSTRACT

Email is a traditional method of communicating on the internet. The earliest version of email was created in 1971, and it has practically not changed since then. Although modern email systems handle their core task of communication between people perfectly well, its standards fail to take into account the security of the correspondence and the personal data of its participants.

All popular providers deliver mails to their servers via an encrypted transport channel but store everything on servers which can be accessed by administrators, algorithms that scan messages to display advertising, and hackers. The situation is the same with cloud data storage providers. For the sake of convenience, users all over the world upload personal photos and sensitive documents to cloud storage with risk of exposure.

PGP, one of the well-known encryption algorithms have some disadvantages. First, they require installing additional software. Second, the open keys may be compromised during exchange. Third, the package-oriented structure of PGP makes data streaming somewhat complicated.

From our point of view, the ideal electronic correspondence system must have the following requirements to meet today’s challenging needs for security:

1. Decentralized (Without any central authority / management like Blockchain);

2. Self-manageable (manages itself without the need for central authority /management);

3. Self-reliant (Rely on itself using advance algorithm)

Modern secure encryption algorithms support the devices you are using today which are equipped with processing power to use on-fly encryption. We deploy blockchain technology into our solutions, which will allow us to enable user identification for creating a secured distributed, autonomous and self-regulating system that will enable you to access your email anytime and anywhere.

Unfortunately, there are no products possess any of those requirements. We implement the requirements into a working product which has been adopted and in use by thousands of users. Please refer to “Our Solutions” section, for the list of functionalities that has been implemented as well as new features to be planned for.

Several teams who have entered the market with their next generation email systems do not have the solutions which are secured enough to protect your information. Nor do these systems offer other useful functionalities that do not compromise security.

https://safe.ad/ico


The modern standards of email communication is hopelessly out of date. It is based on the minimum set of necessary functions and tools required for delivering text messages and attachments between several parties. During transportation of these information they are highly susceptible to hijack for hackers lying in wait. There is no guarantee that the content of your messages won’t be distorted or replaced before reaching the recipient. The maximum size of the message with attached files is on average limited to 20–25 Mb and remarkably. This limitation has existed for the last 30 years!

Email service providers had introduced SSL as the only tool for protecting information at the transport level. However, as the central authority of their servers, data stored with them is only as secured as their company policies and Administrators.

User information has become a source of revenue for all free email providers that bring them Billions of Dollars thru ads promoted. Existing solutions involves using third-party libraries and components that would serve as an intermediary layer to encrypt messages on the sender’s device and decrypt it on the recipient’s device.

Data stored in email service providers’ server are not encrypted, for the purpose for data mining words so to analyze their contents. Algorithms are deployed to harvest contents of your emails / information to serve targeted ads related to the email messages you have sent or received. Email service providers does not charge you for free email services, but actually profits from serving you advertisements from their advertisers. Fraudulent employees or state security services can use your private data to their advantage.

PROBLEMS OF MODERN EMAIL SYSTEMS

https://safe.ad/ico


Have you ever wondered if you are exchanging emails with someone who is not who they say they are? Did you ever get a call from a friend who wishes to clarify with you on an email message you have never sent? And Vice-Versa? If the previous email was sent and read by the person to whom you sent it, the next one may be intercepted and read by someone else. Furthermore, the response may not even come from the same person to whom the original message was meant to be sent. This existing authentication method, DKIM, can detect forged messages from a different domain name, but not from specific address. Also, the validity of a public key used to verify the DKIM signature depends entirely on the goodwill of the owner of the sender domain. There is no guarantee it’s authentic. Modern email lacks tools for establishing the authenticity of correspondents.

We rely on large corporations to provide email services to us. If their data centre fails, if there are problems with global network infrastructure between countries, or if the email service provider blocks your email account, you will lose all your messages and won’t be able to use your address for mail exchange in the future. Centralized architecture does not imply a high level of personal data safety and security and is subject to various risks.

Among the small number of projects devoted to email security, none of them offers basic needs of other functionality for their users. Moreover, minimum packages can start from $45 per year. Existing offers on the secured-mail services have inflated prices.

Businesses have switched to secure messengers for quick and hassle-free communications. These messengers lack the tools to work with files, as well as the limit of size for the files to be uploaded. Cloud Servers that stores these files does not cover end-to-end security, anyone within the messaging group may have possessed security gaps in their current devices without their knowledge. The files are as secured as the weakest link*.

*Go to https://haveibeenpwned.com/ to check how your email addresses have been compromised that you never knew.

https://safe.ad/ico

https://haveibeenpwned.com/


OUR SOLUTION

The next generation email system we are creating will meet the following requirements:

1. Compatible with existing mail protocols;

2. Decentralization – more than one data centre for storage;

3. Public keys and identification data of users are stored in blockchain and therefore cannot be masqueraded or compromised. Recipient identification is guaranteed, and public keys cannot be modified by any third parties;

4. All data stored and delivered is fully encrypted, which includes metadata, headers, and attached files;

5. No size limit for messages or attach files;

6. No additional software required, works in any browser including browsers from mobile devices. Mobile Apps are optional but improves mobility experience;

7. The cryptographic architecture is optimized for data streaming as well as other types of applications, such as group calls, video-conferences, and many more;

8. Public API providing access to user’s keys which allows creation of third-party applications on the architecture and integrates existing systems into a new platform;

9. Our solution is several times more affordable than existing commercial applications (starting at $1 per month), including a long period of free use for new customers;

10. Spam protection is implemented at the system architecture level;

Our software is open-source and the code can be verified and modified by the community. Our revolutionary system provides both essential and value-added functionalities at better performance when compared to existing email platforms.

WE ARE DEVELOPING

A cryptographic architecture that provides other functionalities besides email. One of the examples refers to data streaming in our architecture. Data streaming cannot be used for email exchanges with external sources outside our ecosystem.

Safe.ad is the first application to use our new platform (the first DApp after decentralization will be completed). This technology has displayed speed, reliability and convenience. File storage is an organic addition to our email client, so we combined both onto a single interface. But if you look at the encryption principles that we used in this application, it is clear that this technology can be employed to create secured messenger, secured DApps for voice / video calls and many other potential applications.

https://safe.ad/ico

https://github.com/safead/client


TOKEN ECONOMICS

The token is called SAFE, it was issued according to the ERC20 standard and is a utility (payment, discount) token required for our service. The starting value of 1 SAFE token will be $1 USD, and up to 30% discount for SAFE has been provided at the presale stage to avoid a sharp drop in price when they are traded freely on the stock exchanges.

The minimum subscription price for our service will be $1 per month. After 3 months of use, payment is required to continue using the service. $0.50 per USD will be retained by the service owners for service maintenance cost. The other half ($0.50) will be converted into tokens SAFE according to current stock exchange rate. SAFE can be freely traded and these tokens (or their fractions) will return to service owners.

There are two parameters that have real importance: the conversion of money spent on advertising into paying customers and the exchange rate at the moment they pay for the service. We are assuming 1 new user for every $10 spent on advertising, which will pay as low as $12 for an annual subscription after 3 months of free trial use. We will direct a substantial part of the proceeds from the ICO to marketing and advertising, that let us grow the client base.

We have no doubt with regards to the quality of our product and therefore the conversion rate of $10 into one paying customer is a realistic ballpark. Safe.ad has faith that this Token Economic Plan would be adopted by other companies that will accept the SAFE Token as a means of payment.

https://safe.ad/ico


TOKENS DISTRIBUTION

10,000,000 SAFEMaximum sold

Price $1

+30% BONUS

[February 1]

+25% BONUS

[March 1]

+20% BONUS

[April 1]

+15% BONUS

[May 1]

+10% BONUS

[June 1]

0% BONUS

[June 15]

1 % Legal

5% Advisors

3% Bounty

8% Network Growth

11% Safe.ad Team & Founders

72% Token Sale Participants

https://safe.ad/ico


AES (Advanced Encryption Standard) and asymmetric RSA (Rivest-Shamir-Adleman) are reliable, trusted and adopted by the industry. Safe.ad adopted these standards into our cryptographic security which use the keys of maximum sizes: AES 256 bit and RSA 4096 bit.

CRYPTOGRAPHIC METHODS WE USE

https://safe.ad/ico


SIGN

RSA

AES DATA

It is well known that symmetric cryptography with AES offers higher speed and the maximum key size is currently 256 bits. Asymmetric cryptography using RSA is several times slower and much more resource-consuming, and to achieve decent reliability, the key size must be ten times larger compared to the symmetric algorithms. It is uncommon to use asymmetric methods to encrypt large amounts of data. Instead, any amount of data is encrypted using the symmetric method, and the encryption key is encrypted using the asymmetric method (in our case by RSA). Below are the examples of a typical and frequently used principles of cryptographic protection:

DISADVANTAGES OF PGP (PRETTY GOOD PRIVACY)

PGP is a very reliable method for encrypting a single data block. Schematically, a block encrypted by PGP tools may be represented as follows:

The encryption sequence is as follows: a random AES key is generated and is used to symmetrically encrypt the DATA. This key, already used to encrypt the data, is then encrypted using the asymmetric algorithm (e.g. RSA). The encrypted data array is combined with the encrypted key, and the resulting data block is signed with the private key of the sender. To decrypt the package, the recipient must first use his private RSA key to decrypt the AES key and then use it to decrypt the data and check the signature (to calculate data hash with the open key of the sender). That’s the essence of Pretty Good Privacy in one simple paragraph. It should be added that a lot of additional features are integrated into this standard, like packing data simultaneously for several different recipients and other useful add-ins.

https://safe.ad/ico


This method, with different algorithms and key sizes, is currently considered to be one of the most reliable and the fastest. But in practice, when we need to create an encrypted data link between certain group of users, PGP turns out to be sluggish. Imagine a messenger that uses PGP to send messages: if you want to read the last 500 messages, your system would have to perform complicated and resource-consuming calculations 500 times which may take long, depending on the processing power of your device:

.

And this is to be done 500 times! Since the asymmetric operations account for almost all the calculations, the performance can suffer massively between tens to hundreds times. Also, if this was a streaming data (audio or video), the streaming itself would invoke severe network latency and system overload. We use a more optimized encryption algorithm in our architecture to set up data transfer between a group of correspondents.

1

SIG

N1

RSA1

AES1 DATA1

2

SIG

N1

RSA1

AES2 DATA2

3

SIG

N1

RSA1

AES3 DATA3

https://safe.ad/ico


ENCRYPTED CHANNELS

Combining the signature check and decryption of the asymmetrical key with multiple blocks of data (encrypted with this key), we maintain cryptographic security, increase productivity, and add scalability to the architecture as a whole:

The encrypted channel can be set up for one-time use (streaming) or stored for continuous use (applicable to data that is either delayed or should be read multiple times). The number of users in the channel is not limited and multiple channels can be created.

For email and file storage modules in our architecture, permanent created channels will remain available for as

long as it is required to allow anyone within the channel to decrypt their data.

It should be noted that this type of cryptographic protection can be used only if both users are inside our system. Emails from external sources are encrypted by our server upon reception and are stored encrypted too. We do not store the original content on our servers in any way.

1SIG

N1 2

RSA1

AES1

3DATA1

4DATA2

5DATA3

https://safe.ad/ico


An invite is a block of data that AES key is obtained for further operations. Users utilizing an existing invite or create a new one each time will begin a message exchange with somebody inside our system. In addition to the AES key, an invite may contain any additional data, such as an information of its creator, the name of the channel, and other required information.

The channel identifier is a hash from a line that is a concatenation of the fingerprints of the users participating in the channel sorted alphabetically. The user identifier (fingerprint is a line in UUID format) is generated randomly every time a password is changed in the system (new pairs of PSA keys are also generated). Before sending any data to a particular list of recipients, Safe.ad will take all the identifiers of these recipients, calculate the channel ID for this set of recipients, check if an existing invite for this ID, or create a new invite for each recipient if it is required.

In case the list of participants is changed or any of the participants have changed their password, a new encrypted channel is immediately created. The data in different channels may be linked via service messages to combine the whole communication history into one information flow. And therefore employ flexibility in this technology that could be used to develop into other useful services.

INVITES

https://safe.ad/ico


To gain a deeper understanding, let us consider the following example:

A first writes to B. A random AES key is generated, 2 invites are created for A and B with the same ID (invite ID and channel ID are the same) and the same content, but for different asymmetrical RSA master keys. After that, A writes to B, encrypting data using only AES once, twice or a thousand times.

B receives the message, which contains only the channel identifier and time (we don’t see any other data on our servers). B requests the invite created by A on our server, unpacks it using their private asymmetric key, and now may post to the same channel, without creating a new one. During the communication, B decides to add a new participant C to the existing channel. The channel identifier is now calculated with the participation of three identifiers, which results in B creating a new invite and sending it to all three. After that, A, B and C communicate using this channel. However, the initial channel between A and B remains the same. They will use it to exchange data with each other, and C does not have access to it.

If A changes his password, his fingerprint changes as well, and both (A–B) and (A–B– C) channels will be recreated when the first new message is sent by any of the participants. Removing B from the list would essentially result in the creation of a new channel (A-C), while the previous structures would remain unchanged.

Rearranging message history when adding or removing participants in not very important for exchanging emails. But an add-on shall be implemented for the chat function that will link the channels on a single topic as they change, by sending a message to the channel indicating the ID of the next channel.

Safe.ad addresses the authenticity of senders and recipients as well. The following implementation will explain how this is achieved to prevent malicious masquerading of user’s identity.

https://safe.ad/ico


We are creating a distributed registry-storage for the public asymmetric keys of our users. The keys are created when a new participant registers in the system or changes their password. Because current cost of storing data in the Ethereum blockchain is rather high (~$10 for 1kB), we don’t find it reasonable to directly store any data in it. To save users’ money (because they are paying for all records in blockchain), Safe.ad only stores hashes in the distributed registry from public keys in decentralized storages. This approach allows significant cost reduction for connecting users to the Ethereum blockchain to about 10–20 cents.

Initially, upon registration, user keys will not be linked with blockchain, and the service will be offered thru a trial basis without any additional limitations complicating the communication process. In future, the distributed storage of files and metadata will also be offered for free to all users immediately.

Users will be granted a 3-month trial period to try out the service. When trial period expires, their accounts will go into limited functionality mode. There is no reason to build our customer base with inactive and unused accounts. Safe.ad will be available for a low price of $1 per month for 1 GB of available disk space to encourage subscribers to join.

BLOCKCHAIN AND DECENTRALIZATION

https://safe.ad/ico


AUTHENTICITY OF THE RECIPIENT

To implement one of the essential ideas of our project, which is to allow user to work with Safe.ad from any device without the need to install additional software. There is a need to provide required data for the authentication process. This means the settings, contact lists, sets of keys, data and invites required to decrypt this data before usage. Public asymmetric keys of the user are essential to ensure the authenticity of the recipient.

While storing key prints in the blockchain does not resolve the problem of MITM (Man In The Middle) attacks, because no systems can guarantee that request to а network node would not be spoofed at the node itself. Hence, comparing hashes for RSA keys received by Safe.ad with hashes stored in the blockchain is considered equivalent to a two-factor authentication between the public keys of both parties. Do note that no two-form authentication systems is 100% certain for “Man In The Middle” attacks.

For example, in response to your request “I need Johnny’s key” we can give you our public key and thus gain the ability to read your email (we can even send the same email to Johnny to his real email address with false “from” fields later on to remain unnoticed). Cryptography allows us to solve this problem using a simple method that uses an additional secure one-time data channel.

All that is needed is to compare the public key of their asymmetric pair with the actual key, which requires their participation. This has to be done only once for using our system.

In simple terms, if users should verify the key manually each time before sending a message, it would require effort a bit too much for a simple message and would be extremely inconvenient. This is because there is a need to compare the whole sequence of 4096 bits (RSA key size), and only the hash of this key can be verified. To remove the need for human intervention, authenticity check has to be saved somewhere in reliable place with no access to unauthorized persons.

https://safe.ad/ico


The key point in securing the authenticity of a correspondent’s key is to store key results so that this question can be automatically answered with a “yes” or “no”. For example, the storage of verification result on the other email provider servers would send the message “is this the right key?” each time. In this case, your provider and the data channel between both parties become the bottleneck. The result can be saved on our device, but that solution would not be universal as it will tie the user to a single device (a very common problem among modern applications). It is also repetitive for the same server to reconfirm the genuine key it issued in the beginning each time. The reason for this unneeded reconfirmation or authentication is usually related to vulnerability in their systems.

Encryption can solve this problem by simply storing critical sensitive data. It eliminates the locality on where this block is stored and hence this data can be decoded in any of device you can access to. Only authenticated user can read and modify settings, contact list, information about other verified contacts (those key identifiers that are verified during personal communication) and other sensitive data, these data can be stored anywhere, even in public places (it is encrypted while stored).

To simplify things and eliminate the need to compare your correspondents’ keys bit by bit, Safe.ad has implemented Z-Base hash of each public key in our system. The long key is a simple sequence of 16 letters and digits has solved the problem of masquerading identities. The ID of your current key in the user panel can be shared. Simple verification can be achieved via a voice call or SMS, screenshots, QR code, or business cards. When you are asked: “Is your key 12ZY-6S7R-5P9B-RGBG?” find them in your contact list. This simplicity, act like your identification number and is unique to you.

As a result, each time you send any data from your device to a particular person, you receive their public key, and the Z-Base hash of that key is compared with the one you saved during verification. Even if someone has tampered with our server or data channel, it is impossible for them to slip you a fake key as it is already verified.

Always verify your contacts for business correspondence, it guarantees you that the recipient is authentic and that the data will never be read without the public key of the recipient.

https://safe.ad/ico


From time to time, users may receive email from a familiar sender. The authenticity of the sender’s identity is only as secure as the email service provider.

Asymmetric cryptography is the solution described above that uses the scheme of cryptographic transfer. It is implemented based on invites – a small block of data containing the keys needed to unpack symmetrically encrypted data with the potential to widen the scope. To identify the sender, the invite is signed by his private key and Z-Base hash of that key is inserted inside the invite itself.

AUTHENTICITY OF THE SENDER

https://safe.ad/ico


Here is an example – the first contact with a new correspondent:

zz A random symmetric key is created to encrypt the data for that channel in the future;

zÈ An invite is created for the recipient. The AES key and Z-Base hash of your private key for signatures are inserted;

zÈ The public asymmetric RSA key of the recipient is requested;

zÈ TheZ-Base hash of the received key is compared with the corresponding record in the blockchain;

zÈ The invite is encrypted using this public key;

zÈ The Z-Base hash of your private key is inserted into invite;

zÈ The invite is signed with your private key and sent to the recipient;

zz Everything is ready to begin data transfer in the new channel; all data is encrypted using the created AES key

The recipient:

zz Decrypts the invite using their private RSA key;

zÈ Requests the public key of the sender;

zz If the sender’s address is verified (there is a corresponding record of the Z-Base hash in recipient’s protected data), the authenticity of the invite signature is checked using the received key, and the Z-Base hash of the public key is matched against the stored in the invite identifier.

Or, if the sender is unknown to us:

zz The Z-Base hash of the received key is compared to the corresponding record in the blockchain;

zz The AES key is extracted from the invite, and you can use the data that was sent to you.

To better explain this scheme, two things should be added:

1. The Z-Base hash of private and public keys are the same. We are not going to dwell into the mathematical model, but it is always possible to obtain the public key from the private asymmetric one (but not vice versa).

2. There is no reason to check the signature of a person whom you don’t know since you have never verified either of their public keys.

https://safe.ad/ico


BUSINESS CARD AND NEW ASYMMETRIC RSA KEYS

What happens when users change their asymmetric keys? This happens each time the password is changed in safe.ad and a new password and a new RSA pair are created. The new key identifiers and all previously verified Z-Base hashes do not become obsolete because the user’s business card and the chain of signatures with previous keys can used.

The business card currently can only contain two values: identifiers (Z-Base hashes) from the current and previous public RSA keys. The business card itself is signed with both keys, which allows unequivocally to identify the previous one. Please refer to the diagram:

The first verified user key and saved ID1, can verify ID4 is authentic by simply rolling out the chain of business cards. It’s a simple, quick and efficient process. By performing this operation once, ID1 is replaced with ID4 and do not need to carry out unnecessary calculations again. However, an invite signed with the ID2 key will perform a reverse scan on the chain of business cards to ensure the authenticity of our correspondent.

ID4ID3ID2ID1

https://safe.ad/ico


PASSWORD CHANGE

What can we do with all the data that was encrypted by previous keys when new ones are generated? There are three options:

1. Keep it as it is, but each pair will require providing its password;2. Keep it as it is, but each new pair will have access to the previous one (master

password of the previous pair is stored encrypted with the private key of the new pair);

3. Re-encrypt all existing data with the new keys.

The first option is inconvenient and will not be used if the user has changed the password ten times. This is because in order to access all data 10 different passwords must be entered.

The third option is most reliable but requires various different software, time and resources.

Safe.ad uses the second option, in which the master password from the latest RSA pair is provided to access all previous asymmetric keys. This means that if a hacker gains physical access to the server and knows the password of a pair of keys, they can gain access to all the data encrypted with this key and with all the previous ones, but not with newer ones. Data paired with an older

key and password can only be access with the new pair of password and keys. Unauthorized physical access to non-deleted data can be controlled by setting up the appropriate lifetime for your data using Safe.ad.

All personal user’s data is re-encrypted immediately with new keys and the previous version is deleted.

Changing passwords regularly will keep data up-to-date and auto delete messages by using the timer option.

https://safe.ad/ico


THREE STAGES OF MESSAGE AUTHENTICITY

All incoming messages from external sources are encrypted with the same algorithm as the client software uses. As soon as the message is received for processing, safe.ad servers will encrypt both messages and attachments. The original message is deleted immediately, with no copies or back-ups of the original text or files. But, if the message text or attachment was unencrypted at any time (upon the Safe.ad entrance), it is assumed that copies were already stored elsewhere. These messages are marked with an icon of a red open lock in reading mode.

Messages received from internal users are always encrypted and are never stored or transmitted in open form anywhere, except on sender and recipient devices. All files, both stored and attached to emails are encrypted. They will be marked as a yellow lock icon.

The maximum security level is achieved for emails from an internal contact with key verification. If you see a green lock icon while reading a message, you can be 100% sure that your correspondent is not masqueraded, and the data is protected. To ensure the authenticity of the sender match the Key ID and use internal addresses (@safe.ad).

1

2

3

https://safe.ad/ico


GROUPING LETTERS

Grouping emails is one of the useful and welcomed innovations in modern email clients. We use standard email fields for reliable and error-free grouping (In-Reply-To, References, Message-Id). All groupings are done quickly and work seamlessly for the user. All grouping operations are performed on the client side, either in your browser or mobile app.

All messages that are downloaded to the device are grouped. Not all the emails are downloaded from every folder immediately after login (otherwise, the client software would start to lag). Emails from the Inbox and Sent folders are downloaded first. If there are messages in other folders with the same In-Reply-To or References field, they will also be added to existing groups. Deleted emails (in the Trash folder) would not be visible in this mode, unless the transition was done from the Trash folder. To show deleted emails in the group on the same subject, use view mode from the Trash folder – in that case, all emails from existing message history will be shown.

https://safe.ad/ico


ALIASES

Using Aliases (alternative names) in the same mailbox is convenient. Each Alias has its nickname, avatar and rule for inbound filtering. All incoming mail for all Aliases will go into the Inbox but may be automatically redirected into a folder specified by you depending on a particular Alias (automatic sorting). To send email from a particular name, you need to switch the current active name with two clicks (in the upper panel in the mobile application, or by clicking the username in the desktop interface).

Aliases in our system could be both internal mail addresses and the names of external mailboxes. When somebody sends an email from our system to your external mailbox in an encrypted format, it would send it to the internal alias with the same name. To ensure the integrity and security of the content, only a notification link about the received message goes to the external box.

For convenience, the Alias is automatically switched when creating the reply, depending on the history of correspondence in the group of emails from which the reply was initiated.

https://safe.ad/ico


AUTOMATIC SORTING OF INCOMING MESSAGES

Many modern email services sort your incoming mail without even asking your permission with the pre-created folders such as “Social networks”, “Promotions”, “Advertisements” or others. We prefer giving our customers full control over these actions, and that’s why our incoming message filtration system is based on recipient Alias or sender address. Only some people would need this tool, but those who work with it will be pleased with the simplicity and convenience of our idea.

The highest priority is sorting by alias, and if no rule is specified, then sorting by senders’ address is performed. Default folders for sorting by alias can be set up in customer settings, and sorting rules for a particular sender are specified from your contact list (to sort incoming messages by sender address, the said address should be in your contact list).

TWO-LEVEL SEARCH

As you enter text in the search field, only the digests of emails that satisfy the conditions of your search are displayed, but only from the current folder. This is an email filtration function in the current folder (without clicking the search icon). To perform a global search in all emails, the search button must be clicked after you have entered all the keywords. The search results would be deposit into a temporary virtual folder. Searching this virtual folder would once again would trigger the email filtration function again. This search method is useful for huge number of emails into very accurate results.

Similar to the operations that cover all the messages, a search through all the messages requires loading all your messages onto the client device (only once per session). To search conveniently through a large number of messages, the device should have a fast internet connection.

https://safe.ad/ico


SENDING TO EXTERNAL ADDRESSES IN ENCRYPTED FORMATThere are two methods to send an email: by unencrypted email message and by sending a link to the encrypted message stored only on our servers. The first method is just a regular email. The second method depends of an external email address was already linked to safe.ad system. If it was, then an RSA pair already exists in our system for this alias with the same name as the address to which the email would be sent. Else the new account and a new RSA pair is generated, the master password of which must be set by the sender. The recipient will see in the email the link to the real email that is stored in our system. When this link is accessed, the recipient must enter the password that was set by a safe.ad user (sender). The password must be shared to the recipient via other channel: over the phone, via SMS, via messenger, or any other means. Without a password, it is impossible to read the message. If encrypted emails are sent to this external mailbox again, there is no need to create a new account, because the pair of asymmetrical keys already exists for this alias.

After entering the member zone with the password provided by safe.ad user, the user will be offered to change the password and choose [email protected] for future login (it is impossible to enter the member zone using an external email as the login details). This is not mandatory but it should be understood that at this point the password is known only to two persons: sender and recipient. If this is the case moving forward, the only way to enter the mailbox with only one alias — an external address — is the link sent to the external email. If two senders people have written two different emails to same external recipient, only one of the senders knows the password (because he created this mailbox), but neither of them has the link necessary to enter the system. But if the external recipient plans to continue using our service and wishes to ensure security of his data later on, then we always recommend changing the password after the first login using the link from the email, as well as adding the alias to login into the system in the future.

The lifespan of a message can be controlled only by safe.ad servers and can be set only if there are internal addresses among recipients or if the message to external mail address was sent as a link and stored on safe.ad server. There is no control for external emails to configure the lifespan of emails.

https://safe.ad/ico


FILE STORAGE MODULEThe processing of each file starts with calculating the identifier called BlobId. The resulting hash is signed with the current key so that within one pair of asymmetric keys, the identifier of contents of the same file is always the same (but always different for another RSA pair). So, it is impossible to determine content of the file using its BlobId, but there is no need to store the same content twice.

A unique AES key is generated for each file, and after that block-by-block asynchronous processing of each part is started. It consists of four stages: reading, archiving (zip), encrypting and sending. Each block has its identifier, the array of those blocks, together with the encryption key and other file parameters (name, type, size, etc.), form a small block of metadata that contains all necessary information to assemble the file in reverse sequence.

This block of metadata for specific channel would be encrypted instantly. Any modifications to a file after it is uploaded to the server (if there is no change of password) usually mean modifications only to the block of metadata. If you download it for your own use, it is done through a channel for a single user. If you attach it to an email message with three recipient addresses, then the channel for these three recipients is used. This is a very quick and efficient method that provides maximum cryptographic security.

Combining the mail module and file storage module allowed safe.ad to implement an interesting feature: all files are located in a single interface with convenient search functions.

https://safe.ad/ico


COMPETITIONNone of our competitors, who also have production-level products has ever claimed that he has created his token to use inside his ecosystem. On the other hand, there are some teams out there planning ICOs in the same area, but none of them have an operational product. So they cannot be taken seriously until they are able to show an operational product.

Here are some popular projects that have launched operational products:

PROTON MAIL

Currently the most popular email service with point-to-point encryption. The principal differences from Safe.ad’s idea are:

zz They don’t plan to implement blockchain in their service (at this point of writing), they did not announce the development or use of a distributed network for data storage;

zz They use PGP for each sent email and can’t use their architecture to stream data;

zz They limit the size of attached files to 25 Mb;

zz They don’t have file storage;

zz They don’t have algorithms to reliably identify correspondents;

zz The minimum subscription price is $5, which is, in our opinion, inflated.

zz They are just an email service, while we create a platform for secured data;

TUTANOTA

One of the time-enduring products on the crypto-mail market.

zz They don’t plan to implement blockchain in their service (at this point of writing ), they did not announce the development or use of a distributed network for data storage;

zz They use weak encryption keys (AES 128), which, in our opinion, don’t meet actual requirements;

zz They limit the size of attached files to 25 Mb;

zz They don’t have file storage;

zz They don’t have algorithms to reliably identify correspondents;

https://safe.ad/ico


LEMON MAIL

The use of modern blockchain technologies means users pay for each written block. It makes no sense to record the mere fact of sending a message from one user to another; it significantly increases the cost of service and offers no additional advantages. A distributed register of public asymmetric keys would have made the system reliable sufficiently which does not require paying for each sent message. In our opinion, this is the biggest mistake in the architecture of this service, which prevents it from moving from the test network Kovan to the main Ethereum blockchain.

Second serious problem with using blockchain to record the fact that a message was sent is incredibly slow delivery. We never received the secure message sent to our email from the Private section.

Thirdly, the Ethereum blockchain will hardly be able to store messages not to mention the attached files, without causing the sender to go bankrupt. That’s why we are very sceptical about Lemon developers talking about the decentralization of stored data.

Besides, this product lacks the compatibility of secure and public correspondence, that is sent or received from external sources. The existence of two different sections, Private and Regular suggest that there are two completely different engines glued together. And if you look at the interface settings, you will see immediately that this is nothing else than the regular Mozilla ThunderBird.

The software complex is at an early stage of development, and nothing hints this product will continue to develop.

SAFE.AD AS A NICHE MARKET

We have been studying the current market for encrypted email systems for a long time, and have not found any other projects in our niche that would meet the basic requirements like our architecture; which does not need installation, is compatible with existing email systems, and provides point-to-point encryption. Safe.ad is a working service currently at this point of writing. The team is ready to implement blockchain technology and distributed storage on-fly.

https://safe.ad/ico


TEAM

We are not entering the market with simply an idea or a useless prototype. We believe in our final product addresses the current needs of anyone looking to secure their data and communications. Whether users are communicating in blockchain or other centralised networks, our product supports Crypto-anarchism and user anonymity on the internet.

PAVEL VITALY YURYDESIGN UX/UI Digital Marketing Lead CMO

MAX ANTON ARTEM EGORCCO CEO Head of cryptography

development Frontend developer

https://safe.ad/ico


VOLUME OF THE BUSINESS EMAIL MARKET

Email remains the most common and most often used communication means in the modern world. An email address is needed for any internet activity, from online shopping to registering on social media. There are currently 3.7 billion email addresses registered in the world. The email services market grows by 17% every year, and by 2021 will reach 46.8 billion dollars (more than twice higher than the current value) according to study by Radicati Group, Palo Alto.

Every day, 269 billion e-mail messages are delivered to users, 39% of which are letters from private persons, and 61% is business correspondence. In the coming years, the number of business letters is expected to grow by approximately 13% each year, and the number of private letters will decline by about 3–4% per year.

CLOUD BUSINESS EMAIL REVENUE FORECAST ($BLN)

Now is the ideal time to create an email service that meets the growing demands of the modern world. The largest players on this market is not concerned with information security, as information by itself is a revenue generating machine in this information-driven era.

$40

$22$29

$15

$35

$42

2016 2017 2018 2019 2020

$30

$20

$10

$0

http://www.radicati.com/wp/wp-content/uploads/2016/06/Cloud-Business-Email-Market-2016-2020-Executive-Summary.pdf

https://safe.ad/ico

http://www.radicati.com/wp/wp-content/uploads/2016/06/Cloud-Business-Email-Market-2016-2020-Executive-Summary.pdf


Start of the Project07.2015

SAFE Tokens pre-sale02.2018

Independent security testingfor all components of our system02.2019

Decentralized metadata storage04.2020

Decentralized data storage 06.2019

Complete autonomy & decentralization of all the service components 2021

Launching Desktop version03.2016

SAFE Tokens sale04.2018

Launching IOS application11.2016

Android application11.2018

Administrative toolsfor corporate mail groups

12.2019

Launching encrypted file storage05.2016

SAFE payment system09.2018

Launching a public key store and API for third-party developers

10.2019

ROADMAP

https://safe.ad/ico


RISK FACTORS

An acquisition of SAFE tokens involves a high degree of risk. Each potential purchaser of SAFE tokens should carefully consider the following information about these risks before he decides to buy SAFE tokens. If any of the following risks actually occurs, the value of SAFE tokens could be materially adversely affected. Risks and uncertainties described below in this document may not be the only ones token holders face. Additional risks and uncertainties may also materially adversely affect value of SAFE tokens.

No Corporate Participation Rights: SAFE tokens do not grant any corporate rights to its holders; in particular, there are no corporate voting rights in the Company, rights to dividend payments from the Company, return of capital from the Company or any other similar corporate rights connected to the SAFE tokens.

Blockchain Delay Risk: On the most blockchains used for cryptocurrencies’ transactions (e.g., Ethereum, Bitcoin blockchains), timing of block production is determined by proof of work so block production can occur at random times. For example, the cryptocurrency sent as a payment for the Safe.ad in the final seconds of the payment period may not get included into that period. The respective blockchain may not include the purchaser’s transaction at the time the purchaser expects and the payment for the Safe.ad may reach the intended wallet address not in the same day the purchaser sends the cryptocurrency.

Blockchain Congestion Risk: The most blockchains used for cryptocurrencies’ transactions (e.g., Ethereum, Bitcoin blockchains) are prone to periodic congestion during which transactions can be delayed or lost. Individuals may also intentionally spam the network in an attempt to gain an advantage in purchasing cryptographic tokens. That may result in a situation where block producers may not include the purchaser’s transaction when the purchaser wants or the purchaser’s transaction may not be included at all.

Risk of Software Weaknesses: The SAFE token smart contract concept is based on and the Safe.ad are still in a development stage and unproven. There are no representations and warranties that the process for creating the SAFE tokens will be uninterrupted or error-free. There is an inherent risk that the software could contain weaknesses, vulnerabilities or bugs causing, inter alia, the complete loss of the cryptocurrency and/or the SAFE tokens.

Risk of New Technology: The SAFE tokens and all of the matters set forth in this document are new and have been tested. However, there is no guarantee that all the goals set forth in this document will be finally achieved and successful.

https://safe.ad/ico


Business Model Risk: There is no guarantee that an investment in Safe.ad will lead to increase of the value of SAFE tokens. Investors must be aware that a partial or total loss of capital of the investment in SAFE tokens cannot be excluded.

Regulatory Risk: Blockchain technology allows new forms of interaction and it is possible that certain jurisdictions will apply existing regulations on, or introduce new regulations addressing, blockchain technology based applications, which may be contrary to the smart contract of SAFE token and which may, inter alia, result in substantial modifications to our smart contract and/or the SAFE token, including its termination and the loss of the SAFE token for the purchase. Additionally, regulation of proposed activities of the Company, including without limitation the provision of cryptocurrencies received during the offering to Safe.ad, is currently uncertain. It is not known what regulatory framework national banking supervisory bodies will impose on cryptocurrencies and the Company. It may occur that SAFE token and/or the Company on any way in the future may fail to comply with any such (new) regulatory framework so that it may not continue to carry out its proposed business activities as set out in this document.

Tax Risk: Holders of SAFE tokens may be required to pay taxes on associated with the purchase and sale of SAFE tokens and profits made upon exiting an investment made in Safe.ad, whether in their country of residence or any other country they have personal or professional ties to. It will be the sole responsibility of SAFE token holders to comply with the respective tax they are subject to, bearing in mind that many jurisdictions may currently not have any regulations relating to cryptocurrencies and profits relating therefrom.

Further Risks: There are a number of further risks and uncertainties relating to the Company, its business model, the SAFE tokens and Safe.ad not set forth above in this section which may arise, and which a prospective purchaser of SAFE tokens should consider and carefully evaluate prior to making the decision to an investment in SAFE tokens.

https://safe.ad/ico


LEGAL NOTICE

This document does not constitute or form part of any opinion on and shall not be construed as any advice to sell, or any solicitation of any offer by the Company, to purchase any tokens (SAFE tokens) nor shall it or any part of it, nor the fact of its presentation, form the basis of, or be relied upon in connection with, any contract or investment decision.

The Company will deploy the proceeds of sale of the SAFE tokens to make investments and fund operations.

You are not eligible and you have no rights to purchase any SAFE tokens in the Initial Coin Offering (ICO) if you are a citizen, resident (tax or otherwise) or green card holder of the United States of America or any other country or territory where transactions with digital tokens are prohibited or in any manner restricted by applicable laws or regulations, or will become or be so prohibited or restricted at any time after this Agreement becomes effective.

We do not accept participation from the Restricted Persons and reserve the right to refuse or cancel the SAFE tokens purchase requests at any time at our sole discretion when the information provided by the purchasers within the KYC procedure Is not sufficient, inaccurate or misleading, or the purchaser is deemed to be a Restricted Person.

No regulatory authority has examined or approved of any of the information set out in this document. No such action has been or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The publication, distribution or dissemination of this document does not imply that the applicable laws, regulatory requirements or rules have been complied with.

There are risks and uncertainties associated with the Company and its business and operations, the SAFE tokens, the ICO and the underlying assets, as described above.

This document, any part thereof and any copy thereof must not be taken or transmitted to any country where distribution or dissemination of this document is prohibited or restricted.

This document, statements made by the Company in press releases and social media platforms accessible by the public may contain some forward-looking-statements which do not relate to historical facts (developments, figures, etc.) and events. These forward-looking-statements are based on analysis, assumptions or forecasts of future events and figures which are not finally predictable or foreseeable. Such forward-looking-statements are therefore subject to risks, uncertainties and other factors which may cause actual future results, performance or achievements of the Company, its affiliates, the SAFE tokens and Safe.ad to be materially different from that expected, expressed or implied by the forward-looking-statements herein. No undue reliance shall be placed on such statements.

https://safe.ad/ico


Nothing set forth in this document shall be understood or interpreted as advice (business, financial, legal and/or tax) provided by us relating to the Company, its affiliates, the SAFE tokens and Safe.ad, and should therefore not be relied upon as advice. You should consult with your own advisors prior to making an investment in SAFE tokens.

Please note that we are under no obligation to update this document, the Company’s website and/or any information given in connection with this initial coin offering. The document may, however, be subject to change. Any update provided by the Company will be made voluntarily and in its sole discretion.

We make no guarantee that Safe.ad service will be a successful. Therefore, there is also no guarantee that the value of SAFE tokens will rise. Apart from any situations outlined in the legal system, we exclude any and all implied warranties. Therefore, we make no representations and warranties whatsoever and disclaim all liability to the maximum extent.

The English language is the primary official source of information about the project. The information contained in English language may from time to time be translated into other languages. In the course of such translation some of the information contained in the English language document may be lost, corrupted or misrepresented. The accuracy of such alternative communications cannot be guaranteed. In the event of any conflicts or inconsistencies between such translations and the official English language, the provisions of the English language original document shall prevail.

https://safe.ad/ico

safe · encrypted channels ... communication is hopelessly out of date. it is based on the minimum...

Documents