Internet DRAFT - draft-hallambaker-mesh-advanced
draft-hallambaker-mesh-advanced
Network Working Group P. Hallam-Baker
Internet-Draft Comodo Group Inc.
Intended status: Informational August 31, 2018
Expires: March 4, 2019
Mathematical Mesh Part III: Advanced Cryptographic Services
draft-hallambaker-mesh-advanced-00
Abstract
The Mathematical Mesh ?The Mesh? is an infrastructure that
facilitates the exchange of configuration and credential data between
multiple user devices and provides end-to-end security. This
document describes the advanced encryption services supported by the
Mesh.
This document is also available online at
http://mathmesh.com/Documents/draft-hallambaker-mesh-advanced.html
[1] .
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 4, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Hallam-Baker Expires March 4, 2019 [Page 1]
Internet-Draft Mathematical Mesh Reference August 2018
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Defined Terms . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Related Specifications . . . . . . . . . . . . . . . . . 3
2.4. Implementation Status . . . . . . . . . . . . . . . . . . 3
3. Secret Splitting . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Example: Securing a recovery record . . . . . . . . . . . 4
4. Key Co-Generation . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Application to Elliptic Curve systems . . . . . . . . 7
4.2. Implementation for Ed25519 and Ed 448 . . . . . . . . . . 7
4.3. Example: Provisioning the Confirmation Service . . . . . 8
5. Recryption . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Implementation . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Group Creation . . . . . . . . . . . . . . . . . . . 12
5.2.2. Provisioning a Member . . . . . . . . . . . . . . . . 12
5.2.3. Message Encryption and Decryption . . . . . . . . . . 13
5.3. Example: Messaging group . . . . . . . . . . . . . . . . 13
6. Quantum Resistant Signatures. . . . . . . . . . . . . . . . . 15
6.1. Example: Creating a Quantum Resistant Signature
Fingerprint . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. Appendix A: Prime Values for Secret Sharing . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 18
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
One of the core goals of the Mesh is to move the state of the art in
commercial cryptography beyond that achieved in the 1990s when PKIX,
S/MIME and OpenPGP were first developed. While each of these
infrastructures and protocols has been subject to incremental
improvement, none has seen widespread adoption of new cryptographic
approaches.
Hallam-Baker Expires March 4, 2019 [Page 2]
Internet-Draft Mathematical Mesh Reference August 2018
This document describes the application of four technologies which
have been discussed in the cryptographic literature for many decades
but have not (yet) been applied to standards-based network protocols:
o Secret Splitting
o Recryption
o Key Co-Generation
o Quantum Resistant Signatures.
2. Definitions
This section presents the related specifications and standard, the
terms that are used as terms of art within the documents and the
terms used as requirements language.
2.1. Requirements Language
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] .
2.2. Defined Terms
The terms of art used in this document are described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] .
2.3. Related Specifications
The architecture of the Mathematical Mesh is described in the Mesh
Architecture Guide [draft-hallambaker-mesh-architecture] . The Mesh
documentation set and related specifications are described in this
document.
2.4. Implementation Status
The implementation status of the reference code base is described in
the companion document [draft-hallambaker-mesh-developer] .
3. Secret Splitting
The secret sharing mechanism used is based on the method of Shamir
[Shamir79] .
The mechanism described allows creation of up to 16 shares with a
threshold of between 1 and 16 shares.
Hallam-Baker Expires March 4, 2019 [Page 3]
Internet-Draft Mathematical Mesh Reference August 2018
To share a secret of L bits with a threshold of n we first construct
f(x) a polynomial of degree n in the modular field p:
f(x) = a0 + a1.x + a2.x2 + ? an.xn
where:
L Is the length of the secret in bits rounded up to the nearest
multiple of 32.
n Is the threshold, the number of shares required to reconstitute
the secret.
a0 Is the integer representation of the secret to be shared.
a1 ? an Are randomly chosen integers less than p
p Is the largest prime that is smaller than 2(L+1).
For L=128, p = 2^129-25.
The values of the key shares are the values f(1), f(2),? f(n).
Conversion of octet sequences to integer representation uses network
byte order (i.e. big-endian). The first byte of the octet stream is
the most significant 8 bits of the integer representation and the
last byte is the least significant 8 bits.
Key shares are encoded as an octet sequence:
o Bits 4-7 of the first byte specify the threshold value.
o Bits 0-3 of the first byte specify the x value
o The remaining bytes specify the key share value in network byte
order.
For an explanation of how to recover the master secret from the key
shares, look up Lagrange basis polynomials on the Web.
3.1. Example: Securing a recovery record
Alice decides to protect her recovery record using a set of five key
shares, three of which will be required to recover the key.
Alice's master secret is
Hallam-Baker Expires March 4, 2019 [Page 4]
Internet-Draft Mathematical Mesh Reference August 2018
{Alice.RecoveryMaster}
Figure 1
The master secret is converted to an integer applying network byte
order conventions. Since the master secret is 128 bits, it is
guaranteed to be smaller than the modulus. The resulting value
becomes the polynomial value a0.
Since a threshold of three shares is required, we will need a third
order polynomial. The co-efficients of the polynomial a1, a2, a3 are
random numbers smaller than the modulus:
{Alice.RecoveryPolynomial}
Figure 2
The master secret is the value f(0). The key shares are the values
f(1), f(2)...f(5):
{Alice.RecoverySharesHex}
Figure 3
The key shares in user (Base32) encoding are:
{Alice.RecoveryShare0Hex}
Figure 4
To recover the value f(0) from any three shares, we need to fit a
polynomial curve to the three points and use it to calculate the
value at x=0.
We use the Lagrange polynomial basis method:
{Alice.RecoveryLagrange}
Figure 5
4. Key Co-Generation
Public Key Co-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.
Hallam-Baker Expires March 4, 2019 [Page 5]
Internet-Draft Mathematical Mesh Reference August 2018
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.
Public Key Co-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.
4.1. Mechanism
The 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.
The Key Combination law states that we can define an operator ? such
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)
The Result Combination Law states that we can define an operator ?
such that:
(x ? E) ? (y ? E) = (z ? E) = (e ? Z).
Hallam-Baker Expires March 4, 2019 [Page 6]
Internet-Draft Mathematical Mesh Reference August 2018
For the Diffie Hellman system in a modular field p, o = p-1 and a ? b
= a ? b = a.b
Proof,
By definition, X = ex mod p, Y = ey mod p, Z = ez mod p.
Therefore,
Z = ez mod p = ex+y mod p = (exey) mod p = ex mod p.ey mod p = X.Y
A similar proof may be constructed for the operator ?.
4.1.1. Application to Elliptic Curve systems
For elliptic curve cryptosystems, the operators ? and ? are point
addition.
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 this reason, Ed448
and Ed25519 are the preferred algorithms for key agreement even
though this is not their intended purpose.
4.2. Implementation for Ed25519 and Ed 448
The data structures used to implement co-generation of public keys
are defined in the main Mesh Reference Guide. This document
describes only the additional implementation details.
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
the function of being the private key in the ECDH algorithm.
To provision a new public key to a device, the provisioning device:
1. Obtains the device profile of the device(s) to be provisioned to
determine the type of key to perform co-generation for. Let the
device {public, private} key be {D, d}.
2. Generates a private key m with the specified number of bytes (32
or 57].
3. Calculates the corresponding public key M.
Hallam-Baker Expires March 4, 2019 [Page 7]
Internet-Draft Mathematical Mesh Reference August 2018
4. Calculates the Application public key A = D+M where + is point
addition.
5. Constructs the application device entry containing the private
key value m and encrypts under the device encryption key d.
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 a or alternatively maintain the two secrets separately
and make use of the result combination law to perform private key
operations.
4.3. Example: Provisioning the Confirmation Service
For example, Alice provisions the confirmation service to her watch.
The device profile of the watch specifies an Ed448 signature key:
{Alice.CogenDeviceProfile}
Figure 6
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.
Instead, the provisioning device generates a companion keypair. A
random seed is generated.
{Alice.CoGenerationPrivateSeed}
Figure 7
A key derrivation function (HKDF) is used to derrive a 256 bit key.
{Alice.CoGenerationPrivate2}
Figure 8
The provisioning device can calculate the public key of the composite
keypair by adding the public keys of the device profile and the
companion public key:
{Alice.CoGenerationPublicComp}
Figure 9
Hallam-Baker Expires March 4, 2019 [Page 8]
Internet-Draft Mathematical Mesh Reference August 2018
The provisioning device encrypts the private key of the comanion
keypair under the encryption key of the device.
{Alice.CoGenerationPrivateEncrypted}
Figure 10
The provisioning device calculates the private key of the composite
keypair by adding the two private key values and verifies that scalar
multiplication of the base point returns the composite public key
value.
5. Recryption
A key limitation of most deployed messaging systems is that true end-
to-end confidentiality is only achieved for a limited set of
communication patterns. Specifically, bilateral communications
(Alice sends a message to Bob) or broadcast communications to a known
set of recipients (Alice sends a message to Bob, Carol and Doug).
These capabilities do not support communication patterns where the
set of recipients changes over time or is confidential. Yet such
requirements commonly occur in situations such as sending a message
to a mailing list whose membership isn?t known to the sender, or
creating a spreadsheet whose readership is to be limited to
authorized members of the ?accounting? team.
Traditional End-to-End Encryption is static.
The mathematical approach that makes key co-generation possible may
be applied to support a public key encryption mode in which
encryption is performed as usual but decryption requires the use of
multiple keys. This approach is variously described in the
literature as distributed key generation and proxy re-
encryption [Blaze98] .
The approach specified in this document borrows aspects of both these
techniques. This combined approach is called 'recryption'. Using
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
is sent and can change at any time.
Recryption supports End-to-End Encryption in dynamic groups.
Proxy re-encryption provides a technical capability that meets the
needs of such communication patterns. Conventional symmetric key
cryptography uses a single key to encrypt and decrypt data. Public
key cryptography uses two keys, the key used to encrypt data is
separate from the key used to decrypt. Proxy re-encryption
Hallam-Baker Expires March 4, 2019 [Page 9]
Internet-Draft Mathematical Mesh Reference August 2018
introduces a third key (the recryption key) that allows a party to
permit an encrypted data packet to be decrypted using a different key
without permitting the data to be decrypted.
The introduction of a recryption key permits end-to-end
confidentiality to be preserved when a communication pattern requires
that some part of the communication be supported by a service.
The introduction of a third type of key, the recryption key permits
two new roles to be established, that of an administrator and
recryption service. There are thus four parties:
Administrator
Holder of Decryption Key, Creator of Recryption Keys
Sender
Holder of Encryption Key
Recryption Service
Holder of Recryption keys
Receiver
Holder of personal decryption key
The communication between these parties is shown in Figure X below:
Mesh/Recrypt Parties
The information stored at the recryption service is necessary but not
sufficient to decrypt the message. Thus, no disclosure of the
message plaintext occurs even in the event that an attacker gains
full knowledge of all the information stored by the recryption
service.
5.1. 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
combining two keys to create one, the private component of a
decryption key (i.e. the private key) is split into two parts, a
recryption key and a decryption key.
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
Hallam-Baker Expires March 4, 2019 [Page 10]
Internet-Draft Mathematical Mesh Reference August 2018
that we can split the private key portion of a keypair {G, g} into
two parts by choosing a random number that is less than the order of
the Diffie-Hellman group to be our first key x. Our second key is y
= g - r mod o, where o is the order of the group.
Having generated x, y, we can use these to perform private key
agreement operations on a public key E and then use the result
combination law to obtain the same result that we would have obtained
using g.
One means of applying this mechanism to recryption would be to
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
member via a secure channel. Applying this approach we can clearly
see that the recryption service gains no information about the value
of the private key since the only information it holds is a random
number which could have been generated without any knowledge of the
group private key.
[RFC8032] requires that implementations derive the scalar secret by
taking a cryptographic digest of the private key. This means that
either the client or the service must use a non-compliant
implementation. Given this choice, it is preferable to require that
the non-standard implementation be required at the service rather
than the client. This limits the scope of the non-conformant key
derivation approach to the specialist recryption service and ensures
that the client enforce the requirement to generate the private key
component by means of a digest.
5.2. Implementation
Implementation of recryption in the Mesh has four parts:
o Creation and management of the recryption group.
o Provisioning of members to a recryption group.
o Message encryption.
o Message decryption.
These operations are all performed using the same catalog and
messaging infrastructure provided by the Mesh for other purposes.
Each recryption group has its own independent Mesh account. This has
many advantages:
Hallam-Baker Expires March 4, 2019 [Page 11]
Internet-Draft Mathematical Mesh Reference August 2018
o Administration of the recryption group may be spread across
multiple Mesh users or transferred from one user to another
without requiring specification of a separate management protocol
to support these operations.
o The recryption account address can be used by Mesh applications
such as group messaging, conferencing, etc. as a contact address.
o The contact request service can be used to notify members that
they have been granted membership in the group.
5.2.1. Group Creation
Creation of a Recryption group requires the steps of:
o Generating the recryption group key pair
o Creating the recryption group account
o Generating administrator record for each administrator.
o Publishing the administrator records to the recryption catalog.
Note that in principle, we could make use of the key combination law
to enable separation of duties controls on administrators so that
provisioning of members required multiple administrators to
participate in the process. This is left to future versions.
5.2.2. Provisioning a Member
To provision a user as a member of the recryption group, the
administrator requires their current recryption profile. The
administrator MAY obtain this by means of a contact service request.
As with any contact service request, this request is subject to
access control and MAY require authorization by the intended user
before the provisioning can proceed.
Having obtained the user's recryption profile, the administration
tool generates a decryption private key for the user and encrypts it
under the member's key to create the encrypted decryption key entry.
The administration tool then computes the secret scalar from the
private key and uses this together with the secret scalar of the
recryption group to compute the recryption key for the member. This
value and the encrypted decryption key entry are combined to form the
recryption group membership record which is published to the catalog.
Hallam-Baker Expires March 4, 2019 [Page 12]
Internet-Draft Mathematical Mesh Reference August 2018
5.2.3. Message Encryption and Decryption
Encryption of a messages makes use of DARE Message in exactly the
same manner as any other encryption. The sole difference being that
the recipient entry for the recryption operation MUST specify the
recryption group address an not just the key fingerprint. This
allows the recipient to determine which recryption service to contact
to perform the recryption operation.
To decrypt a message, the recipient makes an authenticated recryption
request to the specified recryption service specifying:
o The recipient entry to be used for decryption
o The fingerprint of the decryption key(s) the device would like to
make use of.
o Whether or not the encrypted decryption key entry should be
returned.
The recryption service searches the catalog for the corresponding
recryption group to find a matching entry. If found and if the
recipient and proposed decryption key are dully authorized for the
purpose, the service performs the key agreement operation using the
recryption key specified in the entry and returns the result to the
recipient.
The recipient then decrypts the recryption data entry using its
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
added to obtain the key agreement value that is then used to decrypt
the message.
5.3. Example: Messaging group
Alice creates a recryption group. The group encryption and signature
key parameters are:
{Alice.RecryptGroup}
Figure 11
To verify the proper function of the group, Alice creates a test
message and encrypts it under the group key.
Hallam-Baker Expires March 4, 2019 [Page 13]
Internet-Draft Mathematical Mesh Reference August 2018
{Alice.RecryptMessagePlaintext}
{Alice.RecryptMessageCiphertext}
Figure 12
Alice decides to add Bob to the group. Bob's recryption profile is:
{Bob.RecryptGroup}
Figure 13
Alice generates a recryption/decryption key entry. The recryption
key is a random value smaller than the modulus:
{bob.RecryptRecryptionKey}
Figure 14
The decryption key is group private encryption key minus the
recryption key (mod p):
{bob.RecryptDecryptionKey}
Figure 15
The Recryption entry consists of Bob's address, the recryption key
and the decryption key encrypted under Bob's encryption key:
{bob.RecryptRecryptionEntry}
Figure 16
Note that the only information available to the server is a random
number and a encrypted value only Bob can read. It is therefore
impossible for compromise of the service to cause disclosure of any
information encrypted under the group key unless Bob's private key is
also compromised.
The group administration tool creates a notification request to tell
Bob that he has been made a member of the new group and signs it
using the group signature key. The recryption entry and the
notification are then sent to the recryption service:
{bob.RecryptRecryptionCreateEntry}
Figure 17
Hallam-Baker Expires March 4, 2019 [Page 14]
Internet-Draft Mathematical Mesh Reference August 2018
The notification message contains a link to the test message. When
he accepts membership of the group, Bob clicks on the link to test
that his membership has been fully provisioned. Providing an
explicit test mechanism avoids the problem that might otherwise occur
in which the message spool fills up with test messages being posted.
Bob's Web browser requests the recryption data for the test message.
The request is authenticated and encrypted under Bob's device keys.
The plaintext of the message is:
{bob.RecryptRecryptionRequest}
Figure 18
The plaintext of the response contains the additional information
Bob's Web browser needs to complete the decryption process:
{bob.RecryptRecryptionResponse}
Figure 19
The Web browser decrypts the private key and uses it to calculate the
decryption value:
{bob.RecryptDecryptionValue}
Figure 20
The key agreement value is obtained by point addition of the
recryption and decryption values:
{bob.RecryptKeyAgreementValue}
Figure 21
This value allows the test message to be decrypted.
6. Quantum Resistant Signatures.
Quantum computing has made considerable advances over the past decade
and the field has now reached the point where a machine weighing many
tons can apply Shor's algorithm to factor numbers as large as 35
before decoherence occurs.
Should construction of a large-scale device prove practical, it will
in principle be possible to break all of the public key cryptosystems
currently in use. While public key cryptosystems that resist quantum
cryptanalysis are currently in development, none has yet reached a
Hallam-Baker Expires March 4, 2019 [Page 15]
Internet-Draft Mathematical Mesh Reference August 2018
sufficient state of maturity for the field to reach consensus that
they are resistant to ordinary cryptanalysis, let alone offer a
replacement.
The consequence of successful quantum cryptanalysis for encryption
systems is that all material encrypted under existing public key
systems could be decrypted by a quantum capable attacker. Nor is
mitigation of this consequence practical since it is not the adoption
of new cryptographic algorithms that make a system more secure, it is
the elimination of weak options that provides improvement.
The Mesh does not currently provide an infrastructure that is Quantum
Resistant but could in principle be used as the basis for deploying a
Needham-Schroeder style symmetric key infrastructure or a future PKI
based on an as yet undecided quantum cryptanalysis resistant public
key algorithm.
Mesh profiles MAY include a Quantum Resistant Signature Fingerprint
(QRSF). This contains the UDF fingerprint of an XMSS signature
public key [RFC8391] together with the parameters used to derive the
private key set for the public key from a 256 bit master secret.
Should it ever become necessary to make use of the QRSF, the user
first recovers the master secret from whatever archival mechanism was
used to protect it. The use of secret sharing to protect the secret
is RECOMMENDED. The master secret is then used to reconstruct the
set of private keys from which the public key set is reconstructed.
The profile owner can now authenticate themselves by means of their
XMSS public key.
6.1. Example: Creating a Quantum Resistant Signature Fingerprint
Alice decides to add a QRSF to her Mesh Profile. She creates a 256
bit master secret.
{Alice.QuantumMaster}
Figure 22
To enable recovery of the master key, Alice creates five keyshares
with a quorum of three:
{Alice.QuantumShares}
Figure 23
Alice uses the master secret to derrive her private key values:
Hallam-Baker Expires March 4, 2019 [Page 16]
Internet-Draft Mathematical Mesh Reference August 2018
{Alice.QuantumXMSSPrivate}
Figure 24
These values are used to generate the public key value:
{Alice.QuantumXMSSPublic}
Figure 25
The QRSF contains the UDF fingerprint of the public key value plus
the XMSS parameters:
{Alice.QuantumXMSSUDF}
Figure 26
Alice adds the QRSF to her profile and publishes it to a Mesh Service
that is enrolled in at least one multi-party notary scheme.
7. Security Considerations
TBS
8. IANA Considerations
All the IANA considerations for the Mesh documents are specified in
this document
9. Acknowledgements
Thanks are due to Viktor Dukhovni, Damian Weber and an anonymous
member of the cryptography@metzdowd.com list for assisting in the
compilation of the table of prime values.
10. Appendix A: Prime Values for Secret Sharing
The following are the prime values to be used for sharing secrets of
up to 512 bits.
If it is necessary to share larger secrets, the corresponding prime
may be found by applying the formula:
2^(n+1) - (1 SHL (n+1)) - B(1 SHL (n+1))
Hallam-Baker Expires March 4, 2019 [Page 17]
Internet-Draft Mathematical Mesh Reference August 2018
+----------------+--------------+
| Number of bits | Prime |
+----------------+--------------+
| 32 | 2^33 - 9 |
| 64 | 2^65 - 49 |
| 96 | 2^97 - 141 |
| 128 | 2^129 - 25 |
| 160 | 2^161 - 159 |
| 192 | 2^193 - 31 |
| 224 | 2^225 - 49 |
| 256 | 2^257 - 93 |
| 288 | 2^289 - 493 |
| 320 | 2^321 - 9 |
| 352 | 2^353 - 139 |
| 384 | 2^385 - 265 |
| 416 | 2^417 - 1029 |
| 448 | 2^449 - 241 |
| 480 | 2^481 - 273 |
| 512 | 2^513 - 445 |
+----------------+--------------+
Table 1
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017.
11.2. Informative References
[Blaze98] "[Reference Not Found!]".
[draft-hallambaker-mesh-architecture]
Hallam-Baker, P., "Mathematical Mesh: Architecture",
draft-hallambaker-mesh-architecture-05 (work in progress),
August 2018.
[draft-hallambaker-mesh-developer]
Hallam-Baker, P., "Mathematical Mesh: Reference
Implementation", draft-hallambaker-mesh-developer-07 (work
in progress), April 2018.
Hallam-Baker Expires March 4, 2019 [Page 18]
Internet-Draft Mathematical Mesh Reference August 2018
[RFC8391] Huelsing, A., Butin, D., Gazdag, S., Rijneveld, J., and A.
Mohaisen, "XMSS: eXtended Merkle Signature Scheme",
RFC 8391, DOI 10.17487/RFC8391, May 2018.
[Shamir79]
"[Reference Not Found!]".
11.3. URIs
[1] http://mathmesh.com/Documents/draft-hallambaker-mesh-
advanced.html
Author's Address
Phillip Hallam-Baker
Comodo Group Inc.
Email: philliph@comodo.com
Hallam-Baker Expires March 4, 2019 [Page 19]
