CSE442T Introduction to Cryptography (Lecture 21)

Chapter 5: Authentication

Digital Signature Scheme

“Chain based approach”.

$pk_0\to m_1||pk_1\to m_2||pk_2\to m_3||pk_3\to m_4\dots$

The signature size grows linearly with the message size $n$ .

Improvement:

Use “Tree based approach”.

Instead of creating 1 public key, we create 2 public keys each time and use the shorter one to sign the next message.

For example, let $n=4$ , and we want to sign $m=1100$ .

Every verifier knows the public key.

Then we generates $(pk_0,sk_0),(pk_1,sk_1)$ and store $\sigma, sk_0,sk_1$

$\sigma=Sign_{sk_0}(pk_0||pk_1)$

and generates $\to (pk_2,sk_2)\to (pk_3,sk_3)\to (pk_4,sk_4)$

$\sigma_1=Sign_{sk_1}(pk_{10}||pk_{11})$

$\sigma_{11}=Sign_{sk_{11}}(pk_{110}||pk_{111})$

$\sigma_{110}=Sign_{sk_{110}}(pk_{1100}||pk_{1101})$

$\sigma_{1100}=Sign_{sk_{1100}}(m)$

So we sign $m=1100$ as $\sigma_{1100}$ .

The final signature is $\sigma'=(pk,\sigma,pk_1,\sigma_1,pk_{11},\sigma_{11},pk_{110},\sigma_{110},pk_{1100},\sigma_{1100})$ .

The verifier can verify the signature by checking the authenticity of each public key.

Outputs $m,\sigma'_m$

The signature size grows logarithmically with the message size $n$ .

If we want to sign $m=1110$ for next message, we can just append $1110$ to the end of the previous signature since $pk_1,pk_{11},pk_{110}$ are all stored in the previous signature tree.

So the next signature is $\sigma'_{1110}=(pk,\sigma,pk_1,\sigma_1,pk_{11},\sigma_{11},pk_{111},\sigma_{111},pk_{1110},\sigma_{1110})$ .

The size of the next signature is still $O(\log n)$ .

Advantages:

The signature size is small (do not grow linearly as the number of messages grows).
The verification is efficient (do not need to check all the previous messages).
The signature is secure.

Disadvantages:

Have to store all the public keys securely pair as you go.

Fix: Psudo-randomness.

Use a Pseudo-random number generator to generate random pk/sk pairs.

Since the PRG is deterministic, we don’t need to store the public keys anymore.

We can use a random seed to generate all the pk/sk pairs.

Trapdoor-based Signature Scheme

Idea: use RSA to create

$N=p\cdot q$ , $e\in\mathbb{Z}_{\phi(N)}^*$ , $d=e^{-1}\mod\phi(N)$ (secret key)

We do the “flip” encryption as follows:

Let $c=Enc_{pk}(m)=m^e\mod N$

Then $Dec_{sk}(c)=c^d\mod N=m'\mod N$ .

$\sigma=Sign_{sk}(m)=m^d\mod N$

$Verify_{pk}(m,\sigma)=1\iff \sigma^e=(m^d)^e\mod N=m$

Forgery 1:

Ask oracle nothing.

Pick random $\sigma$ let $m=\sigma^e$ .

Although in this case, the adversary has no control over $m$ , it is still not very good.

Forgery 2:

They want to sign $m$ .

Pick $m_1,m_2$ and $m=m_1\cdot m_2$ .

Ask oracle for $Enc_{pk}(m_1)=\sigma_1$ and $Enc_{pk}(m_2)=\sigma_2$ .

Output $\sigma=\sigma_1\cdot\sigma_2$ , since $\sigma_1\cdot\sigma_2=(m_1^d\mod N)\cdot(m_2^d\mod N)=(m_1\cdot m_2)^d\mod N=m^d=\sigma$ .

This is a valid signature for $m$ .

That’s very bad.

This means if we signed two messages $m_1,m_2$ , we can get a valid signature for $m_1\cdot m_2$ . If unfortunately $m_1\cdot m_2$ is the message we want to sign, the adversary can produce a fake signature for free.

Fix for forgeries

Pick a “random”-looking function $h:\mathcal{M}\to\mathbb{Z}_N^*$ . ( $h(\cdot)$ is collision-resistant)

$pk=(h,N,e)$ , $sk=(h,N,d)$

$Sign_{sk}(m)=h(m)^d\mod N$

$Verify_{pk}(m,\sigma)=1\iff \sigma^e=h(m)\mod N$

If $h$ is truly random, this would be secure.

$\sigma^e=m$ and $\sigma^e=h(m)\cancel{\to}m$

So $\sigma_1=h(m_1)^d$ and $\sigma_2=h(m_2)^d$ , If $m=m_1\cdot m_2$ , then $\sigma_1\cdot\sigma_2=h(m_1)^d\cdot h(m_2)^d\neq h(m)^d=\sigma$ . (the equality is very unlikely to happen)

This is secure.

Choices of $h$ :

$h$ is random function. Not practical since we need the verifier to know $h$ .
$h$ is pseudo-random function. Verifier needs to use $h$ , with full access to the random oracle. If we use $f_k$ for a random key $k$ , they need $k$ . No more pseudo-random security guarantee.
$h$ is a collision-resistant hash function. We can’t be sure it doesn’t have any patterns like $h(m_1\cdot m_2)=h(m_1)\cdot h(m_2)$ .

Here we present our silly solution:

Random oracle model:

Assume we have a true random function $h$ , the adversary only has oracle access to $h$ .

And $h$ is practical to use.

This RSA scheme under the random oracle model is secure. (LOL)

This requires a proof.

In practice, SHA-256 is used as $h$ . Fun, no one really finds a collision yet.