P500
LOADING...
#How To Log Into Your Online Account Using Digital Chip Card Locker
#See how signing in with DCCL works - step by step, in detail
1 The client enters the registered username and selects the corresponding RSA private key stored on the device the client is using. The login request is sent to the server in the form of a hash code calculated for the entered username.
2 It is checked whether a registration file named after this hash code exists on the server. The registration file consists of the client's public key and the entered username and is stored in a secure location.
3 If the registration file exists, it is up to the server to verify the user's digital identity, which is the primary goal of the login process. Once the identity has been confirmed, the user will be granted access to the system.
4 The server generates a temporary code for end-to-end encrypted communication with the client. The temporary code consists of 500 randomly generated digits arranged in 10 series of 50 digits, each series being divided into 9 chunks. The temporary code formed is called a DCCL key. DCCL technology includes logarithmic functions and exponential functions as mutual inverse functions, with different bases, exponents and arguments derived from the corresponding parts of the DCCL key.
5 A DCCL key can be composed of a large number of randomly generated digits (up to 1500 or even more) arranged in as many series as needed (it can be a series of 1, 2, 5, 10 or even 50), while the number of chunks varies from 9 to 17. It all depends on how strong the encryption is supposed to be. The more digits, the more series and chunks, the stronger the protection. On the other hand, the response time increases, which greatly affects the time required to perform encryption and decryption. In some cases, such as online payments, it is unacceptable to wait too long for the transaction to be completed and a compromise solution must be found.
6 Each of the 10 strings that make up the DCCL key is encrypted with the client's public key on the server side, notifying the client that the file containing the DCCL key is ready to be downloaded. The DCCL key is temporarily stored in the memory of the application that manages the registration process until the registration is complete and is not stored or logged anywhere else.
7 The client loads the encrypted DCCL key and decrypts it using the corresponding private key located on the client's device. The decrypted set of DCCL keys is temporarily stored in the browser's memory (and is not stored or logged anywhere else) and will be used to encrypt data that the client sends to the server.
8 The entered username is encrypted with the loaded DCCL key. The algorithm involves end-to-end encryption springing from a combination of multiple logarithmic functions, each containing a base and exponent derived from the corresponding part of the DCCL key.
9 A composite file containing the encrypted username, the hash code calculated from the original username, a timestamp, and DCCL-encoded variables associated with artificially generated "fake" logarithmic values is created on the client's device. This is called a data file.
10 In addition to the components embedded for registration purposes, there is another tag called a device identification string. It is a "fingerprint" associated with the user's device consisting of the external and internal IP address, user-agent string, operating system, screen resolution, browser version, plugins, color depth, time zone, and language settings. The device identification string is encrypted using the loaded DCCL key and is also included in the data file.
11 Finally, there is the key element for verifying the user's digital identity. Recall that during registration, a pair of RSA keys is generated locally on the user's device: one is a private key, and the other is a public key. The client is required to save the generated private key on their device, while the public key is automatically uploaded to the registration server. This and such private key is something that only a specific user possesses and we will use it to verify the identity of that user, without the risk of exposing the private key to the public. We will randomly select a few dozen characters that make up the private key and use them to form a string, which we will immediately digitally sign by extracting a hash from it and encrypting it using the loaded DCCL key. The sequence of selected characters are also encrypted using the same DCCL key and must be recorded for later decryption purposes. Along with other tags (which include the device identification string + the device's external and internal IP address), the string consisting of the characters selected from the private key and their sequence will become an integral part of the data file.
12 A hash code is calculated for the given data file. The generated hash code represents a digital signature attached to the file and verifies the integrity of the file and the authenticity of the client who initiated the login request.
13 The digital signature is encrypted using the loaded DCCL key and inserted into the data file, which is then uploaded in its entirety to the server.
14 The server accepts the digitally signed data file and decrypts the digital signature and DCCL-encrypted variables using the inverse DCCL algorithm and the very same DCCL key that was used for encryption on the client side.
15 The digital signature is validated by recalculating the hash codes and verifying their match. If the digital signature is valid, the server checks whether a registration file with the requested username is in the server's database, which is the second time this check is performed. If the file exists, the username is confirmed to have been registered regularly and the client receives a notification of successful login.
16 Another log file, named after the username hash, is created and temporarily stored in a secure location on the server. It contains the user's public and internal IP address, hashed characters extracted from the user's private key and their string, as well as the device identification string. This file is called the login file and indicates that the user is logged in to the system. It is deleted from the server after a specified period of time or when the user logs out.
17 If the digital signature is not valid, the login process must be repeated. If the username is not registered regularly, the client should enter a different username and try logging in again.
18 After successful login, all subsequent communication between the client and the server must rely on the data stored in the login file. If the data at the time of sending a message or sharing a file differs from that recorded on the server, communication between the parties will be immediately interrupted or will not be established at all.
19 If we want to log in to a system from multiple devices using the same username, we need to provide the server with information on how to identify those devices by synchronizing their login information. This is done using a technique called tokenization, which is also implemented by DCCL technology.
#Share on social media
#End-to-end encryption in the truest sense of the word: ChatLiner, at your service
ChatLiner is an open-source platform that provides authentic end-to-end encryption of transferred files and messages and prevents their modification, loss, damage or misuse. There is no compromise, interception or collection of users' personal data or sensitive data from users' devices.
#ChatLiner is an open-source platform that provides authentic end-to-end encryption of transferred files and messages and prevents their modification, loss, damage or misuse. There is no compromise, interception or collection of users' personal data or sensitive data from users' devices.