< draft-hallambaker-mesh-cryptography-00.txt   draft-hallambaker-mesh-cryptography-01.txt >
Network Working Group P. Hallam-Baker Network Working Group P. Hallam-Baker
Internet-Draft April 4, 2019 Internet-Draft July 4, 2019
Intended status: Informational Intended status: Informational
Expires: October 6, 2019 Expires: January 5, 2020
Mathematical Mesh Part VIII: Cryptographic Algorithms Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms
draft-hallambaker-mesh-cryptography-00 draft-hallambaker-mesh-cryptography-01
Abstract Abstract
The Mathematical Mesh 'The Mesh' is an infrastructure that The Mathematical Mesh 'The Mesh' is an infrastructure that
facilitates the exchange of configuration and credential data between facilitates the exchange of configuration and credential data between
multiple user devices and provides end-to-end security. This multiple user devices and provides end-to-end security. This
document describes the advanced encryption services supported by the document describes the cryptographic algorithm suites used in the
Mesh. Mesh and the implementation of Multi-Party Encryption and Multi-Party
Key Generation used in the Mesh.
This document is also available online at This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh- http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html [1] . cryptography.html [1] .
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 6, 2019. This Internet-Draft will expire on January 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 16
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Related Specifications . . . . . . . . . . . . . . . . . 3 2.3. Related Specifications . . . . . . . . . . . . . . . . . 4
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 3 2.4. Implementation Status . . . . . . . . . . . . . . . . . . 4
3. Recommended and Required Algorithms . . . . . . . . . . . . . 4 3. Recommended and Required Algorithms . . . . . . . . . . . . . 4
4. Key Co-Generation . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Mesh Device . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Constrained Device . . . . . . . . . . . . . . . . . . . 5
4.1.1. Application to Elliptic Curve systems . . . . . . . . 5 4. Multi-Party Cryptography . . . . . . . . . . . . . . . . . . 6
4.2. Implementation for Ed25519 and Ed448 . . . . . . . . . . 5 4.1. Application to Diffie Hellman (not normative) . . . . . . 6
4.3. Example: Provisioning the Confirmation Service . . . . . 6 4.2. Multi-Party Key Generation . . . . . . . . . . . . . . . 6
4.4. Implementation for X25519 and X448 . . . . . . . . . . . 7 4.3. Multi-Party Decryption . . . . . . . . . . . . . . . . . 7
5. Recryption . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Mutually Authenticated Key Exchange. . . . . . . . . . . 7
5.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Implementation . . . . . . . . . . . . . . . . . . . . . 7
5.2. Implementation . . . . . . . . . . . . . . . . . . . . . 9 4.5.1. Implementation for Ed25519 and Ed448 . . . . . . . . 8
5.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 10 4.5.2. Implementation for X25519 and X448 . . . . . . . . . 8
5.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 10 5. Multi-Party Key Generation . . . . . . . . . . . . . . . . . 9
5.2.3. Message Encryption and Decryption . . . . . . . . . . 11 5.1. Example: Provisioning the Confirmation Service . . . . . 10
5.3. Example: Messaging group . . . . . . . . . . . . . . . . 11 6. Multi-Party Decryption . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.2. Implementation . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 14
9.1. Key Combination . . . . . . . . . . . . . . . . . . . . . 13 6.2.3. Message Encryption and Decryption . . . . . . . . . . 14
9.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Example: Messaging group . . . . . . . . . . . . . . . . 15
9.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Mutually Authenticated Key Agreement . . . . . . . . . . . . 17
9.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
9.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 13 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Key Combination . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1.1. Ed25519 . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.1.2. Ed448 . . . . . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 14 11.1.3. X25519 . . . . . . . . . . . . . . . . . . . . . . . 18
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1.4. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 11.2. Group Encryption . . . . . . . . . . . . . . . . . . . . 19
11.2.1. X25519 . . . . . . . . . . . . . . . . . . . . . . . 19
11.2.2. X448 . . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . 20
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
One of the core goals of the Mesh is to move the state of the art in This document describes the cryptographic algorithm suites used in
commercial cryptography beyond that achieved in the 1990s when PKIX, the Mesh and the implementation of Multi-Party Encryption and Multi-
S/MIME and OpenPGP were first developed. While each of these Party Key Generation used in the Mesh.
infrastructures and protocols has been subject to incremental
improvement, none has seen widespread adoption of new cryptographic
approaches.
This document describes the application of three technologies which
have been discussed in the cryptographic literature for many decades
but have not (yet) been applied to standards-based network protocols:
o Recryption To allow use of Mesh capabilities on the least capable computing
devices currently in use, separate schedules of recommended and
required algorithms are specified for Standard Devices and
Constrained Devices.
o Key Co-Generation The Constrained device class may be considered to include most 8-bit
CPUs equipped with sufficient memory to support the necessary
operations. For example an Ardunino Mega 2560 which can perform ECDH
key agreement and signature operations in times ranging from 3 to 8
seconds. While such a device is clearly not suited to perform such
operations routinely, a one-time connection process that takes
several minutes to complete need not be of major concern.
o Quantum Resistant Signatures. The Standard device class may be considered to include the vast
majority of general purpose and personal computing devices
manufactured since 2010. Even a Raspberry Pi Zero which currently
retails at $5 is capable of performing the cryptographic functions
required to implement the Mesh with negligible impact on the user.
2. Definitions 2. Definitions
This section presents the related specifications and standard, the This section presents the related specifications and standard, the
terms that are used as terms of art within the documents and the terms that are used as terms of art within the documents and the
terms used as requirements language. terms used as requirements language.
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 7 skipping to change at page 4, line 19
documentation set and related specifications are described in this documentation set and related specifications are described in this
document. document.
2.4. Implementation Status 2.4. Implementation Status
The implementation status of the reference code base is described in The implementation status of the reference code base is described in
the companion document [draft-hallambaker-mesh-developer] . the companion document [draft-hallambaker-mesh-developer] .
3. Recommended and Required Algorithms 3. Recommended and Required Algorithms
4. Key Co-Generation To allow implementation of Mesh capabilities on the widest possible
range of devices, separate algorithm requirements and recommendations
are specified for four classes of device:
Public Key Co-Generation is a capability that is used in the Mesh to Administration Device A general-purpose computing device that is
enable provisioning of application specific private key pairs to used for Mesh administration functions.
connected devices without revealing any information concerning the
application private key of the device.
For example, Alice provisions the confirmation service to her watch. Mesh Device A general-purpose computing device that is not used for
The provisioning device could generate a signature key for the device Mesh administration functions with sufficient memory and
and encrypt it under the encryption key of the device. But this processing power to perform public key cryptography operations
means that we cannot attribute signatures to the watch with absolute without paying particular attention to the impact on performance.
certainty as the provisioning device has had knowledge of the watch
signature key. Nor do we wish to use the device signature key for
the confirmation
service. Constrained Device An embedded computing device with limited memory
and computing power that offers sufficient processing capabilities
to perform occasional public key operations (e.g. during device
initialization) but is not suited to repeated operations.
Public Key Co-Generation allows an administration device to provision Bridge Device A trusted device that enables Mesh Devices to
a connected device with an application specific private key that is interoperate with Constrained devices.
specific to that application and no other such that the application
can determine the public key of the device but has no knowledge of
the private key.
Provisioning an application private key to a device requires the Since Administration Devices and Mesh Devices MUST support
administration device to: communication with Mesh Devices and Constrained devices, they MUST
meet all the REQUIRED algorithms for both types of device.
o Generate a new application public key for the device. 3.1. Mesh Device
o Construct and publish whatever application specific credentials Support for the following algorithms is REQUIRED:
the device requires to use the application.
o Providing the information required to make use of the private key o SHA-2-512 [SHA-2]
to the device.
Note that while the administration device needs to know the device o HMAC-SHA-2-512 [RFC2104]
application public key, it does not require knowledge of the device
application private key.
4.1. Mechanism o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869]
o AES-CBC-256 Encryption [FIPS197]
The Diffie Hellman key agreement and elliptic curve variants thereof o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394]
support properties we call the Key Combination Law and the Result
Combination Law. o Montgomery Curve Diffie-Hellman Key Agreement X25519 and X448
[RFC7748]
o Edwards-Curve Digital Signature Algorithm Ed25519 and Ed448
[RFC8032]
Support for the following algorithms is RECOMMENDED:
o AES-GCM-256 Encryption [AES-GCM]
o SHA-3-512 [SHA-3]
o KMAC SHA-3-512 [SHA-3-Derived]
While the use of GCM is generally preferred over CBC mode in IETF
security protocols, this mode is not currently supported by the
reference implementation platform.
3.2. Constrained Device
Support for the following algorithms is REQUIRED:
o SHA-2-512 [SHA-2]
o HMAC-SHA-2-512 [RFC2104]
o HMAC-based Extract-and-Expand Key Derivation Function [RFC5869]
o Poly1035 Authenticated Encryption [RFC8439]
o ChaCha20 Encryption [RFC8439]
o Advanced Encryption Standard (AES) Key Wrap Algorithm [RFC3394]
o Edwards-Curve Digital Signature Algorithm Ed25519 [RFC8032]
o Edwards-Curve Diffie-Hellman Key Agreement Ed25519 [RFC8032]
Use of the Edwards Curves for Signature and Key Agreement allows both
functions to be supported by a single library with no reduction in
security.
4. Multi-Party Cryptography
The multi-party key generation and multi-party decryption mechanisms
used in the Mesh protocols are made possible by the fact that Diffie
Hellman key agreement and elliptic curve variants thereof support
properties we call the Key Combination Law and the Result Combination
Law.
Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs. Let {X, x}, {Y, y}, {E, e} be {public, private} key pairs.
The Key Combination law states that we can define an operator ? such The Key Combination law states that we can define an operator ? such
that there is a keypair {Z, z} such that: that there is a keypair {Z, z} such that:
Z = X ? Y and z = (x + y) mod o (where o is the order of the group) Z = X ? Y and z = (x + y) mod o (where o is the order of the group)
The Result Combination Law states that we can define an operator ? The Result Combination Law states that we can define an operator ?
such that: such that:
(x ? E) ? (y ? E) = (z ? E) = (e ? Z). (x ? E) ? (y ? E) = (z ? E) = (e ? Z).
4.1. Application to Diffie Hellman (not normative)
For the Diffie Hellman system in a modular field p, o = p-1 and a ? b For the Diffie Hellman system in a modular field p, o = p-1 and a ? b
= a ? b = a.b = a ? b = a.b mod p.
Proof, Proof:
By definition, X = e^x mod p, Y = e^y mod p, Z = e^z mod p. By definition, X = e^x mod p, Y = e^y mod p, and Z = e^z mod p.
Therefore, Therefore,
Z = e^z mod p = e^x+y mod p = (e^xe^y) mod p = e^x mod p.e^y mod p = Z = e^z mod p = e^x+y mod p = (e^xe^y) mod p = e^x mod p.e^y mod p =
X.Y X.Y
A similar proof may be constructed for the operator ?. A similar proof may be constructed for the operator ?.
4.1.1. Application to Elliptic Curve systems 4.2. Multi-Party Key Generation
The Key Combination Law provides the basis for the Key Co-Generation
technique used to ensure that the cryptographic keys used in devices
connected to a Mesh profile are sufficiently random and have not been
compromised by malware or other 'backdoor' compromise to the machine
during or after manufacture.
For the Diffie Hellman system, the Key Combination law provides all
the mechanism needed to implement a Key Co-Generation mechanism. If
the Device key is {X, x}, the administration device can generate a
Co-Generation Key Pair {Y, y} and generate a Device Connection
Assertion for the final public key E calculated from knowledge of X
and Y alone. Passing the value y to the device (using a secure
channel) allows it to calculate the corresponding private key e
required to make use of the Device Connection Assertion.
This approach ensures that a party with knowledge of either x or y
but not both obtains no knowledge of e.
Section REF _Ref5309729 \w \h 5 describes the implementation of these
schemes in the Mesh
4.3. Multi-Party Decryption
The Key Combination Law and Result Combination Law provide the basis
for the Multi-Party Decryption technique used to support Mesh
Encryption Groups.
Section REF _Ref5309538 \w \h 6 describes the application of this
technique in the Mesh
4.4. Mutually Authenticated Key Exchange.
The Result Combination Law is used to provide a Key Exchange
mechanism that provides mutual authentication of the parties while
preserving forward secrecy.
4.5. Implementation
For elliptic curve cryptosystems, the operators ? and ? are point For elliptic curve cryptosystems, the operators ? and ? are point
addition. addition.
While the point addition function can be defined for any elliptic Implementing a robust Key Co-Generation for the Elliptic Curve
curve system, it is not necessary to implement point addition to Cryptography schemes described in [RFC7748] and [RFC8032] requires
support ECDH key agreement. some additional considerations to be addressed.
In particular, point multiplication using the Montgomery ladder o The secret scalar used in the EdDSA algorithm is calculated from
technique over Montgomery curves only operate on the x co-ordinate the private key using a digest function. It is therefore
and only require point doubling operations. For this reason, Ed448 necessary to specify the Key Co-Generation mechanism by reference
and Ed25519 are the preferred algorithms for key agreement even to operations on the secret scalar values rather than operations
though this is not their intended purpose. on the private keys.
4.2. Implementation for Ed25519 and Ed448 o The Montgomery Ladder traditionally used to perform X25519 and
X448 point multiplication does not require implementation of a
function to add two arbitrary points. While the steps required to
create such a function are fully constrained by the specification,
the means of satisfying the constraints is not.
4.5.1. Implementation for Ed25519 and Ed448
The data structures used to implement co-generation of public keys The data structures used to implement co-generation of public keys
are defined in the main Mesh Reference Guide. This document are defined in the main Mesh Reference Guide. This document
describes only the additional implementation details. describes only the additional implementation details.
Note that the 'private key' described in [RFC8032] is in fact a seed Note that the 'private key' described in [RFC8032] is in fact a seed
used to generate a 'secret scalar' value that is the value that has used to generate a 'secret scalar' value that is the value that has
the function of being the private key in the ECDH algorithm. the function of being the private key in the ECDH algorithm.
To provision a new public key to a device, the provisioning device: To provision a new public key to a device, the provisioning device:
skipping to change at page 6, line 28 skipping to change at page 8, line 38
5. Constructs the application device entry containing the private 5. Constructs the application device entry containing the private
key value m and encrypts under the device encryption key d. key value m and encrypts under the device encryption key d.
On receipt, the device may at its option use its knowledge of the On receipt, the device may at its option use its knowledge of the
secret scalar corresponding to d and m to calculate the application secret scalar corresponding to d and m to calculate the application
secret scalar a or alternatively maintain the two secrets separately secret scalar a or alternatively maintain the two secrets separately
and make use of the result combination law to perform private key and make use of the result combination law to perform private key
operations. operations.
4.3. Example: Provisioning the Confirmation Service 4.5.2. Implementation for X25519 and X448
While the point addition function can be defined for any elliptic
curve system, it is not necessary to implement point addition to
support ECDH key agreement.
In particular, point multiplication using the Montgomery ladder
technique over Montgomery curves only operate on the x co-ordinate
and only require point doubling operations.
For expediency, the current implementation of the Mesh reference code
uses the Edwards curves for both signature and encryption pending
announcement of platform support for both algorithms.
5. Multi-Party Key Generation
Multi-Party Key Generation is a capability that is used in the Mesh
to enable provisioning of application specific private key pairs to
connected devices without revealing any information concerning the
application private key of the device.
For example, Alice provisions the confirmation service to her watch.
The provisioning device could generate a signature key for the device
and encrypt it under the encryption key of the device. But this
means that we cannot attribute signatures to the watch with absolute
certainty as the provisioning device has had knowledge of the watch
signature key. Nor do we wish to use the device signature key for
the confirmation
service.
Multi-Party Key Generation allows an administration device to
provision a connected device with an application specific private key
that is specific to that application and no other such that the
application can determine the public key of the device but has no
knowledge of the private key.
Provisioning an application private key to a device requires the
administration device to:
o Generate a new application public key for the device.
o Construct and publish whatever application specific credentials
the device requires to use the application.
o Providing the information required to make use of the private key
to the device.
Note that while the administration device needs to know the device
application public key, it does not require knowledge of the device
application private key.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html [2].]]
Two party key pair generation.
5.1. Example: Provisioning the Confirmation Service
For example, Alice provisions the confirmation service to her watch. For example, Alice provisions the confirmation service to her watch.
The device profile of the watch specifies an Ed25519 signature key. The device profile of the watch specifies an Ed25519 signature key.
Note that for production use, Ed448 is almost certainly prefered but Note that for production use, Ed448 is almost certainly prefered but
Ed25519 has the advantage of more compact presentation. Ed25519 has the advantage of more compact presentation.
TBS: TBS:
The provisioning device could generate a signature key for the device The provisioning device could generate a signature key for the device
and encrypt it under the encryption key of the device. But this and encrypt it under the encryption key of the device. But this
skipping to change at page 7, line 21 skipping to change at page 10, line 47
The provisioning device encrypts the private key of the comanion The provisioning device encrypts the private key of the comanion
keypair under the encryption key of the device. keypair under the encryption key of the device.
TBS: TBS:
The provisioning device calculates the private key of the composite The provisioning device calculates the private key of the composite
keypair by adding the two private key values and verifies that scalar keypair by adding the two private key values and verifies that scalar
multiplication of the base point returns the composite public key multiplication of the base point returns the composite public key
value. value.
4.4. Implementation for X25519 and X448 6. Multi-Party Decryption
5. Recryption
A key limitation of most deployed messaging systems is that true end- A key limitation of most deployed messaging systems is that true end-
to-end confidentiality is only achieved for a limited set of to-end confidentiality is only achieved for a limited set of
communication patterns. Specifically, bilateral communications communication patterns. Specifically, bilateral communications
(Alice sends a message to Bob) or broadcast communications to a known (Alice sends a message to Bob) or broadcast communications to a known
set of recipients (Alice sends a message to Bob, Carol and Doug). set of recipients (Alice sends a message to Bob, Carol and Doug).
These capabilities do not support communication patterns where the These capabilities do not support communication patterns where the
set of recipients changes over time or is confidential. Yet such set of recipients changes over time or is confidential. Yet such
requirements commonly occur in situations such as sending a message requirements commonly occur in situations such as sending a message
to a mailing list whose membership isn't known to the sender, or to a mailing list whose membership isn't known to the sender, or
creating a spreadsheet whose readership is to be limited to creating a spreadsheet whose readership is to be limited to
authorized members of the 'accounting' team. authorized members of the 'accounting' team.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html [3].]]
Traditional End-to-End Encryption is static. Traditional End-to-End Encryption is static.
The mathematical approach that makes key co-generation possible may The mathematical approach that makes key co-generation possible may
be applied to support a public key encryption mode in which be applied to support a public key encryption mode in which
encryption is performed as usual but decryption requires the use of encryption is performed as usual but decryption requires the use of
multiple keys. This approach is variously described in the multiple keys. This approach is variously described in the
literature as distributed key generation and proxy re- literature as distributed key generation and proxy re-
encryption [Blaze98] . encryption [Blaze98] .
The approach specified in this document borrows aspects of both these The approach specified in this document borrows aspects of both these
techniques. This combined approach is called 'recryption'. Using techniques. This combined approach is called 'recryption'. Using
recryption allows a sender to send a message to a group of users recryption allows a sender to send a message to a group of users
whose membership is not known to the sender at the time the message whose membership is not known to the sender at the time the message
is sent and can change at any time. is sent and can change at any time.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html [4].]]
Recryption supports End-to-End Encryption in dynamic groups. Recryption supports End-to-End Encryption in dynamic groups.
Proxy re-encryption provides a technical capability that meets the Proxy re-encryption provides a technical capability that meets the
needs of such communication patterns. Conventional symmetric key needs of such communication patterns. Conventional symmetric key
cryptography uses a single key to encrypt and decrypt data. Public cryptography uses a single key to encrypt and decrypt data. Public
key cryptography uses two keys, the key used to encrypt data is key cryptography uses two keys, the key used to encrypt data is
separate from the key used to decrypt. Proxy re-encryption separate from the key used to decrypt. Proxy re-encryption
introduces a third key (the recryption key) that allows a party to introduces a third key (the recryption key) that allows a party to
permit an encrypted data packet to be decrypted using a different key permit an encrypted data packet to be decrypted using a different key
without permitting the data to be decrypted. without permitting the data to be decrypted.
The introduction of a recryption key permits end-to-end The introduction of a recryption key permits end-to-end
confidentiality to be preserved when a communication pattern requires confidentiality to be preserved when a communication pattern requires
that some part of the communication be supported by a service. that some part of the communication be supported by a service.
The introduction of a third type of key, the recryption key permits The introduction of a third type of key, the recryption key permits
two new roles to be established, that of an administrator and two new roles to be established, that of an administrator and
recryption service. There are thus four parties: recryption service. There are thus four parties:
Administrator Administrator Holder of Decryption Key, Creator of Recryption Keys
Holder of Decryption Key, Creator of Recryption Keys
Sender
Holder of Encryption Key
Recryption Service
Holder of Recryption keys Sender Holder of Encryption Key
Receiver Recryption Service Holder of Recryption keys
Holder of personal decryption key Receiver Holder of personal decryption key
The communication between these parties is shown in Figure X below: The communication between these parties is shown in Figure X below:
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html [5].]]
Mesh/Recrypt Parties Mesh/Recrypt Parties
The information stored at the recryption service is necessary but not The information stored at the recryption service is necessary but not
sufficient to decrypt the message. Thus, no disclosure of the sufficient to decrypt the message. Thus, no disclosure of the
message plaintext occurs even in the event that an attacker gains message plaintext occurs even in the event that an attacker gains
full knowledge of all the information stored by the recryption full knowledge of all the information stored by the recryption
service. service.
5.1. Mechanism 6.1. Mechanism
The mechanism used to support recryption is the same as the mechanism The mechanism used to support recryption is the same as the mechanism
used to support key co-generation except that this time, instead of used to support key co-generation except that this time, instead of
combining two keys to create one, the private component of a combining two keys to create one, the private component of a
decryption key (i.e. the private key) is split into two parts, a decryption key (i.e. the private key) is split into two parts, a
recryption key and a decryption key. recryption key and a decryption key.
Recall that the key combination law for Diffie Hellman crypto-systems Recall that the key combination law for Diffie Hellman crypto-systems
states that we can add two private keys to get a third. It follows states that we can add two private keys to get a third. It follows
that we can split the private key portion of a keypair {G, g} into that we can split the private key portion of a keypair {G, g} into
skipping to change at page 9, line 22 skipping to change at page 13, line 8
= g - r mod o, where o is the order of the group. = g - r mod o, where o is the order of the group.
Having generated x, y, we can use these to perform private key Having generated x, y, we can use these to perform private key
agreement operations on a public key E and then use the result agreement operations on a public key E and then use the result
combination law to obtain the same result that we would have obtained combination law to obtain the same result that we would have obtained
using g. using g.
One means of applying this mechanism to recryption would be to One means of applying this mechanism to recryption would be to
generate a different random value x for each member of the group and generate a different random value x for each member of the group and
store it at the recryption service and communicate the value y to the store it at the recryption service and communicate the value y to the
member via a secure channel. Applying this approach we can clearly member via a secure channel. Applying this approach, we can clearly
see that the recryption service gains no information about the value see that the recryption service gains no information about the value
of the private key since the only information it holds is a random of the private key since the only information it holds is a random
number which could have been generated without any knowledge of the number which could have been generated without any knowledge of the
group private key. group private key.
[RFC8032] requires that implementations derive the scalar secret by [RFC8032] requires that implementations derive the scalar secret by
taking a cryptographic digest of the private key. This means that taking a cryptographic digest of the private key. This means that
either the client or the service must use a non-compliant either the client or the service must use a non-compliant
implementation. Given this choice, it is preferable to require that implementation. Given this choice, it is preferable to require that
the non-standard implementation be required at the service rather the non-standard implementation be required at the service rather
than the client. This limits the scope of the non-conformant key than the client. This limits the scope of the non-conformant key
derivation approach to the specialist recryption service and ensures derivation approach to the specialist recryption service and ensures
that the client enforce the requirement to generate the private key that the client enforce the requirement to generate the private key
component by means of a digest. component by means of a digest.
5.2. Implementation 6.2. Implementation
Implementation of recryption in the Mesh has four parts: Implementation of recryption in the Mesh has four parts:
o Creation and management of the recryption group. o Creation and management of the recryption group.
o Provisioning of members to a recryption group. o Provisioning of members to a recryption group.
o Message encryption. o Message encryption.
o Message decryption. o Message decryption.
skipping to change at page 10, line 19 skipping to change at page 14, line 5
multiple Mesh users or transferred from one user to another multiple Mesh users or transferred from one user to another
without requiring specification of a separate management protocol without requiring specification of a separate management protocol
to support these operations. to support these operations.
o The recryption account address can be used by Mesh applications o The recryption account address can be used by Mesh applications
such as group messaging, conferencing, etc. as a contact address. such as group messaging, conferencing, etc. as a contact address.
o The contact request service can be used to notify members that o The contact request service can be used to notify members that
they have been granted membership in the group. they have been granted membership in the group.
5.2.1. Group Creation 6.2.1. Group Creation
Creation of a Recryption group requires the steps of: Creation of a Recryption group requires the steps of:
o Generating the recryption group key pair o Generating the recryption group key pair
o Creating the recryption group account o Creating the recryption group account
o Generating administrator record for each administrator. o Generating administrator record for each administrator.
o Publishing the administrator records to the recryption catalog. o Publishing the administrator records to the recryption catalog.
Note that in principle, we could make use of the key combination law Note that in principle, we could make use of the key combination law
to enable separation of duties controls on administrators so that to enable separation of duties controls on administrators so that
provisioning of members required multiple administrators to provisioning of members required multiple administrators to
participate in the process. This is left to future versions. participate in the process. This is left to future versions.
5.2.2. Provisioning a Member 6.2.2. Provisioning a Member
To provision a user as a member of the recryption group, the To provision a user as a member of the recryption group, the
administrator requires their current recryption profile. The administrator requires their current recryption profile. The
administrator MAY obtain this by means of a contact service request. administrator MAY obtain this by means of a contact service request.
As with any contact service request, this request is subject to As with any contact service request, this request is subject to
access control and MAY require authorization by the intended user access control and MAY require authorization by the intended user
before the provisioning can proceed. before the provisioning can proceed.
Having obtained the user's recryption profile, the administration Having obtained the user's recryption profile, the administration
tool generates a decryption private key for the user and encrypts it tool generates a decryption private key for the user and encrypts it
under the member's key to create the encrypted decryption key entry. under the member's key to create the encrypted decryption key entry.
The administration tool then computes the secret scalar from the The administration tool then computes the secret scalar from the
private key and uses this together with the secret scalar of the private key and uses this together with the secret scalar of the
recryption group to compute the recryption key for the member. This recryption group to compute the recryption key for the member. This
value and the encrypted decryption key entry are combined to form the value and the encrypted decryption key entry are combined to form the
recryption group membership record which is published to the catalog. recryption group membership record which is published to the catalog.
5.2.3. Message Encryption and Decryption 6.2.3. Message Encryption and Decryption
Encryption of a messages makes use of DARE Message in exactly the Encryption of a messages makes use of DARE Message in exactly the
same manner as any other encryption. The sole difference being that same manner as any other encryption. The sole difference being that
the recipient entry for the recryption operation MUST specify the the recipient entry for the recryption operation MUST specify the
recryption group address an not just the key fingerprint. This recryption group address an not just the key fingerprint. This
allows the recipient to determine which recryption service to contact allows the recipient to determine which recryption service to contact
to perform the recryption operation. to perform the recryption operation.
To decrypt a message, the recipient makes an authenticated recryption To decrypt a message, the recipient makes an authenticated recryption
request to the specified recryption service specifying: request to the specified recryption service specifying:
o The recipient entry to be used for decryption o The recipient entry to be used for decryption
o The fingerprint of the decryption key(s) the device would like to o The fingerprint of the decryption key(s) the device would like to
make use of. make use of.
o Whether or not the encrypted decryption key entry should be o Whether or not the encrypted decryption key entry should be
returned. returned.
[[This figure is not viewable in this format. The figure is
available at http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html [6].]]
Two key decryption.
The recryption service searches the catalog for the corresponding The recryption service searches the catalog for the corresponding
recryption group to find a matching entry. If found and if the recryption group to find a matching entry. If found and if the
recipient and proposed decryption key are dully authorized for the recipient and proposed decryption key are dully authorized for the
purpose, the service performs the key agreement operation using the purpose, the service performs the key agreement operation using the
recryption key specified in the entry and returns the result to the recryption key specified in the entry and returns the result to the
recipient. recipient.
The recipient then decrypts the recryption data entry using its The recipient then decrypts the recryption data entry using its
device decryption key and uses the group decryption key to calculate device decryption key and uses the group decryption key to calculate
the other half of the result. The two halves of the result are then the other half of the result. The two halves of the result are then
added to obtain the key agreement value that is then used to decrypt added to obtain the key agreement value that is then used to decrypt
the message. the message.
5.3. Example: Messaging group 6.3. Example: Messaging group
Alice creates a recryption group. The group encryption and signature Alice creates a recryption group. The group encryption and signature
key parameters are: key parameters are:
TBS: TBS:
To verify the proper function of the group, Alice creates a test To verify the proper function of the group, Alice creates a test
message and encrypts it under the group key. message and encrypts it under the group key.
TBS: TBS:
skipping to change at page 13, line 12 skipping to change at page 17, line 5
TBS: TBS:
The key agreement value is obtained by point addition of the The key agreement value is obtained by point addition of the
recryption and decryption values: recryption and decryption values:
TBS: TBS:
This value allows the test message to be decrypted. This value allows the test message to be decrypted.
6. Security Considerations 7. Mutually Authenticated Key Agreement
Diffie Hellman key agreement using the authenticated public keys of
the principals provides mutual authentication of those principals.
For example, if Alice's key pair is {a, A} and Bob's key pair is {b,
B}, the Diffie Hellman key agreement value DH (a, B) = DH (b, A) can
only be generated from the public information if a or b is known.
The chief disadvantage of this approach is that it only allows Alice
and Bob to establish a single shared secret that will never vary and
does not provide forward secrecy. To avoid this, cryptographic
protocols usually perform the key agreement against an ephemeral key
and either accept that the client key is not authenticated or perform
multiple key agreements and combine the results.
Using the Result Combination Law allows a key agreement mechanism to
combine the benefits of mutual authentication with the use of
ephemeral keys without the need for multiple private key operations
or additional round trips.
In its simplest form, the key exchange has two parties which we refer
to as the client and the server. The client being the party that
initiates the protocol exchange and the server being the party that
responds. Let the public key pair of the client be {a, A} and that
of the server {b, B}.
Two versions of the key agreement mechanism are specified:
Client ephemeral The client contributes an ephemeral key pair {n_A,
N_A}. The effective public key of the client is A ? N_A.
The server uses its public key B.
The key agreement value is DH (a + n_A, B) = DH (b, A ? N_A)
Dual ephemeral The client contributes an ephemeral key pair {n_A,
N_A}. The effective public key of the client is A ? N_A.
The server contributes an ephemeral key pair {n_B, N_B}. The
effective public key of the client is B ? N_B.
The key agreement value is DH (a + n_A, B ? N_B) = DH (b + n_B, A
? N_A)
The function of the ephemeral key is effectively that of a nonce but
it is shared with the counter-party as a public key value.
The dual ephemeral approach has the advantage that it limits the
scope for side channel attacks as both sides have contributed unknown
information to the key agreement value. The disadvantage of this
approach is that the key agreement value can only be calculated after
the server has provided its ephemeral.
Implementations MAY take advantage of the result combination law to
enable private key operations involving the authenticated key (or a
contribution to it) to be performed in trustworthy hardware.
An advantage of this key exchange mechanism over the traditional TLS
key exchange approach is that no signature operation is involved,
thus ensuring that either party can repudiate the exchange and thus
the claim that they were in communication.
The master secret is calculated from the key agreement value in the
usual fashion. For ECDH algorithms, this comprises the steps of
converting the key agreement value to an octet string which forms the
input to a Key Derivation Function.
8. Security Considerations
The security considerations for use and implementation of Mesh The security considerations for use and implementation of Mesh
services and applications are described in the Mesh Security services and applications are described in the Mesh Security
Considerations guide [draft-hallambaker-mesh-security] . Considerations guide [draft-hallambaker-mesh-security] .
7. IANA Considerations 9. IANA Considerations
All the IANA considerations for the Mesh documents are specified in This document requires no IANA actions.
this document
8. Acknowledgements 10. Acknowledgements
9. Examples A list of people who have contributed to the design of the Mesh is
presented in [draft-hallambaker-mesh-architecture] .
9.1. Key Combination 11. Examples
9.1.1. Ed25519 11.1. Key Combination
9.1.2. Ed448 11.1.1. Ed25519
9.1.3. X25519 11.1.2. Ed448
9.1.4. X448 11.1.3. X25519
11.1.4. X448
9.2. Group Encryption 11.2. Group Encryption
9.2.1. X25519 11.2.1. X25519
9.2.2. X448 11.2.2. X448
10. References 12. References
10.1. Normative References 12.1. Normative References
[AES-GCM] Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", November
2007.
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh 3.0 Part I:
Architecture Guide", draft-hallambaker-mesh-
architecture-08 (work in progress), July 2019.
[draft-hallambaker-mesh-security] [draft-hallambaker-mesh-security]
"[Reference Not Found!]". Hallam-Baker, P., "Mathematical Mesh Part VII: Security
Considerations", draft-hallambaker-mesh-security-00 (work
in progress), April 2019.
[FIPS197] NIST, "Advanced Encryption Standard (AES)", November 2001.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997. DOI 10.17487/RFC2119, March 1997.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
September 2002.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017. DOI 10.17487/RFC8032, January 2017.
10.2. Informative References [RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018.
[Blaze98] "[Reference Not Found!]". [SHA-2] NIST, "Secure Hash Standard", August 2015.
[draft-hallambaker-mesh-architecture] [SHA-3] Dworkin, M., "SHA-3 Standard: Permutation-Based Hash and
Hallam-Baker, P., "Mathematical Mesh Part I: Architecture Extendable-Output Functions", August 2015.
Guide", draft-hallambaker-mesh-architecture-06 (work in
progress), August 2018. [SHA-3-Derived]
Kelsey, J., Chang, S., and R. Perlner, "SHA-3 Derived
Functions: cSHAKE, KMAC, TupleHash and ParallelHash
SHARE", December 2016.
12.2. Informative References
[Blaze98] "[Reference Not Found!]".
[draft-hallambaker-mesh-developer] [draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", draft-hallambaker-mesh-developer-07 (work Implementation", draft-hallambaker-mesh-developer-08 (work
in progress), April 2018. in progress), April 2019.
10.3. URIs 12.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh- [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html cryptography.html
[2] http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html
[3] http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html
[4] http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html
[5] http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html
[6] http://mathmesh.com/Documents/draft-hallambaker-mesh-
cryptography.html
Author's Address Author's Address
Phillip Hallam-Baker Phillip Hallam-Baker
Email: phill@hallambaker.com Email: phill@hallambaker.com
 End of changes. 71 change blocks. 
146 lines changed or deleted 436 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/