< 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/ |