The SALT protocol is based on the need to identify each party to a conversation. Other protocols provide the ability to do so; but the main purpose of the SALT protocol is to facilitate verifiable  exchanges between parties.

The SALT protocol is an N-factor identity-based authentication text-based protocol which allows network data exchanges to be secured and their origin verifiable. It can be embedded in any connection or connection-less protocol, such as HTTP, FTP, UDP, or IP.

The SALT protocol requires, that two entities involved in a communication session, must be able to synchronize on a particular salt value, encryption algorithm, a cypher mode, an obfuscation mode, a set of encryption characters, and progression algorithms for obfuscation. The set of required information is called the salt-setting.

The SALT protocol also requires that a communication entity must identify itself with a specific access key, a sequence of bytes, generated by a cryptographic engine, using the peer's or his own salt-setting, as the shared secret.

Each party to a conversation must have a salt-setting, which is exchanged through a secured handshake -- see SALT protocol white-paper.

A party to a communication session can, depending on the type of the salt-setting (see the NVC club patent), be the primary initiator of a salt-setting exchange; where the other party is not required to give their own setting. The initiator, of the exchange, is seen as the owner of any conversation; and is the only party able to change the salt-setting in use.

Device is a type of salt-setting, reserved for device access, such as printers, video cameras, etc..

Network is a type of salt-setting, reserved for peer-to-peer networking using fully qualified domain names, IP addresses and port numbers.

Club and account are two types of salt-setting; where, the initiator of the exchange is the owner of any conversation. The owner of a club salt-setting is the club owner; and, the owner of an account salt-setting can be a desktop environment or a website. In a club environment, the initial handshake must be made with each peer's network salt-setting.

Every time a user logs into a desktop computer; he/she gets an updated account salt-setting; which is then used by every application or plugin, running within the desktop environment, to access files, and make requests to other applications or plugins -- see the PI-Desktop white-paper). No application or plugins can be instantiated, unless their signature has been verified.

When a person opens an account on a website, he/she is given an account salt-setting; which is then expected to be used every time the user chooses to log-on. The user may always get an updated salt-setting, in the response, sent by said website.

The SALT protocol requires that the initial exchange, between two unknown server peers, be done using an invitation to the Dance approach (akin to the old modem callback method). It consists in using an initial Diffie-Hellman exchange from the peer asking to join the dance (the dance is a given Virtual Private Network).  For example, a company's supplier may be invited to join the company's VPN, but must first ask to join. The company server, which receives the supplier's request to join, then makes UDP requests to 2-5 of its own peers to verify that the requester/peer is probably who it says it is; by making Diffie-Hellman exchanges of their own, with the supplier's machine. The result of these exchanges are collated, by the server, to perform a verification exchange. The initial exchanges must always be encrypted; they must be implemented using SSL connections, or other strong encryption protocols.

The SALT protocol also requires the use of a universal unique identifier as a way to identify a given person wherever the person may be located. A given person needs to carry along the uuid salt key; so when the person accesses a host. the salt key is then communicated to whichever internet messaging system that keeps track of people's locations. The alternative to a uuid salt key is an OpenID.

The SALT protocol allows the use of a modified Diffie-Hellman exchange when setting-up Secure Socket Layer (SSL) connections, allowing specific asymmetric encryption keys to be exchanged. Such keys can be host-based, device-based, resource-based, club-based, or user-based; and use unique identifiers, such as UUIDs. The ability to exchange specific keys, allows an HTTP server to track the use of public keys by peers. The SALT protocol allows the use of any encryption mode; and public-key encryption and the use of certificates, is and another way of implementing the invitation to the dance protocol, by associating a unique identifier to an SSL certificate; and, where the certificate verifier can either be a series of replicated certificates servers, or a central one.

A first adjunct to this patent is the use of a salt-based universal unique identifier and of a main tracking server, such as a match making service server, allowing any device to inquire of the particular location of a given application, device or person.

A second adjunct to this patent is the use of the salt synchronization database to create and update a list of public-keys on a given computer. The said computer is then used as a public-key server.

A third adjunct to this patent is the use of the salt synchronization database to announce a set of accessible computers to another computer.

A fourth adjunct to this patent is the use of the user, host, club, resource, or device-based public-keys and certificates to deploy a modified secure socket layer communication using SALT protocol handshakes and verification.



Patent Pending

Tsert.inc/Tsert.Com