Mesh/Recrypt

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

This protocol is makes use of technology described in the following specifications JSON [RFC7159] For encoding of message data structures. JOSE [RFC7515] [RFC7516] [RFC7518] Formats for cryptographic messages and keys in JSON. JSON Web Service [draft-hallambaker-json-web-service-04] Describes the approach used for Web Service discovery and the encapsulation of JSON messages as HTTP payloads with the necessary authentication and encryption services. Uniform Data Fingerprint [draft-hallambaker-udf-05] Describes the mechanism used to create identifiers for cryptographic keypairs from the public key. In addition, the following specifications are closely related but not required for implementation: Transport Layer Security [RFC5246] The use of TLS to protect the confidentiality and integrity of all protocol communications is of course highly recommended. It is however highly undesirable for a cryptographic protocol such as LURK should rely on transport layer security enhancements alone. The Mathematical Mesh [draft-hallambaker-mesh-architecture-03] [draft-hallambaker-mesh-reference-04] MAY be used to establish trust relationships between the parties in the protocol. CFRG Elliptic Curves and Algorithms [RFC7748] The threshold and proxy re-encryption schemes described are likely to be of most interest in conjunction with the emerging elliptic curve based cryptography. JSON-BCD [draft-hallambaker-jsonbcd-06] JSON-B or JSON-C encoding may be used if an efficient binary or compressed encoding is required. Alternatively, message structures MAY be encoded according to TLS conventions.

In traditional public key encryption, one key, the public key is used to encrypt messages and a second key, the private key is used for decryption. While this is sufficient for communication between two parties, it is less satisfactory when a message is to be sent to a group of users. Use of a session key allows a message to be sent to multiple recipients at once, but only if the list of recipients is known to the sender. And unless special processing is performed in the infrastructure, the distribution list is disclosed to all the message recipients. The need for more flexible communication patterns has traditionally been supported through the use of key management services. A message encrypted under the public key of the key management service is decrypted on demand and re-encrypted under the public key of an authorized recipient. Again the use of session keys permits this to be performed efficiently (only the session key need be re-encrypted). This approach provides the necessary functionality but the end-to-end protection of confidentiality is lost. The use of proxy re-encryption 'recryption', affords full flexibility without losing end-to-end protection of the encrypted data. As with traditional public key encryption, one public key is used for encryption but instead of using one private key to decrypt, this is split into a pair of decryption keys for each authorized recipient. One of these keys is held by the key server and the other is held by the recipient. Since both private keys are required to complete decryption of the message, neither the key server nor the recipient can decrypt the message without the co-operation of the other. Thus end-to-end confidentiality is preserved even if the ciphertext is disclosed and the key service is entirely compromised.

Currently three forms of public key encryption algorithm are in widespread use, RSA, Diffie Hellman and Elliptic Curve Diffie-Hellman. In each case, the operation at the heart of the algorithm is a method of calculating some function f^n(x) for some very large value n in some group order p. It follows therefore that if n = a+b mod pand there is an efficient method of calculating f^n(x) from f^a(x) and f^b(x), we can perform a private key operation in two separate stages and then combine the results to obtain f^n(x). In practice, the encryption algorithms of greatest interest at the current time is Elliptic Curve Diffie-Hellman using the curves Ed-25519 and Ed-448. While the Montgomery forms of these curves for encryption is widely established, existing implementations do not provide the primitives required to implement a recryption form of the algorithm directly. Equivalent Edwards curves were defined because the same limitation also hinders implementation of digital signatures. Since this code provides the cryptographic primitives we need for recryption, it makes sense to use them for both purposes.

The basic Mesh/Recrypt protocol has three parties: Administrator The initial generator of the encryption keypair associated with the group and the holder of the corresponding private key. The administrator has the ability to add users to the group and the authority to remove them. Service The recryption key service responds to administration requests from the authorized administrator(s) and recryption requests from members of the recryption group(s) it manages. Member A member of at least one recryption group. All group members have at least one personal decryption key. Note that the use of recryption does not change the encryption process at all, except to the extent that the party encrypting the message MUST support use of the algorithm specified by the recryption key. Thus a message sender or a creator of an encrypted document is not a party to the Mesh/Recrypt protocol. To create a recryption group, the administrator first creates a public encryption keypair and publishes the public key. She then uses the private key to create a recryption keypair for each of the initial members of the group and publishes these to the key server. Note that the private key for the recryption group is held by the administrator and is never revealed to the key service. In applications requiring a high level of security, this private key may be stored on a smartcart or other form of Hardware Security Module (HSM). The administrator client creates a recryption entry for each member and publishes it to the key service. This recryption entry contains: The UDF fingerprint of the user's mesh profile The recryption key for the user User decryption entry containing the corresponding decryption key encrypted under the public encryption key of the user. Storing the decryption key information at the keyserver avoids the need to communicate any information to the user during group administration operations. The administrator may add or remove group members at any time. Note however that while the key server cannot add members to a group, the ability to permanently delete members from the group relies on the key service permanently erasing the information in the recryption entry. To decrypt a message, a group member reads the recryption data provided and determines which Mesh/Recrypt service to contact. The member then submits a recryption request specifying the UDF of their mesh profile. If a recryption entry exists for the specified key and the member is authorized to decrypt that message, the recryption service generates a partial recryption result and returns it together with the user decryption entry. The member then decrypts the private key in the decryption entry, uses it to obtain a second partial decryption result and combines the two partial results to obtain the decryption key.

The basic protocol may be extended in several ways: Support for multiple encryption keys within a group to prevent collusion between the key server and former group members after a key rollover event occurs. Distinguishing between Administrators authorized to add and remove users and Super-Administrators with the ability to add and remove Administrators. Specify quotas to restrict the amount of data members may decrypt. Enforce separation of duties in the administration function through key splitting. Use of linked notary logs, aka Blockchain techniques.

It is often useful to be able to verify that a service is ready and willing to perform transactions before attempting to perform one. Especially so when the transaction requires considerable amounts of data and may require the use of specific server determined authentication options. The request message is 'HelloRequest' and has no parameters:

The response message specifies the protocol version(s) supported, the corresponding encodings and bindings:

The request message is 'CreateGroupRequest' and specifies the initial data to be used to populate the group.