1. ChatLiner is an open source platform for protecting sensitive, confidential or private information based on Digital Chip Card Locker ("DCCL"). 2. Digital Chip Card Locker is a group of mathematically based algorithms that set the highest standards for online data protection. 3. You are entirely responsible for the content you share via ChatLiner, as well as who you share your content with. 4. The Licensor does not claim ownership of the content you share via ChatLiner. You will continue to own your content and may use it in any way you choose. 5. You may terminate this Agreement at any time. 6. The Licensor may prohibit your use of this Software at any time due to your potential violation of this Agreement. 7. The Licensor may terminate this Agreement at any time due to your potential breach of this Agreement. 8. Refunds are only possible if you do not receive the service you paid for. In all other cases, refunds do not apply.

Permission is hereby granted, free of charge, to any licensee who obtains a copy of the programming code (the "Code") and associated documentation to use the Code without restriction, including, without limitation, the rights to use, copy, modify and/or merge portions of the Code or the Code in its entirety in accordance with the terms of this Agreement. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Code. The Code is available at https://soundsofsoftware.com/login.js.

1 The client enters the desired username. 2 A pair of RSA keys is generated locally on the user's device: one is the private key, and the other is the public key. The private key must be kept secret and must never be shared with others or its contents revealed, while the public key is publicly available and can be shared with other parties. 3 The client is required to save the generated private key on their device. The public key is automatically uploaded to the registration server, which triggers the sending of a registration request. 4 The server generates a temporary code for end-to-end encrypted communication with the client. The temporary code consists of randomly generated digits arranged in series, each series being divided into 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 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 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 registration. 11 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. 12 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. 13 The digital signature is validated by recalculating the hash codes and checking whether they match. The availability of the requested username is also confirmed (or not confirmed), and the client is notified of the result. 14 If the digital signature is valid and the username is available, the registration is complete. 15 The application that manages the registration process creates a log file named after the hash code and writes the client's public key and the client's username to the file. Although this is public data, there is no reason not to store the file in a secure location, which would make it inaccessible to cyberattacks. This is called a registration file. 16 If the digital signature is not valid or the username is not available, the registration process must be repeated. 17 Finally, the application that manages the registration process will be closed and the temporary DCCL key will be deleted from the server.

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 randomly generated digits arranged in series, each series being divided into 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 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 that allows the server to identify the application, operating system, Internet Service Provider (ISP), and/or web browser version of the client's device. 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.

1. By default, we only have one device from which we can log in with the specified username. Any attempt to log in from another device with a different IP address, or device identification string will be rejected. 2. In order to log in to the 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 details. 3. Each device is represented by a different ID string and/or IP address, which is the data that the server needs to recognize in exchange for granting the device permission to access the system. 4. We actually need to transfer the login credentials from device to device and then forward them to the server for further processing. The user is assumed to have direct access to all devices from which they want to send a login request. 5. The login details are sensitive and must not be at risk of interception or misuse during transmission, so tokens will be used instead. DCCL technology utilizes tokenization by adopting a series of digits underlying the data transfer process between two desktop or mobile devices at a short distance. 6. The user sends a token request using the primary device (i.e., the device that is already logged in). The client will request as many tokens as there are new devices asking for permission to log in to the system. 7. The server generates a temporary DCCL key consisting of randomly generated digits divided into chunks. This code is used to encrypt data exchanged between the client and the server in the tokenization process. 8. The DCCL key itself is encrypted with the client's public key and decrypted with the corresponding private key on the client side. 9. The token is created on the server as a series of digits and encrypted with a ready-made DCCL key to prevent interception and misuse by unauthorized parties. The token is decrypted with the same DCCL code after it is retrieved by the intended recipient. 10. The generated tokens are stored in a secure location on the server, offline and out of reach of cyberattacks. 11. The user picks up the device they want to log in from using the same username. For example, the primary device is a smartphone, and the other device is a computer. The user enters the digits representing the token displayed on the phone screen into the corresponding field on the computer screen and sends them to the server for verification. 12. The server is yet to verify whether the string of digits that make up the token exists in the database. If the string exists, the public data of the device accessing the system (IP address, data identification string) is recorded, while the login request is considered accepted. If it does not exist, the login request will be rejected. 13. After processing, the token is removed from the server for security reasons. If someone intercepted the series of digits during transmission, they will no longer be able to misuse it. 14. The entire process takes only a few seconds, including the time it takes for the server to digitally process the token.

1. A digital telegram is an electronic message of significant importance that conveys sensitive, confidential, or private information. It contains a text message and, optionally, an attached file of up to 30 MB in size. 2. Digital telegrams are encrypted and digitally signed using Digital Chip Card Locker technology, or DCCL for short. 3. DCCL utilizes two-step authentication to verify your digital identity. While entering your username is the first step, the second step is selecting a uniquely generated file that was saved to your device upon registration. 4. Two-factor verification implemented by DCCL is based on passwordless authentication. Instead of dealing with a traditional password, you will authenticate using its more secure and convenient digital equivalent in the form of a passkey, a combination of hash codes, device identification strings, and registered IP addresses. 5. End-to-end encryption defines communication in such a way that a message (whether it is a registration or login request, or a digital telegram) is encrypted on the sender's side and decrypted on the receiver's side, without the possibility of anyone else intercepting and decrypting it. 6. Using the same username on different devices when logging in can pose a security risk. DCCL introduces tokenization as a principle for synchronizing credentials across multiple devices and preventing compromise of sensitive, confidential or private information.