DEPARTMENT OF CSE

COURSE NAME:
INTRODUCTION TO BLOCKCHAIN
& CRYPTO CURRENCIES
COURSE CODE:
22CS2233
 AIM OF THE
SESSION
To familiarize students with the basic concepts of Cryptography

INSTRUCTIONAL
OBJECTIVES
This Session is designed to:
Demonstrate Principles of Authentication Cryptography

LEARNING OUTCOMES

At the end of this session, you should be able to:

1. Define Hash Function Algorithms
2. Message Authentication Code (MAC)
3. RSA Signatures and other methods
 Index
 Authentication: Basics
 Digital Signature
 Hash Function Algorithms
 Message Authentication Code (MAC)
 RSA Signatures
 MD5
 Digital Signature Standard (DSS)
 Digital Signature Algorithm (DSA)
 Secure Hash Algorithm (SHA)
 Bitcoin and address
Authentication:
Scope and
Basics
 AUTHENTICATION

• Authentication is for someone to identify the party

communicating to
• Client and server
• Alice and Bob
• Identity check is usually required when establishing
the communication
• Access authentication (service login, tunnel setup,
etc.)
• Message authentication
 AUTHENTICATION FACTORS
• Something you know
• Password
• Secret (symmetric) key
• Private (asymmetric) key
• Something you have
• SecureID token
• Smartcard
• USB key
• Something you are
• Biometrics
• Others: Cognometrics, Cybermetrics, location, time, etc.
 ONE-WAY AUTHENTICATION

Protection against unauthorized modification by

encrypted message digest
• Symmetric Key Solution: Message Authentication
Code (MAC) formed by using a keyed message
digest function
• Asymmetric Key Solution: Digital Signature formed
by encrypting the message digest with the
document author’s private key
 AUTHENTICATION PROTOCOLS

• Used to convince parties of each other’s identity and to exchange

session keys
• May be one-way or mutual (bi-directional)
• Key issues are

• Confidentiality: to protect session keys

• Timeliness: to prevent replay attacks
AUTHENTICATION CASE I
Goal: Bob wants Alice to “prove”
her identity to him
Protocol: Alice says “I am Alice”
“I am Alice”
Failure scenario??
In a network,
Bob can not “see”
Alice, so Trudy
simply declares
“I am Alice” herself to be Alice
AUTHENTICATION CASE II
Protocol: Alice says “I am Alice” in an IP pack
containing her source IP address
Alice’s “I am
IP addressAlice”

Alice’s “I am
IP addressAlice”
Failure scenario??
Trudy can create
a packet “spoofing”
Alice’s address
AUTHENTICATION CASE III

Protocol: Alice says “I am Alice” and

sends her
Alice’s Alice’s “I’m
IP addrpasswordAlice secret password to “prove” it.
”
Failure scenario??
Alice’s OK
IP addr

Alice’s Alice’s “I’m

IP addrpasswordAlice
”

Playback Attack: Trudy records Alice’s packet and later

plays it back to Bob
AUTHENTICATION CASE IV
Goal: avoid playback
Nonce: number
attack (R) used only once-in-
a-lifetime
Protocol: to prove Alice “live”, Bob sends Alice nonce, R. Alice must
return R, encrypted with shared secret key
“I am Alice”

R Failure scenario??
KA-B(R) Alice is live, and
only Alice knows
key to encrypt
nonce, so it must
be Alice!
AUTHENTICATION CASE V
Case IV used shared symmetric key. Can we authenticate using public key
techniques?

Protocol: use nonce, public key

cryptography
“I am Alice”
Bob computes
R + -
K (K (R)) = R
A A
KA -(R) and knows only
“send me Alice could have
your public the private key,
key” that encrypted R
+ -
KA+ such that
K (K (R)) =R
A A
AUTHENTICATION CASE V (CONT.)
Man (woman) in the middle attack: Trudy
poses as Alice (to Bob) and as Bob (to
Alice)
“I am Alice”
“I am Alice”
R

R KM -(R)
KA -(R)
“Send me your public key”

‘Send me your public key” KM+

KA+ KM +(m)
Trudy gets
- + KA +(m) - +
m = K (K (m)) m = K (K (m))
A A M M
sends m to
Alice
encrypted
with Alice’s
AUTHENTICATION CASE V (CONT.)

Man (woman) in the middle attack:

Trudy poses as Alice (to Bob) and
as Bob (to Alice)

Difficult to detect:
 Bob receives everything that Alice sends, and
vice versa. (e.g., so Bob, Alice can meet one
week later and recall conversation)
 Problem: Trudy receives all messages as well!
 AUTHENTICATION THREATS

• Stealing authentication credentials

• Sniffing, man-in-the-middle, keystroke loggers
• Attacks on the authentication protocol
• Sniffing, Man-in-the-Middle (MITM), keystoke loggers,
replay attacks
• Stealing proof of identity
• Social engineering
Digital Signature
 WHAT ARE DIGITAL CERTIFICATES?

• A “credential” that identifies an “entity”, a person or

resource
• Specifies that a specific public key is owned by a specific
named entity
• Generally, ownership of public key implies “exclusive”
control of related private key
• Signature “binds” the public key to its named owner
(subject)
 WHAT ARE DIGITAL CERTIFICATES?
• The simplest certificate just contains:
• Information about the entity that is being
certified to own a public key
• That public key
• And all of this is
• Digitally signed by someone trusted (like your
friend or a CA)
WHAT ARE DIGITAL CERTIFICATES?
CERTIFICATE

Issuer
Subject

Subject
Public Key

Issuer
Digital
Signature
CERTIFICATE GENERAL STRUCTURE
 DIGITAL SIGNATURE
Cryptographic technique analogous to hand-written signatures
• Sender (Bob) digitally signs document, establishing he is document owner/creator
• Recipient (Alice) can prove to someone that Bob, and no one else (including Alice),
could have signed document

It provides the ability to:

• verify author, date & time of signature
• authenticate message contents
• be verified by third parties to resolve disputes
Verifiable and Non-forgeab
 DIGITAL SIGNATURE PROPERTIES
• Must depend on the message signed
• Must use information unique to sender
• To prevent both forgery and denial
• Must be relatively easy to produce
• Must be relatively easy to recognize & verify
• Be computationally infeasible to forge
• With new message for existing digital signature
• With fraudulent digital signature for given message
• Be practical to save digital signature in storage
DIGITAL SIGNATURE: EXAMPLE
Simple digital signature
-
for message m: -
Bob signs m by encrypting it with his private key
KB , creating “signed” message, KB(m)
-
Bob’s private KB
key
Bob’s message m -
KB(m)
Dear Alice
Oh, how I have
Public key m signed
missed you. I think
of you all the time! encryption (encrypted)
… (blah blah blah) algorithm with Bob’s
Bob private key
 DIRECT DIGITAL SIGNATURES

• Involves only sender & receiver

• Assumes receiver has sender’s public-key
• Digital signature made by sender signing entire message or hash with
private-key
• Can encrypt using receivers public-key
• Important to sign first then encrypt message & signature Security
depends on secure private-key
ARBITRATED DIGITAL SIGNATURES
• Involves use of arbiter A
• Validates any signed message
• Then dates and sends to recipient

• Requires suitable level of trust in arbiter

• Can be implemented with either private or public-key algorithms
• Arbiter may or may not see message
HASH FUNCTION ALGORITHMS
HASH FUNCTION ALGORITHMS
HASH FUNCTION ALGORITHMS
 HASH FUNCTION ALGORITHMS

• MD5 and SHA

• Just a hash value of between 128 bits (MD5) and 512 bits of key
(SHA512)
• Great support in OSes
• MD5 and SHA1 were broken by Prof. Xiaoyun Wang and her team
• MD5: construct MD5 collisions in a few hours on a single notebook
computer (improved)
• SHA1: lowering complexity required for finding a collision in SHA-1 to
263 operations (a brute-force search would require 280 operations)
CREATING A DIGITAL SIGNATURE
Message or File 128 bits Message Digest Digital Signature
This is a Py75c Jrf843kjf
really %bn&*)9| gf*£
long fDe^bDFaq# $&Hdif*7
message xzjFr@g5=& oUsd*&
about nmdFg$5knv @:<CHD
Bill’s… Md’rkvegMs FHSD(**
”
Hash Asymmetric
(SHA, MD5) Encryption

Calculate a short message digest

from even a long input using a private Signatory’s
one-way message digest function private key
(hash)
VERIFYING A DIGITAL SIGNATURE
Py75c%bn&*)
Digital Signature 9|fDe^bDFaq
Jrf843kjf #xzjFr@g5=
gf*£$&Hd Asymmetric &nmdFg$5kn
if*7oUsd decryption vMd’rkvegMs”
*&@:<CHD
FHSD(** (e.g. RSA) ? == ?
Are They Same?
Signatory’s
Py75c%bn&*)
public key Some hash function 9|fDe^bDFaq
(e.g. MD5, SHA…) #xzjFr@g5=
Everyone has &nmdFg$5kn
vMd’rkvegMs”
access to trusted
public key of the This is a
signatory really long Original Message
message
about Bill’s…
 Message Authentication Code (MAC)
• generated by an algorithm that creates a small fixed-sized
block
• depending on both message and some key
• like encryption though need not be reversible
• appended to message as a signature
• receiver performs same computation on message and checks
it matches the MAC
• provides assurance that message is unaltered and comes
from sender
 Hash Functions
• condenses arbitrary message to fixed size
• usually assume that the hash function is public and
not keyed
• Exception MAC which is keyed
• hash used to detect changes to message
• can use in various ways with message
• most often to create a digital signature
 KEYED HASH FUNCTIONS AS
MACS
• have desire to create a MAC using a hash function
rather than a block cipher
• because hash functions are generally faster
• not limited by export controls unlike block ciphers
• hash includes a key along with the message
• original proposal:
KeyedHash = Hash(Key|Message)
• some weaknesses were found with this
• eventually led to development of HMAC
 Secret Value is added by both parties to message before the “hash”
function is used to get the Message Integrity Check (MIC). It is
removed before transmission.

MIC

MIC MIC

MIC MIC

It is critical that a forger cannot compose a different message that would produce the same MIC value.
 DIGITAL SIGNATURE AT WORK
Message Message

Digest
Hash Function Digest
Algorithm Hash Function
Algorithm

Digest
Public Key

Private Key Encryption Decryption

Signature Expected Actual

Digest Digest
Signer Channel Receiver
Message Digest 5 (MD-5)

MD5 is widely used to store

passwords.
To mitigate against the
vulnerabilities, one can add a salt
to the passwords before hashing
them.
 RSA SIGNATURES
• Public key is (n,e), private key is d
• To sign message m: s = hash(m)d mod n
• Signing and decryption are the same mathematical
operation in RSA
• To verify signature s on message m:
se mod n = (hash(m)d)e mod n = hash(m)
• Verification and encryption are the same mathematical
operation in RSA
• Message must be hashed and padded (why?)
 DIGITAL SIGNATURE STANDARD
(DSS)
• uses the SHA hash algorithm
• designed by NIST & NSA in early 90's
• DSS is the standard, DSA is the algorithm
• a variant on ElGamal and Schnorr schemes
• creates a 320 bit signature, but with 512-1024
bit security
• security depends on difficulty of computing
discrete logarithms
 DIGITAL SIGNATURE ALGORITHM (DSA)
• U.S. government standard (1991-94)
• Modification of the ElGamal signature scheme (1985)
• Key generation:
• Generate large primes p, q such that q divides p-1
• 2159 < q < 2160, 2511+64t < p < 2512+64t where 0t8
• Select hZp* and compute g=h(p-1)/q mod p
• Select random x such 1xq-1, compute y=gx mod p
• Public key: (p, q, g, gx mod p), private key: x
• Security of DSA requires hardness of discrete log
• If one can take discrete logarithms, then can extract x (private key) from g x
mod p (public key)
 DIGITAL SIGNATURE ALGORITHM (DSA)

• Key Generation
• Choose an L-bit prime p, where 512≤L ≤1024, and L is divisible by 64 and 2 L-
1
<p<2L.

• Choose a 160-bit prime q, such that p-1=qz, where z is any natural number.

• Choose h, where 1<h<p-1 such that

g=hz mod p>1 or g=h (p-1)/q mod q.
 DIGITAL SIGNATURE ALGORITHM (DSA)

• Key Generation
• Choose x by some random method, where 0<x<q; this is
user’s private key.
• Calculate y=gx mod p, this s user’s public key.
• Public key is (p,q,g,y) and Private key is x.
 DSA SIGNATURE CREATION
• to sign a message M the sender:
• generates a random signature key k, 1<k<q
• k must be random, be destroyed after use, and never be
reused
• then computes signature pair:
r = (gk(mod p))(mod q)
s = (k-1.SHA(M)+ x.r)(mod q)
• sends signature (r,s) with message M
 DSA: SIGNING A MESSAGE
r = (gk mod p) mod q

Private
key
Random secret (r,s) is the
between 0 and signature on M
q
Message

Hash function (SHA-1)

s = k-1(H(M)+xr) mod q
 DSA SIGNATURE
VERIFYING-1
• Calculate w=(s )mod q
• Calculate u1=[SHA(M’)*w](mod q) here SHA (M’) is
encrypted or signed message to receiver.
• Calculate u2=r*w(mod q)
• Calculate v=[g u1 * y u2 mod p] mod q
• Signature valid if v=r.
DSA: VERIFYING A SIGNATURE
Public key

Compute
Messag (gH(M’)w  yr’w mod q mod p) mod q
e

Signatur
e

w = s’-1 mod q
If they match, signature is
valid
 WHY DSA VERIFICATION WORKS
• If (r,s) is a valid signature, then
r  (gk mod p) mod q ; s  k-1(H(M)+xr) mod q
• Thus H(M)  -xr+ks mod q
• Multiply both sides by w=s-1 mod q
• H(M)w + xrw  k mod q
• Exponentiate g to both sides
• (gH(M)w + xrw  gk) mod p mod q
• In a valid signature, gk mod p mod q = r, gx mod p = y
• Verify gH(M)wyrw  r mod p mod q
 SECURITY OF DSA

• Can’t create a valid signature without private key

• Can’t change or tamper with signed message
• If the same message is signed twice, signatures are different
• Each signature is based in part on random secret k
• Secret k must be different for each signature!
• If k is leaked or if two messages re-use the same k,
attacker can recover secret key x and forge any signature
from then on
 PS3 EPIC FAIL

• Sony uses ECDSA algorithm to sign authorized software for Playstation 3

• Basically, DSA based on elliptic curves
… with the same random value in every signature Trivial to extract master signing
key and sign any homebrew software – perfect “jailbreak” for PS3

• Announced by George “Geohot” Hotz

and Fail 0verflow team in Dec 2010

Q: Why didn’t Sony just revoke the key?

SECURE HASH ALGORITHM (SHA)

• SHA-1 stands for Secure Hash

Algorithm. It was developed by the
NIST (National Institute of Standards
and Technology) in conjunction with the
NSA. Like MD5, SHA-1 is based on MD4.
SECURE HASH ALGORITHM (SHA)
• The changes made in SHA-1, however,
are considerably different from the
changes made in MD5. Also, SHA-1
produces a message digest value that is
160 bits long, which increases its
resistance to attack.
SECURE HASH ALGORITHM (SHA)

• Note that this algorithm is often

called SHA. There was a SHA-0, which
is now obsolete. SHA and SHA-1 are
now used to mean the same thing.
SECURE HASH ALGORITHM (SHA-1)

• SHA-1 takes as input a message with

a maximum length of less than 264
bits and produces as output a 160-bit
message digest. The input is
processed in 512-bit blocks.
SECURE HASH ALGORITHM (SHA-1)
The processing consist of following steps:
1. Append padding bits
2. Append length
3. Initialize hash buffer
4. Process message in 512 bit (16-
word)blocks.
5. Output
SECURE HASH ALGORITHM (SHA-
1)

 Append padding bits

The message is padded so that its length is congruent
to 448 modulo 512. Padding is always added.
The number of padding bits is in the range of 1 to 512.
Example- 448(message) + 512 (padding bit) = 960 bits
SECURE HASH ALGORITHM (SHA-1)

 Append length
Append 64 bit length of the original message to the result
step 1.
If original length is greater than 264 only low-order 64 bits
of the length are used. The length of expanded message is
L*512 bits.
No of blocks=L
No of words=N=16*L
SECURE HASH ALGORITHM (SHA-
1)

 Initialize hash buffer

A 160-bit buffer is used to hold intermediate
and final results of the hash function.
The buffer can be represented as five 32-bit
registers (A,B,C,D,E).
SECURE HASH ALGORITHM (SHA-1)
 Initialize hash buffer

These register are initialized to the following values in hexadecimal,

low-order bytes first-
word A:01 23 45 67
word B:89 ab cd ef
word C:fe dc ba 98
word D:76 54 32 10
word E:f0 e1 d2 c3
SECURE HASH ALGORITHM (SHA-1)

Process message in 512 - bit (16-Word) blocks

The heart of the algorithm is a module that
consists of 20 rounds.
Each round takes as input the 512-bit buffer
value A,B,C,D,E and updates the contents of
the buffer.
SECURE HASH ALGORITHM (SHA-1)

Output
After all N 512-bit blocks have been
processed;
The output from the stage is the
160-bit message digest.
 Addresses

• Bitcoin and Ethereum uses Elliptic Curve

Digital Signature Algorithm* (ECDSA) for
signing transactions. Here are the steps.
• We first generate a private key which is 256
bits (64 hex/32 bytes).

*Specifically, ECDSA sec256k1. See https://en.bitcoin.it/wiki/Secp256k1

 Addresses
• We use ECDSA to derive a 512 bit public key
(remember, the public key contains information
on two coordinates). The private and public
keys are known as the “key pair”.
• You can sign transactions with the private key
• Anyone with your public key can verify the
signature is valid
• The Bitcoin and Ethereum addresses are linked
to these keys
*Specifically, ECDSA sec256k1. See https://en.bitcoin.it/wiki/Secp256k1
 Ethereum
• Generate a key pair
• Public key is 512 bits (128 hex characters/64 bytes)
• Hash with Keccak-256 the public key (64 hex
characters/32 bytes)
• Take last 40 hex characters (20 bytes) as your public
address
• When prefixed with ‘0x’ it becomes 42 hex characters

http://gavwood.com/paper.pdf
 Ethereum
• Hash with Keccak-256 the public key (64 hex
characters/32 bytes)

• Check here-
https://emn178.github.io/online-tools/keccak_256.ht
ml

http://gavwood.com/paper.pdf
 Ethereum
https://www.oreilly.com/library/view/m
astering-ethereum/9781491971932/ch
04.html
• Private key 68
f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b27056084
52f315

• Public key (04 prepended)

046e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444
683bae07b83b5c38e5e2b0
C8529d7fa3f64d46daa1ece2d9ac14cab9477d042c84c32ccd0
ash of the public key, it is important to let the hashing algo know the format is “hex”. See https://leventozturk.com/engin
 Ethereum https://www.oreilly.com/library/view/m
astering-ethereum/9781491971932/ch
04.html
• Keccak-256 of public key (remove the 04)* 69
5bc342ed616b5ba5732269001d3f1ef827552ae1114027bd3ecf1f086ba0f

• Last 40 hex (20 bytes) and prepend with 0x

0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9

sh of the public key, it is important to let the hashing algo know the format is “hex”. See https://leventozturk.com/engine
 Bitcoin addresses
• Bitcoin addresses have more steps but the idea is
very similar
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bi
tcoin_addresses
 Bitcoin addresses
1. Start with private ECDSA key
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

2. Take public key generated with it*

0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA
6

3. Perform SHA-256 on public key

600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408
*65 bytes, 1 byte 0x04, 32 bytes corresponding to x-coordinate; 32 bytes for y coordinate
Bitcoin addresses
4. Perform RIPEMD-160 hash on the result of SHA-256
010966776006953D5567439E5E39F86A0D273BEE

5. Add version number byte in front of RIPEMD-160

00010966776006953D5567439E5E39F86A0D273BEE

445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE84
5C094
6. Perform SHA-256 on extended
RIPEMD-160
 Bitcoin addresses
7. Perform SHA-256 on the previous SHA-256
D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30

8. Take first 4 bytes of 2nd SHA-256 (address

checksum)
D61967F6

9. Add 4 checksum bytes to extended RIPEMD-160 in

stage 5 (25 byte bitcoin address)
00010966776006953D5567439E5E39F86A0D273BEED61967F6
Bitcoin addresses

10. Convert to base58 (upper and lower case letters,

numbers, excluding 0,O,I,l)

16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
This is the bitcoin address.
Bitcoin addresses

75
Bitcoin addresses
 Addresses

• Generate a private key and address:

https://www.bitaddress.org/
• http://bitcoin.stackexchange.com/questions/3041/what-is-
a-130-hex-character-public-key

• https://bitcointalk.org/index.php?topic=78132.0
 ACKNOWLEDGEMENTS

• Many of the text and graphic

materials in this lecture module
come from the following sources:
• Textbook and the website of its
author William Stallings
• Andreas Steffen, Secure Network
Communication, Part III,
Authentication
Thanks