NoteNextra-origin/pages/CSE442T/CSE442T_L21.md

Lecture 21

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:

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

Disadvantages:

1. 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:

1. h is random function. Not practical since we need the verifier to know h.
2. 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.
3. 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.