< draft-hallambaker-mesh-trust-00.txt | draft-hallambaker-mesh-trust-01.txt > | |||
---|---|---|---|---|

Network Working Group P. Hallam-Baker | Network Working Group P. Hallam-Baker | |||

Internet-Draft January 18, 2019 | Internet-Draft April 4, 2019 | |||

Intended status: Informational | Intended status: Informational | |||

Expires: July 22, 2019 | Expires: October 6, 2019 | |||

Mathematical Mesh Part IV: The Trust Mesh | Mathematical Mesh Part VI: The Trust Mesh | |||

draft-hallambaker-mesh-trust-00 | draft-hallambaker-mesh-trust-01 | |||

Abstract | Abstract | |||

This paper extends Shannon's concept of a 'work factor' as applied to | This paper extends Shannon's concept of a 'work factor' as applied to | |||

evaluation of cryptographic algorithms to provide an objective | evaluation of cryptographic algorithms to provide an objective | |||

measure of the practical security offered by a protocol or | measure of the practical security offered by a protocol or | |||

infrastructure design. Considering the hypothetical work factor | infrastructure design. Considering the hypothetical work factor | |||

based on an informed estimate of the probable capabilities of an | based on an informed estimate of the probable capabilities of an | |||

attacker with unknown resources provides a better indication of the | attacker with unknown resources provides a better indication of the | |||

relative strength of protocol designs than the computational work | relative strength of protocol designs than the computational work | |||

skipping to change at page 1, line 35 ¶ | skipping to change at page 1, line 35 ¶ | |||

social work factor allows evaluation of Certificate Authority based | social work factor allows evaluation of Certificate Authority based | |||

trust models and peer to peer (Web of Trust) models to be evaluated | trust models and peer to peer (Web of Trust) models to be evaluated | |||

in the same framework. The analysis demonstrates that both | in the same framework. The analysis demonstrates that both | |||

approaches have limitations and that in certain applications, a | approaches have limitations and that in certain applications, a | |||

blended model is superior to either by itself. | blended model is superior to either by itself. | |||

The final section of the paper describes a proposal to realize this | The final section of the paper describes a proposal to realize this | |||

blended model using the Mathematical Mesh. | blended model using the Mathematical Mesh. | |||

This document is also available online at | This document is also available online at | |||

http://mathmesh.com/Documents/draft-hallambaker-mesh- trust.html [1] | http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.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 July 22, 2019. | This Internet-Draft will expire on October 6, 2019. | |||

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 3, line 4 ¶ | skipping to change at page 3, line 4 ¶ | |||

2.1.5. Chained notary . . . . . . . . . . . . . . . . . . . 18 | 2.1.5. Chained notary . . . . . . . . . . . . . . . . . . . 18 | |||

2.1.6. A blended approach . . . . . . . . . . . . . . . . . 19 | 2.1.6. A blended approach . . . . . . . . . . . . . . . . . 19 | |||

3. The Mesh of Trust . . . . . . . . . . . . . . . . . . . . . . 21 | 3. The Mesh of Trust . . . . . . . . . . . . . . . . . . . . . . 21 | |||

3.1. Master Profile . . . . . . . . . . . . . . . . . . . . . 21 | 3.1. Master Profile . . . . . . . . . . . . . . . . . . . . . 21 | |||

3.2. Uniform Data Fingerprints . . . . . . . . . . . . . . . . 21 | 3.2. Uniform Data Fingerprints . . . . . . . . . . . . . . . . 21 | |||

3.3. Strong Internet Names . . . . . . . . . . . . . . . . . . 22 | 3.3. Strong Internet Names . . . . . . . . . . . . . . . . . . 22 | |||

3.4. Trust notary . . . . . . . . . . . . . . . . . . . . . . 23 | 3.4. Trust notary . . . . . . . . . . . . . . . . . . . . . . 23 | |||

3.5. Endorsement . . . . . . . . . . . . . . . . . . . . . . . 23 | 3.5. Endorsement . . . . . . . . . . . . . . . . . . . . . . . 23 | |||

3.6. Evaluating trust . . . . . . . . . . . . . . . . . . . . 23 | 3.6. Evaluating trust . . . . . . . . . . . . . . . . . . . . 23 | |||

4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||

5. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 | |||

5.1. Informative References . . . . . . . . . . . . . . . . . 24 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 | |||

5.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 24 | |||

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 | 6.2. Informative References . . . . . . . . . . . . . . . . . 24 | |||

6.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 | ||||

1. Work Factor | 1. Work Factor | |||

Recent events have highlighted both the need for open standards-based | Recent events have highlighted both the need for open standards-based | |||

security protocols and the possibility that the design of such | security protocols and the possibility that the design of such | |||

protocols may have been sabotaged [Schneier2013] . We thus face two | protocols may have been sabotaged [Schneier2013] . We thus face two | |||

important and difficult challenges, first to design an Internet | important and difficult challenges, first to design an Internet | |||

security infrastructure that offers practical security against the | security infrastructure that offers practical security against the | |||

class of attacks revealed, and secondly, to convince potential users | class of attacks revealed, and secondly, to convince potential users | |||

that the proposed new infrastructure has not been similarly | that the proposed new infrastructure has not been similarly | |||

skipping to change at page 3, line 44 ¶ | skipping to change at page 3, line 46 ¶ | |||

One of Shannon's key insights was that the work factor of a | One of Shannon's key insights was that the work factor of a | |||

cryptographic algorithm could be exponential. Adding a single bit to | cryptographic algorithm could be exponential. Adding a single bit to | |||

the key size of an ideal symmetric algorithm presents only a modest | the key size of an ideal symmetric algorithm presents only a modest | |||

increase in computational effort for the defender but doubles the | increase in computational effort for the defender but doubles the | |||

work factor for the attacker. | work factor for the attacker. | |||

More precisely, the difficulty of breaking a cryptographic algorithm | More precisely, the difficulty of breaking a cryptographic algorithm | |||

is generally measured by the work-factor ratio. If the cost of | is generally measured by the work-factor ratio. If the cost of | |||

encrypting a block with 56-bit DES is x, the worst case cost of | encrypting a block with 56-bit DES is x, the worst case cost of | |||

recovering the key through a brute force attack is 256x. The | recovering the key through a brute force attack is 2^56x. The | |||

security of DES has changed over time because x has fallen | security of DES has changed over time because x has fallen | |||

exponentially. | exponentially. | |||

While the work factor is traditionally measured in terms of the | While the work factor is traditionally measured in terms of the | |||

number of operations, many cryptanalytic techniques permit memory | number of operations, many cryptanalytic techniques permit memory | |||

used to be traded for computational complexity. An attack requiring | used to be traded for computational complexity. An attack requiring | |||

264 bytes of memory that reduces the number of operations required to | 2^64 bytes of memory that reduces the number of operations required | |||

break a 128 bit cipher to 264 is a rather lower concern than one | to break a 128 bit cipher to 2^64 is a rather lower concern than one | |||

which reduces the number of operations to 280. The term 'cost' is | which reduces the number of operations to 2^80. The term 'cost' is | |||

used to gloss over such distinctions. | used to gloss over such distinctions. | |||

The Computational Work Factor ratio WF-C (A) of a cryptographic | The Computational Work Factor ratio WF-C (A) of a cryptographic | |||

algorithm A, is the cost of the best-known attack divided by the cost | algorithm A, is the cost of the best-known attack divided by the cost | |||

of the algorithm itself. | of the algorithm itself. | |||

1.2. Hypothetical Work Factor | 1.2. Hypothetical Work Factor | |||

Modern cryptographic algorithms use keys of 128 bits or more and | Modern cryptographic algorithms use keys of 128 bits or more and | |||

present a work factor ratio of 2128 against brute force attack. This | present a work factor ratio of 2^128 against brute force attack. | |||

work factor is at least 272 times higher than DES and comfortably | This work factor is at least 2^72 times higher than DES and | |||

higher than the work factor of 280 operations that is generally | comfortably higher than the work factor of 2^80 operations that is | |||

believed to be the practical limit to current attacks. | generally believed to be the practical limit to current attacks. | |||

Though Moore's law has delivered exponential improvements in | Though Moore's law has delivered exponential improvements in | |||

computing performance over the past four decades, this has been | computing performance over the past four decades, this has been | |||

achieved through continual reductions in the minimum feature size of | achieved through continual reductions in the minimum feature size of | |||

VLSI circuits. As the minimum feature size rapidly approaches the | VLSI circuits. As the minimum feature size rapidly approaches the | |||

size of individual atoms, this mechanism has already begun to stall | size of individual atoms, this mechanism has already begun to stall | |||

[Intel2018] . | [Intel2018] . | |||

While an exceptionally well-resourced attacker may gain performance | While an exceptionally well-resourced attacker may gain performance | |||

advances through use of massive parallelism, faster clock rates made | advances through use of massive parallelism, faster clock rates made | |||

skipping to change at page 5, line 8 ¶ | skipping to change at page 5, line 10 ¶ | |||

likely capabilities. In particular, it is the capabilities of | likely capabilities. In particular, it is the capabilities of | |||

nation-state actors that generally give rise to greatest concern in | nation-state actors that generally give rise to greatest concern in | |||

security protocol design. In this paper we refer to this set of | security protocol design. In this paper we refer to this set of | |||

actors as nation-state class adversaries in recognition of the fact | actors as nation-state class adversaries in recognition of the fact | |||

that certain technology companies posses computing capabilities that | that certain technology companies posses computing capabilities that | |||

rival if not exceed those of the largest state actors and those | rival if not exceed those of the largest state actors and those | |||

capabilities could at least in theory be co-opted for other purposes | capabilities could at least in theory be co-opted for other purposes | |||

in certain circumstances. | in certain circumstances. | |||

The probability that a nation-state class has discovered an attack | The probability that a nation-state class has discovered an attack | |||

against AES-128 with a work factor ratio of 2120 might be considered | against AES-128 with a work factor ratio of 2^120 might be considered | |||

relatively high while the probability that an attack with a work | relatively high while the probability that an attack with a work | |||

factor ratio of less than 264 is very low. | factor ratio of less than 2^64 is very low. | |||

We define the hypothetical work factor function WF-H (A, p) as | We define the hypothetical work factor function WF-H (A, p) as | |||

follows: If WF is a work factor ratio and p is an informed estimate | follows: If WF is a work factor ratio and p is an informed estimate | |||

of the probability that an adversary has developed an attack with a | of the probability that an adversary has developed an attack with a | |||

work factor ratio against algorithm A of WF or less then WF-H (A, p) | work factor ratio against algorithm A of WF or less then WF-H (A, p) | |||

= WF. | = WF. | |||

Since the best-known public attack is known to the attacker, WF-H (A, | Since the best-known public attack is known to the attacker, WF-H (A, | |||

1) = CWF (A) | 1) = _CWF (A) | |||

The inverse function WF-H' (A, WF) returns the estimated probability | The inverse function WF-H' (A, WF) returns the estimated probability | |||

that the work factor of algorithm A is at least WF. | that the work factor of algorithm A is at least WF. | |||

The hypothetical work factor and its inverse may be used to compare | The hypothetical work factor and its inverse may be used to compare | |||

the relative strengths of protocol designs. Given designs A and B, | the relative strengths of protocol designs. Given designs A and B, | |||

we can state that B is an improvement on A if WF-H (A,p) > WF-H (B,p) | we can state that B is an improvement on A if WF-H (A,p) > WF-H (B,p) | |||

for all p. | for all p. | |||

When considering a protocol or infrastructure design we can thus | When considering a protocol or infrastructure design we can thus | |||

skipping to change at page 7, line 12 ¶ | skipping to change at page 7, line 15 ¶ | |||

For example, consider the case in which a choice between a single | For example, consider the case in which a choice between a single | |||

security control and a defense in depth strategy is being considered: | security control and a defense in depth strategy is being considered: | |||

o Option A: Uses algorithm X for protection. | o Option A: Uses algorithm X for protection. | |||

o Option B: Uses a combination of algorithm X and algorithm Y for | o Option B: Uses a combination of algorithm X and algorithm Y for | |||

protection such that the attacker must defeat both to break the | protection such that the attacker must defeat both to break the | |||

system and algorithms based on different cryptographic principles | system and algorithms based on different cryptographic principles | |||

are chosen so as to minimize the risk of a common failure mode. | are chosen so as to minimize the risk of a common failure mode. | |||

If the computational work factor for both algorithms X and Y is 2128, | If the computational work factor for both algorithms X and Y is | |||

both options present the same work factor ratio. Although Option B | 2^128, both options present the same work factor ratio. Although | |||

offers twice the security, it also requires twice the work. | Option B offers twice the security, it also requires twice the work. | |||

The argument that normally wins is that both options present the same | The argument that normally wins is that both options present the same | |||

computational work factor ratio of 2128, Option A is simpler and | computational work factor ratio of 2^128, Option A is simpler and | |||

therefore Option A should be chosen. This despite the obvious fact | therefore Option A should be chosen. This despite the obvious fact | |||

that only Option B offers defense in depth. | that only Option B offers defense in depth. | |||

If we consider the adversary of being capable of performing a work | If we consider the adversary of being capable of performing a work | |||

factor ratio of 280 and the probability the attacker has discovered | factor ratio of 2^80 and the probability the attacker has discovered | |||

an attack capable of breaking algorithms X and Y to be 10% in each | an attack capable of breaking algorithms X and Y to be 10% in each | |||

case, the probability that the attacker can break Option A is 10% | case, the probability that the attacker can break Option A is 10% | |||

while the probability that an attack on Option B is only 1%, a | while the probability that an attack on Option B is only 1%, a | |||

significant improvement. | significant improvement. | |||

While Option B clearly offers a significant potential improvement in | While Option B clearly offers a significant potential improvement in | |||

security, this improvement is only fully realized if the | security, this improvement is only fully realized if the | |||

probabilities of a feasible attack are independent. | probabilities of a feasible attack are independent. | |||

1.5. Mutual Reinforcement | 1.5. Mutual Reinforcement | |||

The defense in depth approach affords a significant improvement in | The defense in depth approach affords a significant improvement in | |||

security but an improvement that is incremental rather than | security but an improvement that is incremental rather than | |||

exponential in character. With mutual reinforcement we design the | exponential in character. With mutual reinforcement we design the | |||

mechanism such that in addition to requiring the attacker to break | mechanism such that in addition to requiring the attacker to break | |||

each of the component algorithms, the difficulty of the attacks is | each of the component algorithms, the difficulty of the attacks is | |||

increased. | increased. | |||

For example, consider the use of a Deterministic Random Number | For example, consider the use of a Deterministic Random Number | |||

Generator R(s,n) which returns a sequence of values R(s,1), R(s,2)? | Generator R(s,n) which returns a sequence of values R(s,1), R(s,2)... | |||

from an initial seed s. | from an initial seed s. | |||

Two major concerns in the design of such generators are the | Two major concerns in the design of such generators are the | |||

possibility of bias and that the seed value be somehow leaked through | possibility of bias and that the seed value be somehow leaked through | |||

a side channel. | a side channel. | |||

Both concerns are mitigated if instead of using the output of one | Both concerns are mitigated if instead of using the output of one | |||

generator directly, two independent random number generators with | generator directly, two independent random number generators with | |||

distinct seeds are used. | distinct seeds are used. | |||

skipping to change at page 8, line 46 ¶ | skipping to change at page 9, line 4 ¶ | |||

attack, the concern is not just whether an individual communication | attack, the concern is not just whether an individual communication | |||

might be compromised but the number of communications that may be | might be compromised but the number of communications that may be | |||

compromised for a given amount of effort. | compromised for a given amount of effort. | |||

'Perfect' Forward Secrecy is an optional feature supported in IPSec | 'Perfect' Forward Secrecy is an optional feature supported in IPSec | |||

and TLS. In 2008, implementations of TLS/1.2 [RFC6246] purported to | and TLS. In 2008, implementations of TLS/1.2 [RFC6246] purported to | |||

offer a choice between: | offer a choice between: | |||

Direct key exchange with a work factor dependent on the difficulty of | Direct key exchange with a work factor dependent on the difficulty of | |||

breaking RSA 2048 | breaking RSA 2048 | |||

Direct key exchange followed by a perfect forward secrecy exchange | Direct key exchange followed by a perfect forward secrecy exchange | |||

with a work factor dependent on the difficulty of breaking both RSA | with a work factor dependent on the difficulty of breaking both RSA | |||

2048 and DH 1024. | 2048 and DH 1024. | |||

Using the computational work factor alone suggests that the second | Using the computational work factor alone suggests that the second | |||

scheme has little advantage over the first since the computational | scheme has little advantage over the first since the computational | |||

work factor of Diffie Hellman using the best-known techniques 280 | work factor of Diffie Hellman using the best-known techniques 2^80 | |||

while the computational work factor for RSA 2048 is 2112. Use of the | while the computational work factor for RSA 2048 is 2^112. Use of | |||

perfect forward secrecy exchange has a significant impact on server | the perfect forward secrecy exchange has a significant impact on | |||

performance but does not increase the difficulty of cryptanalysis. | server performance but does not increase the difficulty of | |||

cryptanalysis. | ||||

Use of perfect forward secrecy with a combination of RSA and Diffie | Use of perfect forward secrecy with a combination of RSA and Diffie | |||

Hellman does not provide a significant improvement in the | Hellman does not provide a significant improvement in the | |||

hypothetical work factor either if individual messages are | hypothetical work factor either if individual messages are | |||

considered. The RSA and Diffie Hellman systems are closely related | considered. The RSA and Diffie Hellman systems are closely related | |||

and so an attacker that can break RSA 2048 can almost certainly break | and so an attacker that can break RSA 2048 can almost certainly break | |||

RSA 1024. Moreover, computational work factor for DH 1024 is only | RSA 1024. Moreover, computational work factor for DH 1024 is only | |||

280 and thus feasibly within the reach of a well-funded and | 2^80 and thus feasibly within the reach of a well-funded and | |||

determined attacker. | determined attacker. | |||

According to the analysis informally applied during design, use of | According to the analysis informally applied during design, use of | |||

perfect forward secrecy does provide an important security benefit | perfect forward secrecy does provide an important security benefit | |||

when multiple messages are considered. While a sufficiently funded | when multiple messages are considered. While a sufficiently funded | |||

and determined attacker could conceivably break tens, hundreds or | and determined attacker could conceivably break tens, hundreds or | |||

even thousands of DH 1024 keys a year, it is rather less likely that | even thousands of DH 1024 keys a year, it is rather less likely that | |||

an attacker could break millions a year. The OCSP servers operated | an attacker could break millions a year. The OCSP servers operated | |||

by Comodo CA receive over 2 billion hits a day and this represents | by Comodo CA receive over 2 billion hits a day and this represents | |||

only a fraction of the number of uses of TLS on the Internet. Use of | only a fraction of the number of uses of TLS on the Internet. Use of | |||

skipping to change at page 10, line 5 ¶ | skipping to change at page 10, line 11 ¶ | |||

exploits the fact that the difficulty of breaking the discrete | exploits the fact that the difficulty of breaking the discrete | |||

logarithm involves four major steps, the first three of which are the | logarithm involves four major steps, the first three of which are the | |||

most computationally intensive and only depend on the shared group | most computationally intensive and only depend on the shared group | |||

parameters. The cost of breaking a hundred Diffie Hellman public | parameters. The cost of breaking a hundred Diffie Hellman public | |||

keys is not a hundred times the cost of breaking a single key, there | keys is not a hundred times the cost of breaking a single key, there | |||

is almost no difference. | is almost no difference. | |||

Work factor analysis exposes these flaws in the design of the | Work factor analysis exposes these flaws in the design of the | |||

TLS/1.2. Since the session keys used to encrypt traffic do not | TLS/1.2. Since the session keys used to encrypt traffic do not | |||

depend on knowing the secret established in the RSA2048 exchange, the | depend on knowing the secret established in the RSA2048 exchange, the | |||

work factor of the protocol is the lesser of 280 and 2112. | work factor of the protocol is the lesser of 2^80 and 2^112. | |||

A simple means of ensuring that the work factor of a protocol is not | A simple means of ensuring that the work factor of a protocol is not | |||

reduced by a fresh key exchange is to use a one-way function such as | reduced by a fresh key exchange is to use a one-way function such as | |||

a cryptographic digest or a key exchange to combine the output of the | a cryptographic digest or a key exchange to combine the output of the | |||

prior exchange with its successor. This principle is employed in the | prior exchange with its successor. This principle is employed in the | |||

double ratchet algorithm [Ratchet] used in the Signal protocol. In | double ratchet algorithm [Ratchet] used in the Signal protocol. In | |||

the Mesh, the HKDF Key Derivation function [RFC5869] is frequently | the Mesh, the HKDF Key Derivation function [RFC5869] is frequently | |||

used for the same purpose. | used for the same purpose. | |||

The work factor downgrade issue was addressed in TLS/1.3 [RFC8446] | The work factor downgrade issue was addressed in TLS/1.3 [RFC8446] | |||

skipping to change at page 13, line 39 ¶ | skipping to change at page 13, line 45 ¶ | |||

Introducing a backdoor into a HSM, application or operating system | Introducing a backdoor into a HSM, application or operating system | |||

platform requires that every person with access to the platform | platform requires that every person with access to the platform | |||

source or who might be called in to audit the code be a party to the | source or who might be called in to audit the code be a party to the | |||

conspiracy. Tapping the fiber optic cables that support the Internet | conspiracy. Tapping the fiber optic cables that support the Internet | |||

backbone requires only a small work crew and digging equipment. | backbone requires only a small work crew and digging equipment. | |||

Maintaining a covert backdoor in a major operating system platform | Maintaining a covert backdoor in a major operating system platform | |||

would require hundreds if not thousands of engineers to participate | would require hundreds if not thousands of engineers to participate | |||

in the conspiracy. | in the conspiracy. | |||

The Social Work Factor SWF(t) is a measure of the cost of | The Social Work Factor _SWF(t) is a measure of the cost of | |||

establishing a fraud in a conspiracy starting at date t. The cost is | establishing a fraud in a conspiracy starting at date t. The cost is | |||

measured in the number of actions that the party perpetrating the | measured in the number of actions that the party perpetrating the | |||

fraud must perform that carry a risk of exposure. | fraud must perform that carry a risk of exposure. | |||

In general, the Social Work Factor will increase over time. | In general, the Social Work Factor will increase over time. | |||

Perpetrating a fraud claiming that the Roman emperor Nero never | Perpetrating a fraud claiming that the Roman emperor Nero never | |||

existed today would require that millions of printed histories be | existed today would require that millions of printed histories be | |||

erased and rewritten, every person who has ever taught or taken a | erased and rewritten, every person who has ever taught or taken a | |||

lesson in Roman history would have to participate in the fraud. The | lesson in Roman history would have to participate in the fraud. The | |||

Social Work Factor would be clearly prohibitive. | Social Work Factor would be clearly prohibitive. | |||

The Social Work Factor in the immediate aftermath of Nero's | The Social Work Factor in the immediate aftermath of Nero's | |||

assassination in 68 would have been considerably lower. While the | assassination in 68 would have been considerably lower. While the | |||

emperor Nero was obviously not erased from history, this did happen | emperor Nero was obviously not erased from history, this did happen | |||

to Akhenaten, an Egyptian pharaoh of the 18th dynasty whose monuments | to Akhenaten, an Egyptian pharaoh of the 18^th dynasty whose | |||

were dismantled, statues destroyed, and his name erased from the | monuments were dismantled, statues destroyed, and his name erased | |||

lists of kings. | from the lists of kings. | |||

1.8.1. Related work | 1.8.1. Related work | |||

It has not escaped the notice of the author that the social work | It has not escaped the notice of the author that the social work | |||

factor might be applied as a general metric for assessing the | factor might be applied as a general metric for assessing the | |||

viability of a conspiracy hypothesis. | viability of a conspiracy hypothesis. | |||

Applying social work factor analysis to the moon landing conspiracy | Applying social work factor analysis to the moon landing conspiracy | |||

theory we note that almost all of the tens of thousands of NASA | theory we note that almost all of the tens of thousands of NASA | |||

employees who worked on the Apollo project would have had to be a | employees who worked on the Apollo project would have had to be a | |||

skipping to change at page 22, line 8 ¶ | skipping to change at page 22, line 8 ¶ | |||

3.2. Uniform Data Fingerprints | 3.2. Uniform Data Fingerprints | |||

Direct trust in the Mesh is realized through use of Uniform Data | Direct trust in the Mesh is realized through use of Uniform Data | |||

Fingerprints (UDF) [draft-hallambaker-udf] . A UDF consists of a | Fingerprints (UDF) [draft-hallambaker-udf] . A UDF consists of a | |||

cryptographic digest (e.g. SHA-2-512) over a data sequence and a | cryptographic digest (e.g. SHA-2-512) over a data sequence and a | |||

content type identifier. | content type identifier. | |||

UDFs are presented as a Base32 encoded sequence with separators every | UDFs are presented as a Base32 encoded sequence with separators every | |||

25 characters. UDFs may be presented at different precisions | 25 characters. UDFs may be presented at different precisions | |||

according to the intended use. The 25-character presentation | according to the intended use. The 25-character presentation | |||

provides a work factor of 2117 and is short enough to put on a | provides a work factor of 2^117 and is short enough to put on a | |||

business card or present as a QR code. The 50-character presentation | business card or present as a QR code. The 50-character presentation | |||

provides a work factor of 2242 and is compact enough to be used in a | provides a work factor of 2^242 and is compact enough to be used in a | |||

configuration file. | configuration file. | |||

For example, the UDF of the text/plain sequence "UDF Data Value" may | For example, the UDF of the text/plain sequence "UDF Data Value" may | |||

be presented in either of the following forms: | be presented in either of the following forms: | |||

MDDK7-N6A72-7AJZN-OSTRX-XKS7D | MDDK7-N6A72-7AJZN-OSTRX-XKS7D | |||

MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI-6OZSL-U2VOA-TZQ6J-MHPTS | MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI-6OZSL-U2VOA-TZQ6J-MHPTS | |||

Figure 1 | ||||

The UDF of a user's master profile signature key is used as a | The UDF of a user's master profile signature key is used as a | |||

persistent, permanent identifier of the user that is unique to them | persistent, permanent identifier of the user that is unique to them | |||

and will remain constant for their entire life unless they have | and will remain constant for their entire life unless they have | |||

reason to replace their master profile with a new one. The exchange | reason to replace their master profile with a new one. The exchange | |||

of master profile UDFs is the means by which Mesh users establish | of master profile UDFs is the means by which Mesh users establish | |||

direct trust. | direct trust. | |||

3.3. Strong Internet Names | 3.3. Strong Internet Names | |||

A Strong Internet name (SIN) [draft-hallambaker-sin] is a valid | A Strong Internet name (SIN) [draft-hallambaker-sin] is a valid | |||

skipping to change at page 24, line 12 ¶ | skipping to change at page 24, line 12 ¶ | |||

for the Web, the evaluation of trust in the Mesh is left to the | for the Web, the evaluation of trust in the Mesh is left to the | |||

application of venture capital to deep AI. | application of venture capital to deep AI. | |||

4. Conclusions | 4. Conclusions | |||

This paper describes the principal approaches used to establish | This paper describes the principal approaches used to establish | |||

Internet trust, a means of evaluating them and a proposed successor. | Internet trust, a means of evaluating them and a proposed successor. | |||

It now remains to determine the effectiveness of the proposed | It now remains to determine the effectiveness of the proposed | |||

approach by attempting deployment. | approach by attempting deployment. | |||

5. References | 5. Security Considerations | |||

5.1. Informative References | This document describes the means by which interparty identification | |||

risk is managed and controlled in the Mathematical Mesh. | ||||

The security considerations for use and implementation of Mesh | ||||

services and applications are described in the Mesh Security | ||||

Considerations guide [draft-hallambaker-mesh-security] . | ||||

6. References | ||||

6.1. Normative References | ||||

[draft-hallambaker-mesh-security] | ||||

"[Reference Not Found!]". | ||||

6.2. Informative References | ||||

[Adrian2015] | [Adrian2015] | |||

Adrian, D., "Weak Diffie-Hellman and the Logjam Attack", | Adrian, D., "Weak Diffie-Hellman and the Logjam Attack", | |||

October 2015. | October 2015. | |||

[Bitcoin] Finley, K., "After 10 Years, Bitcoin Has Changed | [Bitcoin] Finley, K., "After 10 Years, Bitcoin Has Changed | |||

Everything?And Nothing", November 2018. | Everything?And Nothing", November 2018. | |||

[Diffie76] | [Diffie76] | |||

Diffie, W. and M. Hellman, "New Directions in | Diffie, W. and M. Hellman, "New Directions in | |||

skipping to change at page 24, line 52 ¶ | skipping to change at page 25, line 17 ¶ | |||

[Intel2018] | [Intel2018] | |||

Bell, L., "Intel delays 10nm Cannon Lake processors, | Bell, L., "Intel delays 10nm Cannon Lake processors, | |||

again, until late 2019", July 2018. | again, until late 2019", July 2018. | |||

[Kohnfelder78] | [Kohnfelder78] | |||

Kohnfelder, L., "Towards a Practical Public-Key | Kohnfelder, L., "Towards a Practical Public-Key | |||

Cryptosystem", May 1978. | Cryptosystem", May 1978. | |||

[Namecoin] | [Namecoin] | |||

"Namecoin Web Site", 2019. | Inc., N., "Namecoin Web Site", 2019. | |||

[Ratchet] Marlinspike, M. and T. Perrin, "The Double Ratchet | [Ratchet] Marlinspike, M. and T. Perrin, "The Double Ratchet | |||

Algorithm", November 2016. | Algorithm", November 2016. | |||

[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | |||

Key Derivation Function (HKDF)", RFC 5869, | Key Derivation Function (HKDF)", RFC 5869, | |||

DOI 10.17487/RFC5869, May 2010. | DOI 10.17487/RFC5869, May 2010. | |||

[RFC6246] Sajassi, A., Brockners, F., Mohan, D., and Y. Serbest, | [RFC6246] Sajassi, A., Brockners, F., Mohan, D., and Y. Serbest, | |||

"Virtual Private LAN Service (VPLS) Interoperability with | "Virtual Private LAN Service (VPLS) Interoperability with | |||

skipping to change at page 25, line 31 ¶ | skipping to change at page 25, line 45 ¶ | |||

Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018. | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018. | |||

[Schneier2013] | [Schneier2013] | |||

Schneier, B., "Defending Against Crypto Backdoors", | Schneier, B., "Defending Against Crypto Backdoors", | |||

October 2013. | October 2013. | |||

[Shannon1949] | [Shannon1949] | |||

Shannon, C., "Communication Theory of Secrecy Systems", | Shannon, C., "Communication Theory of Secrecy Systems", | |||

1949. | 1949. | |||

5.2. URIs | 6.3. URIs | |||

[1] http://mathmesh.com/Documents/draft-hallambaker-mesh- trust.html | [1] http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html | |||

Author's Address | Author's Address | |||

Phillip Hallam-Baker | Phillip Hallam-Baker | |||

Email: phill@hallambaker.com | Email: phill@hallambaker.com | |||

End of changes. 30 change blocks. | ||||

48 lines changed or deleted | | 61 lines changed or added | ||

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