Appeal to Authority: a Failure of Trust

8/18/2019 Appeal to Authority: a Failure of Trust

1/19

1

Appeal to authority: A failure of trust

Abstract. In December 2015, a Motherboard article suggested that cryptographic

keys claimed by Wired and Gizmodo to be linked to Satoshi Nakamoto were created

using technology that was not available on the dates they were supposedly made.

This idea has gained widespread acceptance. However, in this paper we present

evidence that disproves this claim by showing precisely how the keys in question

could indeed have been generated on the specified dates. In addition, a warning is

rung regarding the onset of centralised authority in the control of bitcoin that has

been achieved through Blocksize restrictions. These restrictions have led to

centralisation of Bitcoin via the dogma of the core development team. This paper

highlights why it is always essential to investigate allegations and critically evaluate

the evidence presented.

1. Introduction

This paper aims to disprove the assertion made by bitcoin core developer Greg Maxwell as reported

in Motherboard [2] (and elsewhere) that cryptographic keys associated with Satoshi Nakamoto could

not have been generated at the time they were supposedly made. This paper neither confirms nor

denies those keys; the aim is to show that their creation on the disputed dates is possible. We do

this by laying out, step by step, a repeatable procedure that any interested individual can follow to

confirm that the required cryptographic features were available at the time. Furthermore, in doing

this, we hope to edify those like Maxwell who aspire to acquire the proper skills and knowledge in

this area, so that misconceptions can be reduced and further misinformation avoided.

The logical fallacy of an appeal to authority is made whenever we try to justify an idea through

the citing of expertise as the reason to hold that idea. However, even experts are subject to

validation. The nature of science is of a system derived through empirical proof and evidence.Generally, an appeal to authority is fallacious when we cite those who have no special expertise.

This is of greater concern when we have an individual believed or purporting to be an expert who

abuses trust. Even experts have agendas and the only means to ensure that trust is valid is to hold

those experts to a greater level of scrutiny. It remains the expert's reasons and methods that are

valuable and not the fact that a statement is made by an expert. Experts can be wrong and may not

be aware of invalid statements they have themselves made.

The importance of critical thinking cannot be overstated. Bitcoin on the Blockchain have been

designed with the aim of limiting the amount of trust needed to deal with unknown parties. It is a

system that allows us to create systems that open dialogue and communication between parties. Of

particular note, it is a system that allows us to record interactions and validate them seamlessly

across time and distance.

We remain a long way from understanding the value of the system. Before we get to a point

where we can trade and interact we need to understand the nature of trust. Even with Bitcoin, wecan never create a society that does not rely on trust. It is a part of human nature that looks to others

for leadership. Those who assume the mantle of leadership also need to understand the burdens and

the responsibilities. All too often, the limitations of those who have had leadership and

responsibility handed to them show forth in a damaging manner. The media do not sell news but


2/19

2

sell sensation. For this, the fallacies of suppressed evidence and selective attention should be first

to mind. It is in this spirit that the current paper is presented; the claims made herein are supported

by evidence with the intention that it be critically and independently evaluated.

2. PGP – key analysis and review.

In a response that has been taken up by Motherboard [2], a great deal of weight has been placed onan assertion made by bitcoin core developer Gregory Maxwell [3] that has cast doubt on the validity

of a number of PGP keys. This paper neither confirms nor denies those keys, but it does address

the questions posed by Maxwell as reported by Wired magazine.

The misinformation questioned in this paper has been variously reported but can be summarised

as follows:

The 8,2,9,10,11 list was added to the GNUPG code tree in commit

e50cac1d848d332c4dbf49d5f705d3cbbf074ba1 on July 9th, 2009, and not

released until version 2.0.13 later. This is well after the 2008 date on the key.

The 2,8,3 list was the prior list the would have been used in 2008. That they

were different at all was surprising, considering that they claim to be

generated less than a day apart.

The list mentioned above refers to the cipher-suites, or encryption algorithms, used in the

creation of the keys. It is known that the Satoshi Nakamoto key was created using GnuPG 1.4.7. In

the following sections we provide in detail the procedure required to disprove the claim reported in

Motherboard and to highlight the dangers of reporting without sufficient fact checking. Due to the

lack of response and analysis along with the willingness to accept the word of an expert on faith

alone and without independent verification, it has become necessary to demonstrate that this position

is incorrect.

3. GnuPG 1.4.7

As we have quoted above, it was stated that “This is well after the 2008 date on the key”. What was

not clarified was that the 2008 version of the software is available and has been saved.

● https://web.archive.org/web/20070606214025/http://www.gnupg.org/download/

● ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.7.exe 1

We can test the claim that “Two of the keys attributed to Satoshi were likely created using

technology that wasn’t available on the dates that they were supposedly made” [2]. In a download

of this software, we can simply check and refute this statement. The first step is to start by installing

the version of the software that was used on the original Satoshi key in 2008 from the link listed

above. Once this has been downloaded, we can install the old version of the software. We configure

and run this by going to the command line and changing to the directory it was installed into (see

Fig. 1). The link provided above has a copy of the software as at June 2007. This is more than a

full year prior to the 2008 keys that have been disputed.

1 The Signature and SHA-1 checksum for gnupg-w32cli-1.4.7.exe is available from the NIST software catalogue: b806e8789c93dc6d08b129170d6beb9e1a5ae68f

https://web.archive.org/web/20070606214025/http:/www.gnupg.org/download/https://web.archive.org/web/20070606214025/http:/www.gnupg.org/download/ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.7.exeftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.7.exeftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32cli-1.4.7.exehttps://web.archive.org/web/20070606214025/http:/www.gnupg.org/download/https://web.archive.org/web/20070606214025/http:/www.gnupg.org/download/


3/19

3

Figure 1: GPG 1.4.7 install on Windows

By executing the following command, we can list the details of all the keys stored in our keyring.

!"! $% $$&'"()* +,%*(-./ 0%1%2(*(+ 3 !"! $$4/-*$"%51&*- $$

6&)7(-& 3 2()&

With the key associated with the Vistomail account, the known fingerprint is

18C09E865EC948A1. In analysing the results of the above command on this key we can validate

the following output from the image displayed in Fig. 2.

Figure 2: Details of the Satoshi PGP key

From Fig. 2 and the results that can be independently verified, one will see the cipher suites that

are associated with the PGP with a 32-bit fingerprint of 5EC948A1. We will simply note this forfuture reference at this point.

In his assertions, Gregory Maxwell had stated that “both keys use a list of cipher- suites that don’t

match up to the Original Key, and weren’t added to GPG until 2009”. This statement is important

and we need to note that it was followed with the reported statement from Motherboard:


4/19

4

Maxwell found that the Wired Key and the Gizmodo Key have preferred hash

algorithms “8,2,9,10,11.” The Original Key has a preferred hash algorithm

list “2,8,3.” This refers to the cipher -suites, or encryption algorithms, used.

The “8,2,9,10,11” list was added to the GnuPG code tree as a commit on July

9, 2009, and released inversion 2.0.13 on September 4, 2009.

The importance of this statement is that Maxwell has firmly asserted that the algorithms,

“8,2,9,10,11” have only been added from a later period in 2009. It is stated that the code tree was

built on the 09th July 2009 and that this was released on the 04 th September of the same year. The

challenge to the reader is to engage in an independent scientific examination of the evidence

presented. Each stage of this paper can be repeated. The truth is not in who has stated it, but in the

formal validation of the results. As the Internet Archive and the NIST software archives hold the

cryptographic hashes of the released software, the truth comes from a mathematical analysis of the

binary and source code that has been retrieved.

This paper details how the reader can download and install GnuPG version 1.4.7. This is a

version of the software that was commonly available in 2008 and was in fact compiled and available

to download as a binary from 2007. The mirror repository sites are maintained by NIST and the US

Library of Congress and the software hashes are widely available making the validation of thissoftware a reasonably straightforward proposition [4]. We have engaged in this exercise in order to

demonstrate that the former statement made by Maxwell is incorrect. From what we will document

below, the reader will note the ease with which a knowledgeable individual could have built a PGP

key using the disputed cypher suites, “8,2,9,10,11”. We demonstrate this using a version of the

GnuPG binaries that had been compiled in 2007.

We start by issuing the following command used to create a new key. We can complete this

using the former version of software:

!"! $$!&8$1&9

For this exercise, GnuPG is installed on Microsoft Windows. The first version of Bitcoin and

indeed the version of PGP keys that are attributed to the Satoshi email address were compiled on

Microsoft Windows. In executing these commands in the manner listed in this paper, the reader willobtain the same results as have been displayed in the following figures.


5/19

5

Figure 3: Generating a new PGP key

The first step is to enter the values for the test key that we are using to create a PGP key that we

can evaluate. In running through this process step by step, the reader will obtain an understanding

of how GnuPG functions and also an insight into the inner workings and format of the created public

and private key pairs.

Figure 4: Selecting a passphrase


6/19

6

Next, key is created and saved in the keyring. The requirement to move the mouse is due to a

process of collecting entropy (see Fig. 5). This is to ensure that the code used in GnuPG, “rndw32.c”

does not repeat the same or extremely similar results as this could lead to a compromised key. The

Riemann zeta function for example is a commonly used method of creating a pseudo random series

of numbers. If an attacker can guess the input, they can attack the private keys. This is not what we

are concerned about in this paper but should be noted by the reader to ensure that a strong source ofentropy is available when key security matters.

Figure 5: The new key is created

In this first stage, we have created a PGP key pair that has been built using a 1024 Bit DSA key

for signing and a 2048 Bit key for encryption. The nature of this exercise is to familiarise the reader

with the process of creating a default key using the 2007/8 version of GnuPG in a manner that aligns

to the 1024 bit Satoshi key.

Next, we shall extend this exercise into the creation of a 4096 Bit RSA key pair. We will then

further extend this into adding protocol suites to our keys. This is important as it will prove

definitively to the reader through evidence and not authoritative statement that the following

statement by Gregory Maxwell cannot be correct:

“Two of the keys attributed to Satoshi were likely created using technology that wasn’t available

on the dates that they were supposedly made”.

In the logical analysis of evidence, we cannot have contradictions. Where such a contradiction

exists, we need to check our premises. In this process that we are exploring together, either we can

recreate a similar key along the lines of the one Maxwell has stated could not have existed and must

have been backdated, or we cannot. If we can create a key using the GnuPG software from 2007


7/19

7

and add the attributes of the disputed keys to a newly created key pair, then Maxwell is wrong. If

we cannot complete this process, then he was correct and the keys could have been backdated. This

is a binary outcome and there cannot be any other result.

Either creating the keys was possible, or the evidence reported by Motherboard was unfounded.

Figure 6: Creating a 4096 Bit RSA key

One of the claims made in the Motherboard article was that the creation of a 3072 bit RSA key

was unusual for the time. We will show that this is incorrect and misleading. Not only is it simple

to create a key of this length but it was a process that was readily available to a novice, let alone anexperienced user of cryptographic software. When an RSA algorithm is selected, it is possible to

create a far more secure key than when a DSA key has been chosen. The reason for this comes from

the limitations on the key length for DSA. This length is always 1024 bits as is specified by FIPS

186-2. The result is that from the limits that are imposed on the DSA key length as compared to an

RSA key length that is not limited: it is obvious that one can generate much stronger RSA keys than

DSA keys. For this reason, RSA was preferable over DSA in 2008. (Note that this was before the

wide deployment of Elliptic Curve Cryptography.)

More importantly, it has been widely argued2 that the key length of DSA was deliberately limited

in the government standard in order to increase the chances that a government agency could decrypt

it. When a signed and/or encrypted message was to be valid for a short time, say in the order of

months to a year, a 1024 bit DSA key would have been adequate. When the key would have been

required to last for a decade or more, it would have been preferable to use either a 3072 bit or 4096

bit RSA key. It should be clear to the reader that this was not a difficult decision and that a

2 This debate has been detailed at https://www.guyrutenberg.com/2007/10/05/ssh-keygen-

tutorial-generating-rsa-and-dsa-keys/ and later at

https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html

https://www.guyrutenberg.com/2007/10/05/ssh-keygen-tutorial-generating-rsa-and-dsa-keys/https://www.guyrutenberg.com/2007/10/05/ssh-keygen-tutorial-generating-rsa-and-dsa-keys/https://www.guyrutenberg.com/2007/10/05/ssh-keygen-tutorial-generating-rsa-and-dsa-keys/https://www.guyrutenberg.com/2007/10/05/ssh-keygen-tutorial-generating-rsa-and-dsa-keys/https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.htmlhttps://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.htmlhttps://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.htmlhttps://www.guyrutenberg.com/2007/10/05/ssh-keygen-tutorial-generating-rsa-and-dsa-keys/https://www.guyrutenberg.com/2007/10/05/ssh-keygen-tutorial-generating-rsa-and-dsa-keys/


8/19

8

knowledgeable individual who desired a contract or other signed document would not have selected

a small key length that would not be expected to have lasted for a sufficiently long term.

For a deed, the term of the deed can be calculated to be the final date plus 12 years. NIST

recommended prior to 2010 that for a document that is to be protected up until to 2030 such as the

one in question, that a “Factoring Modulus” or RSA key length of 3072 bits should be selected.

Given this information, it is not a great leap in logic to see that the selection of a 3072 bit RSA keywas not an unusual choice. Rather, had a lower strength key been selected for the purpose it was

used for, we would be likely to suspect either the security and cryptographic knowledge or the

integrity of the creator of that key [5], [4].

The statement noting that the selection of algorithms in the disputed PGP keys was unusual also

seems out of place. In January 2011, Gregory Maxwell moderated a discussion [1] concerning the

reason for the selection of the specific Koblitz curves used in the Bitcoin code. The use of secp256k1

has been a source of debate within the community with some contention. This selection was a trade-

off between speed and power but is out of scope in this paper other than to note that this comment

could not in itself be validly supported by anyone who knows Satoshi.

Returning to our exercise, we can view the details of the key we have just by executing the

following commands:

●

!"! $$:/8!&)")/8* +;&-*


9/19

9

Figure 7: Validating extended data for the new key

We see here the default hash list of “2.8.3” as Maxwell asserts is the only available choice. This

is displayed in Fig. 7 on the line that lists the “pref -hash-algos”. Our next exercise is to change the

default algorithms used in our newly created key to implement a new selection based on the hash

list, “8,2,9,10,11”. In doing this, we logically prove that the following statement is not correct:

The “8,2,9,10,11” list was added to the GnuPG code tree as a commit on July 9,

2009, and released inversion 2.0.13 on September 4, 2009.

In this exercise, we are using the 2007/8 version of GnuPG. The consequence of this is that we

are limited to being able to select only those algorithms that are listed in the original codebase. If

algorithms “9,10,11” are not included, then this step would fail. Use the following command to

https://lists.gnupg.org/pipermail/gnupg-announce/2009q3/000294.htmlhttps://lists.gnupg.org/pipermail/gnupg-announce/2009q3/000294.htmlhttps://lists.gnupg.org/pipermail/gnupg-announce/2009q3/000294.htmlhttps://lists.gnupg.org/pipermail/gnupg-announce/2009q3/000294.html


10/19

10

interactively edit the key using the algorithms that were available in the key (note that the key ID

will be the one you have created):

!"! $$&>/*$1&9 ?@ABCDE@DFGHIJ@?

When running the “edit-key” sub-command, the reader would change the listed key value from

our example, “85203B75B1D6C458” to represent the PGP fingerprint of the key that they have just

created.


The list of hash algorithms that Maxwell has stated to be new “8,2,9,10,11” are defined at the

following site:

http://tools.ietf.org/html/rfc4880#section-9.4

We can validate that this site maintained this list in 2007 using the Web Archive:

https://web.archive.org/web/20071027063636/http://www.iana.org/assignments/pgp-parameters

To detail what we are discussing, the numbered hash algorithms are listed below:

? ,K


11/19

11

Figure 9: GPG 1.4.7 install on Windows.

In completing the change to the private key for the exercise, it is important to remember to save

using the “ save” interactive command. This is demonstrated in Fig. 10. This step is crucial as the

changes made to the keys are not permanent until the “save” command has been issued.



12/19

12

Having completed this exercise, the reader can now check that the newly created PGP key has

incorporated the changes and now includes the selected hash algorithms. This is completed using

the following command:

!"! $% $$&'"()* +;&-*


13/19

13

“ We already noted that RSA-3072 is an odd form of encryption to use in 2008, but there is

other metadata in these keys that seem to postdate 2008.”

Keys are clearly selected for purpose. The security requirements are matched against the

economic requirements of creating and running a particular key length. For longer keys, the amount

of computational power required to both create and implement the level of desired encryptionincreases. If a key is only used for limited purposes and a low cost function, the key length selected

is generally lower. When a key is required to remain secure for a long period of time, the key length

needs to be increased to accommodate this requirement.

The following page details the use of RSA 3072 in 2007:

http://www.linuxquestions.org/questions/linux-security-4/gpg-rsa-or-dsa-with-el-gamal-for-

new-keys-565242/

It is important to note that at this time, due to vulnerabilities with SHA-1 and DH, RSA 3072

was a secure choice and was not uncommon. When the requirement was to maintain a signed

document for more than a decade or until at least 2020, the usual choice of keys was 3072 bit RSA.

The following exercise details the creation of an RSA-3072-bit key using the GnuPG 1.4.7

software:


We then issue the password in order to complete the creation of a new key. This is demonstrated

in Fig. 13.

http://www.linuxquestions.org/questions/linux-security-4/gpg-rsa-or-dsa-with-el-gamal-for-new-keys-565242/http://www.linuxquestions.org/questions/linux-security-4/gpg-rsa-or-dsa-with-el-gamal-for-new-keys-565242/http://www.linuxquestions.org/questions/linux-security-4/gpg-rsa-or-dsa-with-el-gamal-for-new-keys-565242/http://www.linuxquestions.org/questions/linux-security-4/gpg-rsa-or-dsa-with-el-gamal-for-new-keys-565242/http://www.linuxquestions.org/questions/linux-security-4/gpg-rsa-or-dsa-with-el-gamal-for-new-keys-565242/


14/19

14


Again using the “gpg --edit-key” command the reader can update the PGP key such that they

can create the required RSA encryption sub-key. In this case, the key ID is added to the commandand issued as follows:

!"! $$&>/*$1&9 NC@@H?BI



15/19

15

We create the encryption key using the “addkey” command. This is demonstrated in Fig. 15.


Finally, it is again important to save the key using the “save” command. This is documented in

Fig. 16. If the save command is not issued in the interactive session, the changes made to the key

will not be saved permanently.


16/19

16


This exercise has taken the reader through the creation of a 3072-bit RSA PGP key using GnuPG1.4.7 as it was compiled into a Microsoft Windows binary in 2007, thereby disproving the claims

made in the Motherboard article. From this we can only conclude that the perpetrators of that

misinformation did not understand the workings of PGP sufficiently to implement a different hash

algorithm that was, as we have clearly demonstrated, readily deployed over a year before the release

of the version used in the creation of the disputed keys. We hope that the foregoing explanation will

go some way towards their education.

Maxwell states that his copy of the key log is definitive, however he has not supplied any

timestamped supporting evidence to validate this assertion. We may either conclude that Gregory

Maxwell understood what he was asserting and has intentionally misled the community in stating

that the PGP keys referenced had been backdated, or that a Bitcoin core developer did not understand

the workings of PGP sufficiently. Bitcoin was designed to allow for validation and proof in places

where trust was being abused. It was created to ensure that trust authority alone is not sufficient.

4. On centralisation

There is an inherent warning in the foregoing discussion with regard to the growing power of

individuals who may not fully grasp the full potential of the Blockchain but who nevertheless have

a disproportionate level of influence. A case in point is the current dispute regarding the size of the


17/19

17

Blockchain. It is not the increase in size of the Blockchain that is leading towards centralisation, it

is the creation of an unintended scarcity. In limiting the size of the Block, the issue of control and

the use of the protocol is centralised to a limited number of developers. The Bitcoin protocol was

designed to be the primary protocol in the same manner that IPv4 and soon IPv6 are the primary

networking protocols. It may be that changes to Bitcoin lead to forks in the future just as IPv4 is

migrating towards IPv6, but the core of the Internet remains based on a single set of protocols. Thecore of this system is an RFC or “request for comment” system and not a fixed standard.

The result is that we have multiple protocol stacks across the Internet that are interacting. This

is the plan for Bitcoin and the Blockchain. The bitcoin core protocol was never designed to be a

single implementation maintain by a small cabal acting to restrain the heretics. In restricting the

Blocksize, the end is the creation of a centralised management body. This can only result in a

centralised control function that was never intended for Bitcoin. Satoshi was removed from the

community to stop this from occurring. Too many people started to look to Satoshi as a figurehead

and controller. Rather than experimenting and creating new systems within Bitcoin, many people

started to expect to be led. In the absence, the experiment has not led to an ecosystem of

experimentation and research, of trial and failure, but one of dogma and rhetoric.

Several core developers, including Gregory Maxwell have assumed a mantle of control. This is

centralisation. It is not companies that we need to ensure do not violate our trust, but individuals.

All companies, all governments and all of society consists of individuals and the interactions theycreate. In the past, these ideas were discussed extensively with Mike Hearn and others who saw the

need for the Blockchain to be unconstrained. Gregory Maxwell has been an avid supporter in

limiting Blocksize3. The arguments as to the technical validity of this change are political and act

against the core principles of Bitcoin. The retention of limits on Block size consolidates power into

the hands of a few individuals. This is the definition of centralisation.

The Internet was not a controlled system. Many applied for and received the equivalent of a

standard in implementing an RFC, but at the same time, the development of new Internet Protocols

occurred prior to the writing of an RFC. Many RFCs came to be written years after the protocol was

widely adopted. This is what Bitcoin was designed for. Not for cautious stagnation as the banks

have allowed themselves to enter, but for change and growth. Bitcoin was not created to have a

single core team developing. It was developed in a manner that would allow anyone to create their

own version. Each version would compete and could lead to forks, but this is a desired outcome.

Where a fork is created it will either lead to a new set of protocols, or it will be rejected. Only thenew forms of transactions are truly at risk and their introduction can be planned without the

requirements for a central governing body.

5. Conclusion

We have demonstrated that the claims made in the Motherboard article [2] regarding the keys

associated with Satoshi are incorrect. Specifically, that the PGP key information we have analysed

demonstrates that the keys could have been created earlier rather than backdated as was alleged. In

so doing we have provided something of an instructional guide on key creation and also a warning

against the centralisation of bitcoin control – especially by those who may lack sufficient technical

expertise.

Political bias should not exist within a technical solution based on the mathematical analysis of

a universal source of truth. The position that has been assumed by those seeking centralisation ofBitcoin for many years is to create an artificial scarcity within Bitcoin associated with the limits on

the Blocksize. This is an issue that can be addressed through technology. The assertions that have

3 https://www.reddit.com/user/nullc

https://www.reddit.com/user/nullchttps://www.reddit.com/user/nullchttps://www.reddit.com/user/nullchttps://www.reddit.com/user/nullc


18/19

18

been made concerning PGP keys are a matter of fact. As the evidence is readily available, the

difficulty becomes the same of mitigating demagoguery. Rhetoric is frequently upheld over reason

whose voice is soft.

The response has not been one of reason, leading to the formation of a mob mentality. Just as

the main benefits of a digital currency are lost if a trusted party is still required to prevent double-

spending, the benefits to society of a free and independent media are lost if we allow ourselves to be bamboozled through the untested statements of an authority. Those with power need to be held

to a higher standard. When we read a statement, we should not assume its validity on face value

alone nor on the trust of an individual with an agenda. The technical analysis presented in this paper

can be validated. This is the process that should have occurred prior to Sarah Jeong’s statement and

reporting of Gregory Maxwell in Motherboard. Trust placed in authority needs to be challenged [7].

Science and reason are based on the analysis of empirically derived evidence. When facts are

available, these, in the manner of the mathematical proof contained within Bitcoin need to be

analysed and validated.

The Motherboard article presented assertions as a matter of fact rather than as opinion. This has

led the community to believe that the notion of a signing subkey was created in 2014 as if it was a

fact and not a possibly uninformed opinion. It, and the encryption subkey, are only self-signed. We

have shown this assertion to be false. What has not been addressed is that there is an expiration

subpacket on the self signature of the disputed key which puts a time limit on the certification. Thisfollows from the definition in RFC-4880 at 5.2.3.6. Hal Finney helped write this document and

would have noted the error that has been distributed by the media. He would have further noted that

GPG will automatically use the most recent signing/encryption subkey when the master is

referenced. Where there are multiple keys in a keyring, it can be necessary to force a specific

key/subkey to be selected. To do this, it is essential that the user add an exclamation mark after the

Key ID.

The facts of this case are that the PGP key information we have analysed demonstrates that the

keys could have been created earlier and not later and backdated as was alleged. What we do not

know is whether this hasty assertion was an error from ignorance or one based on malicious intent.

It is always important to note that an absence of evidence is not evidence.

No evidence as to the existence of the PGP keys has been presented. The only evidence that

these keys have been uploaded after 2011 was a statement by Gregory Maxwell who said that he

had a 2011 chatlog where he and others discussed “ fake” Satoshi keys (keys tied to Satoshi’s emailsthat weren’t the Original Key ) on the keyserver ” [2]. The interesting aspect to this statement was

that none of the participants to this thread thought to ask Satoshi if the keys were valid as would be

the practice in a web of trust.

Silence is not a confession. Before we decide to believe what we believe, it is necessary to verify

the information being asserted. We can clearly assert that the evidence Maxwell has presented to

justify his assertions to Motherboard that the PGP keys is false. His motives in this remain a

mystery. All we can state as to the intentions of Motherboard and Gregory is “Whatever’s going on

here, it’s pretty fishy.”


19/19

19

References

[1] “Development & Technical Discussion (Moderator: gmaxwell) > secp256k1”

https://bitcointalk.org/?topic=2699.0

[2]

Jeong, S. "Satoshi's Pgp Keys Are Probably Backdated and Point to a Hoax."http://motherboard.vice.com/read/satoshis-pgp-keys-are-probably-backdated-and-point-to-a-

hoax.

[3] Maxwell, Gregory. "Blockchain Scale Tests by (Alleged) Satoshi! 340 Gb Blocks, 568k

Transactions! (Imgur.Com)." (2015)

[4] NIST Cryptographic toolset: Digital Signatures,

http://csrc.nist.gov/groups/ST/toolkit/digital_signatures.html (see also FIPS PUB 186-4

http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf )

[5] Orman H. & Hoffman P. (2004) "Determining Strengths for Public Keys Used for

Exchanging Symmetric Keys", RFC 3766, , 04/2004. https://www.rfc-

editor.org/info/rfc3766

[6]

Nakamoto, Satoshi (31 Oct 2008). "Bitcoin: A Peer-to-Peer Electronic Cash System"

(www.bitcoin.org).

[7] Thoreau, Henry David. 1849 "On the Duty of Civil Disobedience".

http://www.ibiblio.org/ebooks/Thoreau/Civil%20Disobedience.pdf

[8] Callas, J., Donnerhacke, L., Finney, H., Shaw, D. & Thayer, R. (November 2007) RFC

4880. OpenPGP Message Format. https://tools.ietf.org/html/rfc4880
https://bitcointalk.org/?topic=2699.0https://bitcointalk.org/?topic=2699.0http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdfhttp://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdfhttp://www.bitcoin.org/http://www.bitcoin.org/http://www.bitcoin.org/http://www.ibiblio.org/ebooks/Thoreau/Civil%20Disobedience.pdfhttp://www.ibiblio.org/ebooks/Thoreau/Civil%20Disobedience.pdfhttp://www.ibiblio.org/ebooks/Thoreau/Civil%20Disobedience.pdfhttp://www.bitcoin.org/http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdfhttps://bitcointalk.org/?topic=2699.0

Date post:	07-Jul-2018
Category:	Documents
Upload:	clapujugas
View:	216 times
Download:	0 times

Appeal to Authority: a Failure of Trust

Documents