## Description

## 2 Phase I: Developing software for digital signature

In this phase of the project, you will develop software for signing given any message. For digital

signature (DS) you will us an algorithm, which consists of four functions as follows:

• Public parameter generation: Two prime numbers p and q are generated with q|p − 1,

where q and p are 224-bit and 2048-bit integers, respectively. The generator g generates a

subgroup of Z

∗

p with q elements. Naturally, g

q ≡ 1 mod p. Note that in your system q, p,

and g are public parameters shared by all users, who have different secret/public key pairs.

Refer to the slide (with title “DSA Setup” in chapter 10 for an efficient method for parameter

generation).

• Key generation: A user picks a random secret key 0 < α < q and computes the public

key β = g

α mod p.

• Signature generation: Let m be an arbitrary length message. The signature is computed

as follows:

1. k ← Zq, (i.e., k is a random integer in [0, q − 1]).

1

2. r = g

k

(mod p)

3. h = SHA3 256(m||r)

4. s = α · h + k (mod q)

5. The signature for m is the tuple (s, h).

• Signature verification: Let m be a message and the tuple (s, h) is a signature for m. The

verificiation proceeds as follows:

– v = g

sβ

−h

(mod p)

– h˜ = SHA3 256(m||v)

– Accept the signature only if h = h˜ mod q

– Reject it otherwise.

Note that the signature generation and verification of this DS are different than those discussed in

the lecture.

You are required to develop Python software that implements those four functions; namely

Setup for public parameter generation, Key Generation, Signature Generation and

Signature Verification. You are required to test your software using the test routines in

“DS Test.py” provided in the assignment package.

In “DS Test.py”, there are four basic test functions:

1. checkDSparams(q, p, g) takes your public parameters (q, p, g) and check if they are correct.

It returns 0 if they are. Otherwise, it returns a code that indicates the problem.

2. CheckKeys(q, p, g, α, β) takes your public parameters (q, p, g) and key pair (α, β) and check

if the key pair is correct. It returns 0 if they are; otherwise it returns -1.

3. CheckSignature(q, p, g, α, β) takes your public parameters (q, p, g), key pair (α, β) and

generates a signature for a random message and verifies the signature. It returns 0 if the

signatures verifies; otherwise it returns -1.

4. CheckTestSignature() reads the file “TestSet.txt” (provided in the assignment package),

which contains public parameters, a public key, and 10 randomly chosen messages and their

signatures. The test code reads them and runs signature verification function. The test code

returns 0 if all signatures verify; otherwise it returns -1.

In this phase of the project, you are required to upload only a file named “DS.py” with sufficient

comments. We will be able to test your code using “DS Test.py’. If your software cannot be tested

by “DS Test.py’ as it is, you will get no credit.

3 Phase II: Developing software for transaction and implementing

## proof of work

In this phase of the project, you are required to generate a block of random transactions and Proofof-Work for the block. The details are given in the following subsections. For further information

about bitcoin and blockchain, please refer to bitcoin.pptx provided in the assignment package.

2

### 3.1 Transaction

A transaction contains information of a payment (transaction) from the payer to the payee and is

in the following format:

*** Bitcoin transaction ***

Serial number:

Payer public key (beta):

Payee public key (beta):

Amount:

Signature (s):

Signature (h):

Explanations of these fields are as follows

Serial Number: is a uniformly randomly generated 128-bit integer

Payer public key (beta): is the public key of the person making the payment

Payee public key (beta): is the public key of the person receiving the payment

Amount: is the amount in Satoshi being transferred in range [1, 1000000]

Signature (s): Signature (s part) of the transaction by Payer

Signature (h): Signature (h part) of the transaction by Payer

Note that the payer and payee are identified by their public keys in the transaction, which is

signed by the private key of the payer. Therefore, the transaction can be verified by the public

key of the payer. For the signature you are required to use the set of public parameters in file

“pubparams.txt” provided in the assignment package. A sample block of random transactions is

given in file “transactions sample.txt” also provided in the assignment package.

In this part of the project, you are required to generate random transactions and write those

transactions into a file named “transactions.txt”. For this, you will develop a function named

“gen random tx(q, p, g)”. You have to test your transactions in “transactions.txt’ using

CheckBlock() function in Test code “PhaseII Test.py’ before submission.’

As a deliverable, you are required to submit a file with the name “Tx.py” that should include

the function

“gen random tx(q, p, g)”

that will take the public parameters and output a random transaction in the format defined above.

### 3.2 Implementing Proof-of-Work (PoW)

In cryptocurrency systems, blockchain network members (a.k.a. miners) approve transactions by

running the proof-of-work (PoW) algorithm. The PoW algorithm is a consensus protocol that determines who will write the next block of the transactions to the blockchain. All miners participate

in the protocol as they receive a commision if they win.

A miner reads a block of transactions, adds a random number called nonce at the end and tries

to compute a hash value of the special form. In particular, the hash value must start with x 0 bits;

i.e., if you print the hash value with “hexdigest()”, the first PoWLen = x/4 hexadecimal digits

must be 0 (pick x a multiple of 4). The hash value with this property is known as Proof-of-Work

or shortly PoW. To find PoW, the miner tries different nonce values chosen at random.

The miner, who comes up with such hash value first, wins the right to add the block to the

chain and thus recevies the commision. A sample block is given in file “block.txt” with x = 20

3

provided in the assignment package.

You are required to write a function (with the name “PoW”) that reads the transactions in the

file “transactions.txt” and computes a PoW for the block. PoWLen must be at least 5. Once your

programs finds the PoW for the block, it appends the nonce at the end of the block and writes it

into a file with the name “block.txt”. A sample block is provided in the file “block sample.txt” in

the assignment package.

You are strongly recemmended to test your codes with the test functions in “PhaseII Test.py”

before submission as we will use it to test your codes. If your codes will not pass the tests in

“PhaseII Test.py”, you will get no credit in this phase of the project.

Finally, as generating PoW takes quite some time, you are recommended to test your codes

with smaller PoWLen first such as PoWLen = 3 to make sure your code is working. Then you try

larger PoWLen.

### 3.3 Bonus I – Competition

The group that will submit a block with the longest PoW will recieve an extra 10% in this Phase.

Submit your block in the file “block.txt”. To qualify for the competition, PowLen must be at least

7. In case of tie, the earliest submission wins. Make sure that “block.txt’ is testable by the “Test

II” in “PhaseII Test.py”.

4 Appendix I: Timeline & Deliverables & Weight & Policies etc.

Project Phases Deliverables Due Date Weight

Project announcement 07/12/2018

First Phase Source code (DS.py) 14/12/2018 25%

Second Phase Source codes 21/12/2018 40%

( Tx.py and PoW.py)

Bonus – I block.txt 21/12/2018 10%

Third Phase TBA 28/12/2018 TBA

Bonus – II TBA 28/12/2018 TBA

4.1 Policies

• You may work in groups of two.

• You may be asked to demonstrate a project phase to a TA or the instructor.

• In every phase, we will provide you with a validation software in python language that can

be used to check your implementation for correctness. We will also use it to check your

implementation. If your implementation in a project phase fails to pass the validation, you

will get no credit for that phase.

4