Compare commits
21 Commits
b426538413
...
78691732a8
| Author | SHA1 | Date | |
|---|---|---|---|
|
78691732a8
|
|||
|
de3c6a1d4e
|
|||
|
b8d0068e6d
|
|||
|
746023e0b7
|
|||
|
c446506f4a
|
|||
| e1b1ec6fc5 | |||
| 7a6e58dac5 | |||
| 4f013805b5 | |||
| 6d574c1004 | |||
| a6ab9d49fd | |||
| 0d6dc88470 | |||
| f394e395b0 | |||
| b5e3a4a3b2 | |||
| 25f93569b0 | |||
| 6b769209bd | |||
| 307bb79179 | |||
| 187179afaf | |||
| eeba575c28 | |||
| 68fcbab46c | |||
| d55c927a9d | |||
| b606549af6 |
3
.github/workflows/pages-deploy.yml
vendored
@@ -54,7 +54,8 @@ jobs:
|
|||||||
run: |
|
run: |
|
||||||
bundle exec htmlproofer _site \
|
bundle exec htmlproofer _site \
|
||||||
\-\-disable-external \
|
\-\-disable-external \
|
||||||
\-\-ignore-urls "/^http:\/\/127.0.0.1/,/^http:\/\/0.0.0.0/,/^http:\/\/localhost/"
|
\-\-ignore-urls "/^http:\/\/127.0.0.1/,/^http:\/\/0.0.0.0/,/^http:\/\/localhost/" \
|
||||||
|
\-\-no-check-internal-hash
|
||||||
|
|
||||||
- name: Upload site artifact
|
- name: Upload site artifact
|
||||||
uses: actions/upload-pages-artifact@v3
|
uses: actions/upload-pages-artifact@v3
|
||||||
|
|||||||
@@ -2,17 +2,10 @@
|
|||||||
|
|
||||||
<!-- commons -->
|
<!-- commons -->
|
||||||
|
|
||||||
{% assign urls = site.data.origin[type].jquery.js
|
{% assign urls = site.data.origin[type].search.js %}
|
||||||
| append: ','
|
|
||||||
| append: site.data.origin[type].bootstrap.js
|
|
||||||
| append: ','
|
|
||||||
| append: site.data.origin[type].search.js
|
|
||||||
%}
|
|
||||||
|
|
||||||
<!-- layout specified -->
|
<!-- layout specified -->
|
||||||
|
|
||||||
{% assign js_dist = '/assets/js/dist/' %}
|
|
||||||
|
|
||||||
{% if page.layout == 'post' or page.layout == 'page' or page.layout == 'home' %}
|
{% if page.layout == 'post' or page.layout == 'page' or page.layout == 'home' %}
|
||||||
{% assign urls = urls | append: ',' | append: site.data.origin[type]['lazy-polyfill'].js %}
|
{% assign urls = urls | append: ',' | append: site.data.origin[type]['lazy-polyfill'].js %}
|
||||||
|
|
||||||
@@ -20,7 +13,7 @@
|
|||||||
<!-- image lazy-loading & popup & clipboard -->
|
<!-- image lazy-loading & popup & clipboard -->
|
||||||
{% assign urls = urls
|
{% assign urls = urls
|
||||||
| append: ','
|
| append: ','
|
||||||
| append: site.data.origin[type]['magnific-popup'].js
|
| append: site.data.origin[type].glightbox.js
|
||||||
| append: ','
|
| append: ','
|
||||||
| append: site.data.origin[type].clipboard.js
|
| append: site.data.origin[type].clipboard.js
|
||||||
%}
|
%}
|
||||||
@@ -33,7 +26,7 @@
|
|||||||
or page.layout == 'category'
|
or page.layout == 'category'
|
||||||
or page.layout == 'tag'
|
or page.layout == 'tag'
|
||||||
%}
|
%}
|
||||||
{% assign locale = site.lang | split: '-' | first %}
|
{% assign locale = include.lang | split: '-' | first %}
|
||||||
|
|
||||||
{% assign urls = urls
|
{% assign urls = urls
|
||||||
| append: ','
|
| append: ','
|
||||||
@@ -67,11 +60,13 @@
|
|||||||
{% assign js = 'commons' %}
|
{% assign js = 'commons' %}
|
||||||
{% endcase %}
|
{% endcase %}
|
||||||
|
|
||||||
{% capture script %}{{ js_dist }}{{ js }}.min.js{% endcapture %}
|
{% capture script %}/assets/js/dist/{{ js }}.min.js{% endcapture %}
|
||||||
<script defer src="{{ script | relative_url }}"></script>
|
|
||||||
|
<script src="{{ script | relative_url }}"></script>
|
||||||
|
|
||||||
{% if page.math %}
|
{% if page.math %}
|
||||||
<!-- MathJax -->
|
<!-- MathJax -->
|
||||||
|
<script src="{{ '/assets/js/data/mathjax.js' | relative_url }}"></script>
|
||||||
<script>
|
<script>
|
||||||
/* see: <https://docs.mathjax.org/en/latest/options/input/tex.html#tex-options> */
|
/* see: <https://docs.mathjax.org/en/latest/options/input/tex.html#tex-options> */
|
||||||
MathJax = {
|
MathJax = {
|
||||||
@@ -148,7 +143,7 @@
|
|||||||
}
|
}
|
||||||
};
|
};
|
||||||
</script>
|
</script>
|
||||||
<script src="https://polyfill.io/v3/polyfill.min.js?features=es6"></script>
|
<script src="https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js?features=es6"></script>
|
||||||
<script id="MathJax-script" async src="{{ site.data.origin[type].mathjax.js | relative_url }}"></script>
|
<script id="MathJax-script" async src="{{ site.data.origin[type].mathjax.js | relative_url }}"></script>
|
||||||
{% endif %}
|
{% endif %}
|
||||||
|
|
||||||
@@ -166,10 +161,17 @@
|
|||||||
{% endif %}
|
{% endif %}
|
||||||
{% endif %}
|
{% endif %}
|
||||||
|
|
||||||
|
{% if page.mermaid %}
|
||||||
|
{% include mermaid.html %}
|
||||||
|
{% endif %}
|
||||||
|
|
||||||
{% if jekyll.environment == 'production' %}
|
{% if jekyll.environment == 'production' %}
|
||||||
<!-- PWA -->
|
<!-- PWA -->
|
||||||
{% if site.pwa.enabled %}
|
{% if site.pwa.enabled %}
|
||||||
<script defer src="{{ 'app.min.js' | prepend: js_dist | relative_url }}"></script>
|
<script
|
||||||
|
defer
|
||||||
|
src="{{ 'app.min.js' | relative_url }}?baseurl={{ site.baseurl | default: '' }}®ister={{ site.pwa.cache.enabled }}"
|
||||||
|
></script>
|
||||||
{% endif %}
|
{% endif %}
|
||||||
|
|
||||||
<!-- Web Analytics -->
|
<!-- Web Analytics -->
|
||||||
|
|||||||
@@ -11,7 +11,7 @@ tail_includes:
|
|||||||
|
|
||||||
{% include lang.html %}
|
{% include lang.html %}
|
||||||
|
|
||||||
<article class="px-1">
|
<article class="px-1" data-toc="{{ enable_toc }}">
|
||||||
<header>
|
<header>
|
||||||
<h1 data-toc-skip>{{ page.title }}</h1>
|
<h1 data-toc-skip>{{ page.title }}</h1>
|
||||||
{% if page.description %}
|
{% if page.description %}
|
||||||
@@ -75,6 +75,45 @@ tail_includes:
|
|||||||
</div>
|
</div>
|
||||||
</header>
|
</header>
|
||||||
|
|
||||||
|
{% if enable_toc %}
|
||||||
|
<div
|
||||||
|
id="toc-bar"
|
||||||
|
class="d-flex align-items-center justify-content-between invisible"
|
||||||
|
>
|
||||||
|
<span class="label text-truncate">{{ page.title }}</span>
|
||||||
|
<button type="button" class="toc-trigger btn me-1">
|
||||||
|
<i class="fa-solid fa-list-ul fa-fw"></i>
|
||||||
|
</button>
|
||||||
|
</div>
|
||||||
|
|
||||||
|
<button
|
||||||
|
id="toc-solo-trigger"
|
||||||
|
type="button"
|
||||||
|
class="toc-trigger btn btn-outline-secondary btn-sm"
|
||||||
|
>
|
||||||
|
<span class="label ps-2 pe-1"
|
||||||
|
>{{- site.data.locales[lang].panel.toc -}}</span
|
||||||
|
>
|
||||||
|
<i class="fa-solid fa-angle-right fa-fw"></i>
|
||||||
|
</button>
|
||||||
|
|
||||||
|
<dialog id="toc-popup" class="p-0">
|
||||||
|
<div
|
||||||
|
class="header d-flex flex-row align-items-center justify-content-between"
|
||||||
|
>
|
||||||
|
<div class="label text-truncate py-2 ms-4">{{- page.title -}}</div>
|
||||||
|
<button
|
||||||
|
id="toc-popup-close"
|
||||||
|
type="button"
|
||||||
|
class="btn mx-1 my-1 opacity-75"
|
||||||
|
>
|
||||||
|
<i class="fas fa-close"></i>
|
||||||
|
</button>
|
||||||
|
</div>
|
||||||
|
<div id="toc-popup-content" class="px-4 py-3 pb-4"></div>
|
||||||
|
</dialog>
|
||||||
|
{% endif %}
|
||||||
|
|
||||||
<div class="content">{{ content }}</div>
|
<div class="content">{{ content }}</div>
|
||||||
|
|
||||||
<div class="post-tail-wrapper text-muted">
|
<div class="post-tail-wrapper text-muted">
|
||||||
|
|||||||
@@ -2,11 +2,16 @@
|
|||||||
share: true
|
share: true
|
||||||
toc: true
|
toc: true
|
||||||
math: true
|
math: true
|
||||||
categories: [Mathematics, Coq]
|
categories:
|
||||||
tags: [math, coq, proof-verification]
|
- Mathematics
|
||||||
title: "Rules of Inference with Coq"
|
- Coq
|
||||||
date: "2023-07-08"
|
tags:
|
||||||
github_title: "2023-07-08-rules-of-inference"
|
- math
|
||||||
|
- coq
|
||||||
|
- proof-verification
|
||||||
|
title: Rules of Inference with Coq
|
||||||
|
date: 2023-07-08
|
||||||
|
github_title: 2023-07-08-rules-of-inference
|
||||||
---
|
---
|
||||||
|
|
||||||
This is a list of proofs with Coq, for each rule of inference stated in [List of Rules of Inference (Wikipedia)](https://en.wikipedia.org/wiki/List_of_rules_of_inference)
|
This is a list of proofs with Coq, for each rule of inference stated in [List of Rules of Inference (Wikipedia)](https://en.wikipedia.org/wiki/List_of_rules_of_inference)
|
||||||
@@ -188,7 +193,7 @@ Lemma distributive_conjunction : forall P Q R : Prop,
|
|||||||
Proof.
|
Proof.
|
||||||
split; intros.
|
split; intros.
|
||||||
- destruct H as [H [H1 | H1]]; auto.
|
- destruct H as [H [H1 | H1]]; auto.
|
||||||
- destruct H as [ [H1 H2](H1%20H2.md); auto.
|
- destruct H as [[H1 H2] | [H1 H2]]; auto.
|
||||||
Qed.
|
Qed.
|
||||||
|
|
||||||
Lemma material_implication_converse : forall P Q : Prop,
|
Lemma material_implication_converse : forall P Q : Prop,
|
||||||
|
|||||||
@@ -1,94 +0,0 @@
|
|||||||
---
|
|
||||||
share: true
|
|
||||||
---
|
|
||||||
|
|
||||||
- [Link](https://www.cs.virginia.edu/~robins/YouAndYourResearch.html) to original text.
|
|
||||||
- **I recommend reading the full text. It may seem a bit long but I assure you that it is worth the time.**
|
|
||||||
- The talk is mainly about how to do **first-class work**, something **significant** as a great scientist.
|
|
||||||
|
|
||||||
The following is a list of quotes from the text that inspired me. Bold fonts were not in the original text, I added them on my own.
|
|
||||||
|
|
||||||
Read the full text for the full context!
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Luck
|
|
||||||
|
|
||||||
> And I will cite Pasteur who said, "Luck favors the prepared mind." \[...\]
|
|
||||||
> **There is indeed an element of luck, and no, there isn't.**
|
|
||||||
|
|
||||||
> I want to dispose of this matter of luck as being the sole criterion whether you do great work or not.
|
|
||||||
|
|
||||||
> Newton said, "If others would think as hard as I did, then they would get similar results."
|
|
||||||
|
|
||||||
> I'd say luck changes the odds, but there is some definite control on the part of the individual.
|
|
||||||
|
|
||||||
## Courage
|
|
||||||
|
|
||||||
> One of the characteristics you see, and many people have it including great scientists, is that usually **when they were young they had independent thoughts and had the courage to pursue them.**
|
|
||||||
|
|
||||||
> One of the characteristics of successful scientists is having **courage**. \[...\]
|
|
||||||
> They will go forward under incredible circumstances; **they think and continue to think.**
|
|
||||||
|
|
||||||
## Working Conditions
|
|
||||||
|
|
||||||
> What most people think are the best working conditions, are not. Very clearly they are not because **people are often most productive when working conditions are bad.**
|
|
||||||
|
|
||||||
## Drive
|
|
||||||
|
|
||||||
> "**Knowledge and productivity are like compound interest.**" \[...\] The more you know, the more you learn; the more you learn, the more you can do; the more you can do, the more the opportunity.
|
|
||||||
|
|
||||||
> Given two people with exactly the same ability, **the one person who manages day in and day out to get in one more hour of thinking will be tremendously more productive over a lifetime.**
|
|
||||||
|
|
||||||
> On this matter of **drive** Edison says, "Genius is 99% perspiration and 1% inspiration." He may have been exaggerating, but the idea is that **solid work, steadily applied, gets you surprisingly far**. The steady application of effort with a little bit more work, *intelligently applied* is what does it.
|
|
||||||
|
|
||||||
## Ambiguity
|
|
||||||
|
|
||||||
> Most people like to believe something is or is not true. Great scientists tolerate **ambiguity** very well. **They believe the theory enough to go ahead; they doubt it enough to notice the errors and faults so they can step forward and create the new replacement theory.** If you believe to much you'll never notice the flaws; if you doubt to much you won't get started. It requires a lovely balance.
|
|
||||||
|
|
||||||
> When you find apparent flaws you've got to be sensitive and keep track of those things, and keep an eye out for how they can be explained or how the theory can be changed to fit them.
|
|
||||||
|
|
||||||
## Commitment
|
|
||||||
|
|
||||||
> If you are deeply immersed and committed to a topic, day after day after day, **your subconscious has nothing to do but work on your problem.** \[...\] For those who don't get committed to their current problem, **the subconscious goofs off on other things and doesn't produce the big result**.
|
|
||||||
|
|
||||||
> Keep your subconscious starved so it has to work on *your* problem, so you can sleep peacefully and get the answer in the morning, free.
|
|
||||||
|
|
||||||
## Important Problem
|
|
||||||
|
|
||||||
> "What are the important problems of your field?"
|
|
||||||
> "What important problems are you working on?"
|
|
||||||
> "**If what you are doing is not important, and if you don't think it is going to lead to something important, why are you at Bell Labs working on it?**"[^1]
|
|
||||||
|
|
||||||
> If you do not work on an important problem, it's unlikely you'll do important work. It's perfectly obvious.
|
|
||||||
|
|
||||||
> We didn't work on (1) time travel, (2) teleportation, and (3) antigravity. They are not important problems because we do not have an attack. **It's not the consequence that makes a problem important, it is that you have a reasonable attack.**
|
|
||||||
|
|
||||||
> "**What will be the impact of computers on science and how can I change it?**"[^2]
|
|
||||||
|
|
||||||
> I thought hard about where was my field going, where were the opportunities, and what were the important things to do. Let me go there so there is a chance I can do important things.
|
|
||||||
|
|
||||||
> They (most great scientists) have something between 10 and 20 important problems for which they are looking for an attack. And when they see a new idea come up, one hears them say "Well that bears on this problem." They drop all the other things and get after it.
|
|
||||||
|
|
||||||
> They get rid of other things and they get after an idea because **they had already thought the thing through**. Their minds are prepared; they see the opportunity and they go after it.
|
|
||||||
|
|
||||||
## Working with an Open Door
|
|
||||||
|
|
||||||
> He who works with the door open gets all kinds of interruptions, but **he also occasionally gets clues as to what the world is and what might be important.**
|
|
||||||
|
|
||||||
## Others
|
|
||||||
|
|
||||||
> "Is the effort to be a great scientist worth it?" \[...\] I think it is very definitely worth the struggle to try and do first-class work because the truth is, **the value is in the struggle more than it is in the result**.
|
|
||||||
|
|
||||||
> But if you want to be a great scientist you're going to have to put up with stress.
|
|
||||||
|
|
||||||
> You know the idea called the '**critical mass**'. \[...\] What you want to do is get that critical mass in action; "Yes, that reminds me of so and so," or, "Have you thought about that or this?" When you talk to other people, you want to get rid of those **sound absorbers** who are nice people but merely say, "Oh yes," and **to find those who will stimulate you right back.**
|
|
||||||
|
|
||||||
> If you read all the time what other people have done you will think the way they thought. **If you want to think new thoughts that are different, then do what a lot of creative people do** - get the problem reasonably clear and then **refuse to look at any answers until you've thought the problem through** carefully how you would do it, how you could slightly change the problem to be the correct one.
|
|
||||||
|
|
||||||
> The reading is necessary to know what is going on and what is possible. But reading to get the solutions does not seem to be the way to do great research. \[...\] **You read; but it is not the amount, it is the way you read that counts.**
|
|
||||||
|
|
||||||
> I think it's very valuable to have first-class people around. \[...\] **I tried to go with people who had great ability so I could learn from them and who would expect great results out of me.**
|
|
||||||
|
|
||||||
[^1]: *if you don't think it is going to lead to something important, why are you at \[...\] working on it?"*
|
|
||||||
[^2]: *What will be the impact of \[...\] on \[...\] and how can I change it?*
|
|
||||||
@@ -5,6 +5,7 @@ math: false
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- network
|
- network
|
||||||
- security
|
- security
|
||||||
@@ -13,9 +14,9 @@ title: 01. Security Introduction
|
|||||||
date: 2023-09-10
|
date: 2023-09-10
|
||||||
github_title: 2023-09-10-security-intro
|
github_title: 2023-09-10-security-intro
|
||||||
image:
|
image:
|
||||||
path: /assets/img/posts/Lecture Notes/Internet Security/is-01-cryptosystem.png
|
path: /assets/img/posts/lecture-notes/internet-security/is-01-cryptosystem.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Internet Security
|
folder: assets/img/posts/lecture-notes/internet-security
|
||||||
---
|
---
|
||||||
|
|
||||||
> Every program has at least two purposes: the one for which it was written, and another for which it wasn't. - Alan J. Perlis
|
> Every program has at least two purposes: the one for which it was written, and another for which it wasn't. - Alan J. Perlis
|
||||||
@@ -155,7 +156,7 @@ There are many ways of achieving security.
|
|||||||
|
|
||||||
### Basics of a Cryptosystem
|
### Basics of a Cryptosystem
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- A **message** in *plaintext* is given to an **encryption algorithm**.
|
- A **message** in *plaintext* is given to an **encryption algorithm**.
|
||||||
- The encryption algorithm uses an **encryption key** to create a *ciphertext*.
|
- The encryption algorithm uses an **encryption key** to create a *ciphertext*.
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- security
|
- security
|
||||||
- lecture-note
|
- lecture-note
|
||||||
@@ -190,22 +191,22 @@ Let $m \in \left\lbrace 0, 1 \right\rbrace^n$ be the message to encrypt. Then ch
|
|||||||
- Encryption: $E(k, m) = k \oplus m$.
|
- Encryption: $E(k, m) = k \oplus m$.
|
||||||
- Decryption: $D(k, c) = k \oplus c$.
|
- Decryption: $D(k, c) = k \oplus c$.
|
||||||
|
|
||||||
This scheme is **provably secure**. See also [one-time pad (Modern Cryptography)](../Modern%20Cryptography/2023-09-07-otp-stream-cipher-prgs.md#one-time-pad-(otp)).
|
This scheme is **provably secure**. See also [one-time pad (Modern Cryptography)](../../modern-cryptography/2023-09-07-otp-stream-cipher-prgs/#one-time-pad-(otp)).
|
||||||
|
|
||||||
## Perfect Secrecy
|
## Perfect Secrecy
|
||||||
|
|
||||||
> **Definition.** Let $(E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. We assume that $\lvert \mathcal{K} \rvert = \lvert \mathcal{M} \rvert = \lvert \mathcal{C} \rvert$. The cipher is **perfectly secure** if for all $m \in \mathcal{M}$ and $c \in \mathcal{C}$,
|
> **Definition.** Let $(E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. We assume that $\lvert \mathcal{K} \rvert = \lvert \mathcal{M} \rvert = \lvert \mathcal{C} \rvert$. The cipher is **perfectly secure** if for all $m \in \mathcal{M}$ and $c \in \mathcal{C}$,
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \Pr[\mathcal{M} = m \mid \mathcal{C} = c] = \Pr[\mathcal{M} = m].
|
> \Pr[\mathcal{M} = m \mid \mathcal{C} = c] = \Pr[\mathcal{M} = m].
|
||||||
> $$
|
> $$
|
||||||
>
|
>
|
||||||
> Or equivalently, for all $m_0, m_1 \in \mathcal{M}$, $c \in \mathcal{C}$,
|
> Or equivalently, for all $m_0, m_1 \in \mathcal{M}$, $c \in \mathcal{C}$,
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \Pr[E(k, m _ 0) = c] = \Pr[E(k, m _ 1) = c]
|
> \Pr[E(k, m _ 0) = c] = \Pr[E(k, m _ 1) = c]
|
||||||
> $$
|
> $$
|
||||||
>
|
>
|
||||||
> where $k$ is chosen uniformly in $\mathcal{K}$.
|
> where $k$ is chosen uniformly in $\mathcal{K}$.
|
||||||
|
|
||||||
In other words, the adversary learns nothing from the ciphertext.
|
In other words, the adversary learns nothing from the ciphertext.
|
||||||
@@ -224,7 +225,7 @@ since for each $m$ and $c$, $k$ is determined uniquely.
|
|||||||
|
|
||||||
*Proof*. Assume not, then we can find some message $m_0 \in \mathcal{M}$ such that $m_0$ is not a decryption of some $c \in \mathcal{C}$. This is because the decryption algorithm $D$ is deterministic and $\lvert \mathcal{K} \rvert < \lvert \mathcal{M} \rvert$.
|
*Proof*. Assume not, then we can find some message $m_0 \in \mathcal{M}$ such that $m_0$ is not a decryption of some $c \in \mathcal{C}$. This is because the decryption algorithm $D$ is deterministic and $\lvert \mathcal{K} \rvert < \lvert \mathcal{M} \rvert$.
|
||||||
|
|
||||||
For the proof in detail, check [Shannon's Theorem (Modern Cryptography)](../Modern%20Cryptography/2023-09-07-otp-stream-cipher-prgs.md#shannon's-theorem).
|
For the proof in detail, check [Shannon's Theorem (Modern Cryptography)](../../modern-cryptography/2023-09-07-otp-stream-cipher-prgs/#shannon's-theorem).
|
||||||
|
|
||||||
### Two-Time Pad is Insecure
|
### Two-Time Pad is Insecure
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -13,9 +14,9 @@ title: 03. Symmetric Key Cryptography (2)
|
|||||||
date: 2023-09-18
|
date: 2023-09-18
|
||||||
github_title: 2023-09-18-symmetric-key-cryptography-2
|
github_title: 2023-09-18-symmetric-key-cryptography-2
|
||||||
image:
|
image:
|
||||||
path: /assets/img/posts/Lecture Notes/Internet Security/is-03-feistel-function.png
|
path: /assets/img/posts/lecture-notes/internet-security/is-03-feistel-function.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Internet Security
|
folder: assets/img/posts/lecture-notes/internet-security
|
||||||
---
|
---
|
||||||
|
|
||||||
## Block Cipher Overview
|
## Block Cipher Overview
|
||||||
@@ -63,7 +64,7 @@ $$
|
|||||||
|
|
||||||
#### The Feistel Function
|
#### The Feistel Function
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using a P-box. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a (straight) permutation at the end, resulting in $32$ bit data.
|
The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using a P-box. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a (straight) permutation at the end, resulting in $32$ bit data.
|
||||||
|
|
||||||
@@ -179,7 +180,7 @@ AES, DES use fixed block size for encryption. How do we encrypt longer messages?
|
|||||||
|
|
||||||
### Electronic Codebook Mode (ECB)
|
### Electronic Codebook Mode (ECB)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- Codebook is a mapping table.
|
- Codebook is a mapping table.
|
||||||
- For the $i$-th plaintext block, we use key $k$ to encrypt and obtain the $i$-th ciphertext block.
|
- For the $i$-th plaintext block, we use key $k$ to encrypt and obtain the $i$-th ciphertext block.
|
||||||
@@ -198,9 +199,9 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
|||||||
|
|
||||||
### Cipher Block Chaining Mode (CBC)
|
### Cipher Block Chaining Mode (CBC)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- Two identical messages produce to different ciphertexts.
|
- Two identical messages produce two different ciphertexts.
|
||||||
- This prevents chosen plaintext attacks
|
- This prevents chosen plaintext attacks
|
||||||
- Blocks are linked together in the encryption process
|
- Blocks are linked together in the encryption process
|
||||||
- **Each previous cipher block is chained with current block**
|
- **Each previous cipher block is chained with current block**
|
||||||
@@ -238,17 +239,18 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
|||||||
- **IV changes should be unpredictable**
|
- **IV changes should be unpredictable**
|
||||||
- On IV reuse, same message will generate the same ciphertext if key isn't changed
|
- On IV reuse, same message will generate the same ciphertext if key isn't changed
|
||||||
- If IV is predictable, CBC is vulnerable to chosen plaintext attacks.
|
- If IV is predictable, CBC is vulnerable to chosen plaintext attacks.
|
||||||
- Define Eve's new message $m' = \mathrm{IV} _ {\mathrm{E}} \oplus \mathrm{IV} _ {\mathrm{A}} \oplus g$, where
|
- Suppose Eve obtains $(\mathrm{IV}_1, E_k(\mathrm{IV}_1 \oplus m))$.
|
||||||
- $\mathrm{IV} _ \mathrm{A}$ and $\mathrm{IV} _ \mathrm{E}$ are Alice and Eve's IVs
|
- Define Eve's new message $m' = \mathrm{IV} _ {2} \oplus \mathrm{IV} _ {1} \oplus g$, where
|
||||||
|
- $\mathrm{IV} _ 2$ is the guess of the next IV, and
|
||||||
- $g$ is a guess of Alice's original message $m$.
|
- $g$ is a guess of Alice's original message $m$.
|
||||||
- Since Eve can encrypt any message, $m'$ can be encrypted.
|
- Eve requests an encryption of $m'$
|
||||||
- $c' = E _ k(\mathrm{IV} _ \mathrm{E} \oplus m') = E _ k(\mathrm{IV} _ \mathrm{A} \oplus g)$.
|
- $c' = E _ k(\mathrm{IV} _ 2 \oplus m') = E _ k(\mathrm{IV} _ \mathrm{1} \oplus g)$.
|
||||||
- Then Eve can compare $c'$ and the original $c = E _ k(\mathrm{IV} _ \mathrm{A} \oplus m)$ to recover $m$.
|
- Then Eve can compare $c'$ and the original $c = E _ k(\mathrm{IV} _ \mathrm{1} \oplus m)$ to recover $m$.
|
||||||
- Useful when there are not many cases for $m$ (or most of the message is already known).
|
- Useful when there are not many cases for $m$ (or most of the message is already known).
|
||||||
|
|
||||||
### Cipher Feedback Mode (CFB)
|
### Cipher Feedback Mode (CFB)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- The message is treated as a stream of bits; similar to stream cipher
|
- The message is treated as a stream of bits; similar to stream cipher
|
||||||
- **Result of the encryption is fed to the next stage.**
|
- **Result of the encryption is fed to the next stage.**
|
||||||
@@ -283,7 +285,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
|||||||
|
|
||||||
### Output Feedback Mode (OFB)
|
### Output Feedback Mode (OFB)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- Very similar to stream cipher.
|
- Very similar to stream cipher.
|
||||||
- Initialization vector is used as a seed to generate the key stream.
|
- Initialization vector is used as a seed to generate the key stream.
|
||||||
@@ -316,7 +318,7 @@ Since the same key is used for all blocks, once a mapping from plaintext to ciph
|
|||||||
|
|
||||||
### Counter Mode (CTR)
|
### Counter Mode (CTR)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- Without chaining, we use a counter (typically incremented by $1$).
|
- Without chaining, we use a counter (typically incremented by $1$).
|
||||||
- Counter starts from the initialization vector.
|
- Counter starts from the initialization vector.
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -20,7 +21,7 @@ github_title: 2023-09-25-modular-arithmetic-1
|
|||||||
## Divisibility
|
## Divisibility
|
||||||
|
|
||||||
> **Definition.** Let $a, b, c \in \mathbb{Z}$ such that $a = bc$. Then,
|
> **Definition.** Let $a, b, c \in \mathbb{Z}$ such that $a = bc$. Then,
|
||||||
>
|
>
|
||||||
> 1. $b$ and $c$ are said to **divide** $a$, and are called **factors** of $a$.
|
> 1. $b$ and $c$ are said to **divide** $a$, and are called **factors** of $a$.
|
||||||
> 2. $a$ is said to be a **multiple** of $b$ and $c$.
|
> 2. $a$ is said to be a **multiple** of $b$ and $c$.
|
||||||
|
|
||||||
@@ -29,7 +30,7 @@ github_title: 2023-09-25-modular-arithmetic-1
|
|||||||
These are simple lemmas for checking divisibility.
|
These are simple lemmas for checking divisibility.
|
||||||
|
|
||||||
> **Lemma.** Let $a, b, c \in \mathbb{Z}$.
|
> **Lemma.** Let $a, b, c \in \mathbb{Z}$.
|
||||||
>
|
>
|
||||||
> 1. If $a \mid b$ and $a \mid c$, then $a \mid (b + c)$.
|
> 1. If $a \mid b$ and $a \mid c$, then $a \mid (b + c)$.
|
||||||
> 2. If $a \mid b$, then $a \mid bc$.
|
> 2. If $a \mid b$, then $a \mid bc$.
|
||||||
> 3. If $a \mid b$ and $b \mid c$, then $a \mid c$.
|
> 3. If $a \mid b$ and $b \mid c$, then $a \mid c$.
|
||||||
@@ -88,7 +89,7 @@ As a congruence, it means that $a, b$ are in the same *equivalence class*.[^2]
|
|||||||
Properties of modulo operation.
|
Properties of modulo operation.
|
||||||
|
|
||||||
> **Lemma.** Suppose that $a \equiv b \pmod n$ and $c \equiv d \pmod n$. Then, the following hold.
|
> **Lemma.** Suppose that $a \equiv b \pmod n$ and $c \equiv d \pmod n$. Then, the following hold.
|
||||||
>
|
>
|
||||||
> 1. $a + c \equiv (b + d) \pmod n$.
|
> 1. $a + c \equiv (b + d) \pmod n$.
|
||||||
> 2. $ac \equiv bd \pmod n$.
|
> 2. $ac \equiv bd \pmod n$.
|
||||||
> 3. $a^k \equiv b^k \pmod n$.
|
> 3. $a^k \equiv b^k \pmod n$.
|
||||||
@@ -143,7 +144,7 @@ Note that $\mathbb{Z}_n$ is closed under addition and multiplication.
|
|||||||
### Identity
|
### Identity
|
||||||
|
|
||||||
> **Definition.** For a binary operation $\ast$ defined on a set $S$, $e$ is the **identity** if
|
> **Definition.** For a binary operation $\ast$ defined on a set $S$, $e$ is the **identity** if
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \forall a \in S,\, a * e = e * a = a.
|
> \forall a \in S,\, a * e = e * a = a.
|
||||||
> $$
|
> $$
|
||||||
@@ -153,11 +154,11 @@ In $\mathbb{Z}_n$, the additive identity is $0$, the multiplicative identity is
|
|||||||
### Inverse
|
### Inverse
|
||||||
|
|
||||||
> **Definition.** For a binary operation $\ast$ defined on a set $S$, let $e$ be the identity. $x$ is the **inverse of $a$** if
|
> **Definition.** For a binary operation $\ast$ defined on a set $S$, let $e$ be the identity. $x$ is the **inverse of $a$** if
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> x * a = a * x = e.
|
> x * a = a * x = e.
|
||||||
> $$
|
> $$
|
||||||
>
|
>
|
||||||
> We write $x = a^{-1}$.
|
> We write $x = a^{-1}$.
|
||||||
|
|
||||||
In the language of modular arithmetic, $x$ is the inverse of $a$ if
|
In the language of modular arithmetic, $x$ is the inverse of $a$ if
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -20,7 +21,7 @@ github_title: 2023-10-04-rsa-elgamal
|
|||||||
Suppose we are given integers $a$ and $N$. For any integer $x$ that is relatively prime to $N$, we choose $b$ so that
|
Suppose we are given integers $a$ and $N$. For any integer $x$ that is relatively prime to $N$, we choose $b$ so that
|
||||||
|
|
||||||
$$
|
$$
|
||||||
|
|
||||||
\tag{$*$}
|
\tag{$*$}
|
||||||
ab \equiv 1 \pmod{\phi(N)}.
|
ab \equiv 1 \pmod{\phi(N)}.
|
||||||
$$
|
$$
|
||||||
@@ -139,7 +140,7 @@ This is an inverse problem of exponentiation. The inverse of exponentials is log
|
|||||||
|
|
||||||
Given $y \equiv g^x \pmod p$ for some prime $p$, we want to find $x = \log_g y$. We set $g$ to be a generator of the group $\mathbb{Z}_p$ or $\mathbb{Z}_p^*$, since if $g$ is the generator, a solution always exists.
|
Given $y \equiv g^x \pmod p$ for some prime $p$, we want to find $x = \log_g y$. We set $g$ to be a generator of the group $\mathbb{Z}_p$ or $\mathbb{Z}_p^*$, since if $g$ is the generator, a solution always exists.
|
||||||
|
|
||||||
Read more in [discrete logarithm problem (Modern Cryptography)](../../modern-cryptography/2023-10-03-key-exchange#discrete-logarithm-problem-dl).
|
Read more in [discrete logarithm problem (Modern Cryptography)](../../modern-cryptography/2023-10-03-key-exchange/#discrete-logarithm-problem-(dl)).
|
||||||
|
|
||||||
## ElGamal Encryption
|
## ElGamal Encryption
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -31,7 +32,7 @@ These keys are created to be used in **trapdoor one-way functions**.
|
|||||||
|
|
||||||
A **one-way function** is a function that is easy to compute, but hard to compute the pre-image of any output. Here are some common examples.
|
A **one-way function** is a function that is easy to compute, but hard to compute the pre-image of any output. Here are some common examples.
|
||||||
|
|
||||||
- *Cryptographic hash functions*: [Hash Functions (Modern Cryptography)](../../modern-cryptography/2023-09-28-hash-functions#collision-resistance).
|
- *Cryptographic hash functions*: [Hash Functions (Modern Cryptography)](../../modern-cryptography/2023-09-28-hash-functions/#collision-resistance).
|
||||||
- *Factoring a large integer*: It is easy to multiply to integers even if they're large, but factoring is very hard.
|
- *Factoring a large integer*: It is easy to multiply to integers even if they're large, but factoring is very hard.
|
||||||
- *Discrete logarithm problem*: It is easy to exponentiate a number, but it is hard to find the discrete logarithm.
|
- *Discrete logarithm problem*: It is easy to exponentiate a number, but it is hard to find the discrete logarithm.
|
||||||
|
|
||||||
@@ -86,7 +87,7 @@ Choose a large prime $p$ and a generator $g$ of $\mathbb{Z}_p^{ * }$. The descri
|
|||||||
> 3. Alice and Bob calculate $g^{xy} \bmod p$ separately.
|
> 3. Alice and Bob calculate $g^{xy} \bmod p$ separately.
|
||||||
> 4. Eve can see $g^x \bmod p$, $g^y \bmod p$ but cannot calculate $g^{xy} \bmod p$.
|
> 4. Eve can see $g^x \bmod p$, $g^y \bmod p$ but cannot calculate $g^{xy} \bmod p$.
|
||||||
|
|
||||||
Refer to [Diffie-Hellman Key Exchange (Modern Cryptography)](../../modern-cryptography/2023-10-03-key-exchange#diffie-hellman-key-exchange-dhke).
|
Refer to [Diffie-Hellman Key Exchange (Modern Cryptography)](../../modern-cryptography/2023-10-03-key-exchange/#diffie-hellman-key-exchange-(dhke)).
|
||||||
|
|
||||||
## Message Integrity
|
## Message Integrity
|
||||||
|
|
||||||
@@ -132,7 +133,7 @@ Suppose Alice wants to **sign** a message $m$. Alice has public key $pk$ and pri
|
|||||||
> 2. Bob receives it and calculates $E(pk, \sigma)$ and compares it with $m$.
|
> 2. Bob receives it and calculates $E(pk, \sigma)$ and compares it with $m$.
|
||||||
> - The key $pk$ here is Alice's public key.
|
> - The key $pk$ here is Alice's public key.
|
||||||
|
|
||||||
- Since the signature can be decrypted using Alice's public key, it must have been signed using Alice's private key.
|
- Since the signature can be verified using Alice's public key, it must have been signed using Alice's private key.
|
||||||
- Thus the message must have been from Alice.
|
- Thus the message must have been from Alice.
|
||||||
- Verification is done using Alice's public key, so anyone can verify the message.
|
- Verification is done using Alice's public key, so anyone can verify the message.
|
||||||
- Messages are usually long, so we take a hash function $H$ to shorten it, and sign $H(m)$ instead.
|
- Messages are usually long, so we take a hash function $H$ to shorten it, and sign $H(m)$ instead.
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -12,7 +13,7 @@ title: 08. Public Key Infrastructure
|
|||||||
date: 2023-10-16
|
date: 2023-10-16
|
||||||
github_title: 2023-10-16-pki
|
github_title: 2023-10-16-pki
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Internet Security
|
folder: assets/img/posts/lecture-notes/internet-security
|
||||||
---
|
---
|
||||||
|
|
||||||
Suppose that we're using RSA, Alice has public key $(N, e)$ and private key $d$. Anyone can send messages to Alice using $(N, e)$. But because anyone can generate $(N, e)$, we are not sure whether the key $(N, e)$ is *really* Alice's key. We might run into a situation where $(N, e)$ was actually some other person's key. *How do we check whose key this is?*
|
Suppose that we're using RSA, Alice has public key $(N, e)$ and private key $d$. Anyone can send messages to Alice using $(N, e)$. But because anyone can generate $(N, e)$, we are not sure whether the key $(N, e)$ is *really* Alice's key. We might run into a situation where $(N, e)$ was actually some other person's key. *How do we check whose key this is?*
|
||||||
@@ -83,7 +84,7 @@ We have a root CA at the top. Then there are issuing CAs below. We usually reque
|
|||||||
|
|
||||||
### Certificate Validation
|
### Certificate Validation
|
||||||
|
|
||||||
[^1]
|
[^1]
|
||||||
|
|
||||||
Since we have a hierarchy of CAs, certificate validation must also follow the hierarchy. When we receive a certificate, it is highly likely to be signed by an non-root CA.
|
Since we have a hierarchy of CAs, certificate validation must also follow the hierarchy. When we receive a certificate, it is highly likely to be signed by an non-root CA.
|
||||||
|
|
||||||
@@ -149,13 +150,13 @@ CRL checking is done in the following way.
|
|||||||
> 2. The client queries the certificate revocation server and downloads CRLs.
|
> 2. The client queries the certificate revocation server and downloads CRLs.
|
||||||
> 3. The client checks whether the certificate is revoked or not.
|
> 3. The client checks whether the certificate is revoked or not.
|
||||||
|
|
||||||
But Distributing CRL in real-time is not possible. Furthermore, CRL lifecycles/update periods can vary depending on CAs. Thus there can be attacks between CRL updates. Also, CRL sizes will keep increasing over time, so it gets harder to download and manage the CRLs.
|
But distributing CRL in real-time is not possible. Furthermore, CRL lifecycles/update periods can vary depending on CAs. Thus there can be attacks between CRL updates. Also, CRL sizes will keep increasing over time, so it gets harder to download and manage the CRLs.
|
||||||
|
|
||||||
### Online Certificate Status Protocol (OCSP)
|
### Online Certificate Status Protocol (OCSP)
|
||||||
|
|
||||||
The **online certificate status protocol** (OCSP) is another way to handle certificate revocation. Basically, the client queries a OCSP server for revocation information.
|
The **online certificate status protocol** (OCSP) is another way to handle certificate revocation. Basically, the client queries a OCSP server for revocation information.
|
||||||
|
|
||||||
There is a **OCSP server** that runs 24/7, responding to queries. This server can be run by the CAs or may be delegated to some other entities. The address of the OCSP server is specified in the certificate.
|
There is an **OCSP server** that runs 24/7, responding to queries. This server can be run by the CAs or may be delegated to some other entities. The address of the OCSP server is specified in the certificate.
|
||||||
|
|
||||||
Using OCSP, revocation check is done in the following way.
|
Using OCSP, revocation check is done in the following way.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Internet Security
|
- Internet Security
|
||||||
|
path: _posts/lecture-notes/internet-security
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -12,9 +13,9 @@ title: 09. Transport Layer Security
|
|||||||
date: 2023-10-18
|
date: 2023-10-18
|
||||||
github_title: 2023-10-18-tls
|
github_title: 2023-10-18-tls
|
||||||
image:
|
image:
|
||||||
path: /assets/img/posts/Lecture Notes/Internet Security/is-09-tls-handshake.png
|
path: /assets/img/posts/lecture-notes/internet-security/is-09-tls-handshake.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Internet Security
|
folder: assets/img/posts/lecture-notes/internet-security
|
||||||
---
|
---
|
||||||
|
|
||||||
This is a brief comparison of HTTP and HTTPS
|
This is a brief comparison of HTTP and HTTPS
|
||||||
@@ -61,19 +62,19 @@ You can check if TLS is used on your browser. The address should begin with `htt
|
|||||||
|
|
||||||
## CBC Padding Oracle Attack
|
## CBC Padding Oracle Attack
|
||||||
|
|
||||||
Recall [CBC Mode (Internet Security)](../2023-09-18-symmetric-key-cryptography-2#cipher-block-chaining-mode-cbc) .
|
Recall [CBC Mode (Internet Security)](../2023-09-18-symmetric-key-cryptography-2/#cipher-block-chaining-mode-(cbc)) .
|
||||||
|
|
||||||
Suppose that each block has $8$ bytes. If the message size is not a multiple of the block size, we pad the message. If we need to pad $b$ bytes, we pad $b$ bytes with $b$, encoded in binary.
|
Suppose that each block has $8$ bytes. If the message size is not a multiple of the block size, we pad the message. If we need to pad $b$ bytes, we pad $b$ bytes with $b$, encoded in binary.
|
||||||
|
|
||||||
If the padding is not valid, the decryption algorithm outputs a *padding error* during the decryption process. The attacker can observe if a padding error has occurred, and use this information to recover the plaintext.
|
If the padding is not valid, the decryption algorithm outputs a *padding error* during the decryption process. The attacker can observe if a padding error has occurred, and use this information to recover the plaintext.
|
||||||
|
|
||||||
To defend this attack, we can use [encrypt-then-MAC (Modern Cryptography)](../../modern-cryptography/2023-09-26-cca-security-authenticated-encryption#encrypt-then-mac-etm), or hide the padding error.
|
To defend this attack, we can use [encrypt-then-MAC (Modern Cryptography)](../../modern-cryptography/2023-09-26-cca-security-authenticated-encryption/#encrypt-then-mac-(etm)), or hide the padding error.
|
||||||
|
|
||||||
### Attack in Detail
|
### Attack in Detail
|
||||||
|
|
||||||
We will perform a **chosen ciphertext attack** to fully recover the plaintext.
|
We will perform a **chosen ciphertext attack** to fully recover the plaintext.
|
||||||
|
|
||||||
Suppose that we obtains a ciphertext $(\mathrm{IV}, c_1, c_2)$, which is an encryption of two blocks $m = m_0 \parallel m_1$, including the padding. By the CBC encryption algorithm we know that
|
Suppose that we obtain a ciphertext $(\mathrm{IV}, c_1, c_2)$, which is an encryption of two blocks $m = m_0 \parallel m_1$, including the padding. By the CBC encryption algorithm we know that
|
||||||
|
|
||||||
$$
|
$$
|
||||||
c_1 = E_k(m_0 \oplus \mathrm{IV}), \qquad c_2 = E_k(m_1 \oplus c_1).
|
c_1 = E_k(m_0 \oplus \mathrm{IV}), \qquad c_2 = E_k(m_1 \oplus c_1).
|
||||||
@@ -81,7 +82,7 @@ $$
|
|||||||
|
|
||||||
We don't know exactly how many padding bits there were, but it doesn't matter. We brute force by **changing the last byte of $c_1$** and requesting the decryption of the modified ciphertext $(\mathrm{IV}, c_1', c_2)$.
|
We don't know exactly how many padding bits there were, but it doesn't matter. We brute force by **changing the last byte of $c_1$** and requesting the decryption of the modified ciphertext $(\mathrm{IV}, c_1', c_2)$.
|
||||||
|
|
||||||
The decryption process of the last block is $c_1 \oplus D_k(c_2)$, so by changing the last byte of $c_1$, we hope to get a decryption result that ends with $\texttt{0x01}$. Then the last byte $\texttt{0x01}$ will be treated as a padding and padding errors will not occur. So we keep trying until we don't get a padding error.
|
The decryption process of the last block is $c_1 \oplus D_k(c_2)$, so by changing the last byte of $c_1$, we hope to get a decryption result that ends with $\texttt{0x01}$. Then the last byte $\texttt{0x01}$ will be treated as a padding and padding errors will not occur. So we keep trying until we don't get a padding error.[^1]
|
||||||
|
|
||||||
Now, suppose that we successfully changed the last byte of $c_1$ to $b$, so that the last byte of $(c_1[0\dots6] \parallel b) \oplus D_k(c_2)$ is $\texttt{0x01}$. Next, we change the second-last bit $c_1[6]$ and request the decryption and hope to get an output that ends with $\texttt{0x0202}$. The last two bytes will also be treated as a padding and we won't get a padding error.
|
Now, suppose that we successfully changed the last byte of $c_1$ to $b$, so that the last byte of $(c_1[0\dots6] \parallel b) \oplus D_k(c_2)$ is $\texttt{0x01}$. Next, we change the second-last bit $c_1[6]$ and request the decryption and hope to get an output that ends with $\texttt{0x0202}$. The last two bytes will also be treated as a padding and we won't get a padding error.
|
||||||
|
|
||||||
@@ -113,7 +114,7 @@ $$
|
|||||||
|
|
||||||
## Hashed MAC (HMAC)
|
## Hashed MAC (HMAC)
|
||||||
|
|
||||||
Let $H$ be a has function. We defined MAC as $H(k \parallel m)$ where $k$ is a key and $m$ is a message. This MAC is insecure if $H$ has [Merkle-Damgård construction](../../modern-cryptography/2023-09-28-hash-functions#merkle-damg%C3%A5rd-transform), since it is vulnerable to length extension attacks. See [prepending the key in MAC is insecure (Modern Cryptography)](../../modern-cryptography/2023-09-28-hash-functions#prepending-the-key).
|
Let $H$ be a has function. We defined MAC as $H(k \parallel m)$ where $k$ is a key and $m$ is a message. This MAC is insecure if $H$ has [Merkle-Damgård construction](../../modern-cryptography/2023-09-28-hash-functions/#merkle-damgård-transform), since it is vulnerable to length extension attacks. See [prepending the key in MAC is insecure (Modern Cryptography)](../../modern-cryptography/2023-09-28-hash-functions/#prepending-the-key).
|
||||||
|
|
||||||
Choose a key $k \leftarrow \mathcal{K}$, and set
|
Choose a key $k \leftarrow \mathcal{K}$, and set
|
||||||
|
|
||||||
@@ -146,7 +147,7 @@ Here's how the client and the server establishes a connection using the TLS hand
|
|||||||
> 3. Use the server's public key to share a secret.
|
> 3. Use the server's public key to share a secret.
|
||||||
> 4. Both parties generate a symmetric key from the shared secret.
|
> 4. Both parties generate a symmetric key from the shared secret.
|
||||||
|
|
||||||
[^1]
|
[^2]
|
||||||
|
|
||||||
- `ServerKeyExchange`, `ClientKeyExchange` is optional. Used sometimes if Diffie-Hellman is used.
|
- `ServerKeyExchange`, `ClientKeyExchange` is optional. Used sometimes if Diffie-Hellman is used.
|
||||||
- The actual messages and process differ for each protocol and ciphers used.
|
- The actual messages and process differ for each protocol and ciphers used.
|
||||||
@@ -209,7 +210,7 @@ key_block = PRF(SecurityParameters.master_secret,
|
|||||||
```
|
```
|
||||||
|
|
||||||
- Why do we use `pre_master_secret` and `master_secret`?
|
- Why do we use `pre_master_secret` and `master_secret`?
|
||||||
- To provide greater consistency between TLS cipher suites.[^2]
|
- To provide greater consistency between TLS cipher suites.[^3]
|
||||||
|
|
||||||
## Version Rollback Attack (SSL)
|
## Version Rollback Attack (SSL)
|
||||||
|
|
||||||
@@ -252,9 +253,9 @@ These two protocols run over the record protocol.
|
|||||||
|
|
||||||
### Forward Secrecy
|
### Forward Secrecy
|
||||||
|
|
||||||
> **Forward secrecy** is a feature of key agreement protocols that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised.[^3]
|
> **Forward secrecy** is a feature of key agreement protocols that session keys will not be compromised even if long-term secrets used in the session key exchange are compromised.[^4]
|
||||||
|
|
||||||
> An encryption system has the property of **forward secrecy** if plaintext (decrypted) inspection of the data exchange that occurs during key agreement phase of session initiation does not reveal the key that was used to encrypt the remainder of the session.[^3]
|
> An encryption system has the property of **forward secrecy** if plaintext (decrypted) inspection of the data exchange that occurs during key agreement phase of session initiation does not reveal the key that was used to encrypt the remainder of the session.[^4]
|
||||||
|
|
||||||
- Forward secrecy prevents an **NSA-style attack**.
|
- Forward secrecy prevents an **NSA-style attack**.
|
||||||
- Save all TLS traffic starting from TLS handshake.
|
- Save all TLS traffic starting from TLS handshake.
|
||||||
@@ -282,7 +283,7 @@ Actual secret sharing is done using Diffie-Hellman key exchange, and RSA is used
|
|||||||
- Certificate is signed using RSA.
|
- Certificate is signed using RSA.
|
||||||
- The client sends $g^c \bmod p$.
|
- The client sends $g^c \bmod p$.
|
||||||
- The server and client agree on a secret $g^{sc} \bmod p$.
|
- The server and client agree on a secret $g^{sc} \bmod p$.
|
||||||
- The ephemeral keys $s$ and $g^{sc} \bmod p$ is discarded after the session.
|
- The ephemeral keys $s$ and $g^{sc} \bmod p$ are discarded after the session.
|
||||||
|
|
||||||
## TLS 1.3
|
## TLS 1.3
|
||||||
|
|
||||||
@@ -297,12 +298,13 @@ We previously had 2 round trips, but now we have one. The main difference is the
|
|||||||
|
|
||||||
- **Client hello**
|
- **Client hello**
|
||||||
- Protocol version, client random, cipher suites are sent.
|
- Protocol version, client random, cipher suites are sent.
|
||||||
- **Parameters for calculating the premaster secret is also sent.**[^4]
|
- **Parameters for calculating the premaster secret are also sent.**[^5]
|
||||||
- **Server generates master secret**
|
- **Server generates master secret**
|
||||||
- Server has client random, parameters and cipher suites.
|
- Server has client random, parameters and cipher suites.
|
||||||
- Using the server random, generate the master secret.
|
- Using the server random, generate the master secret.
|
||||||
- **Server hello** and **Finished**
|
- **Server hello** and **Finished**
|
||||||
- Server's certificate, digital signature, server random, chosen cipher suite is sent.
|
- Server's certificate, digital signature, server random, chosen cipher suite is sent.
|
||||||
|
- This message is encrypted, so server random is not leaked.
|
||||||
- Master secret has been generated, so `Finished` is sent.
|
- Master secret has been generated, so `Finished` is sent.
|
||||||
- **Client Finished**
|
- **Client Finished**
|
||||||
- Client verifies the certificate, generates master secret, sends `Finished`.
|
- Client verifies the certificate, generates master secret, sends `Finished`.
|
||||||
@@ -312,7 +314,7 @@ We previously had 2 round trips, but now we have one. The main difference is the
|
|||||||
TLS 1.3 also supports an event faster handshake that doesn't require and round trips.
|
TLS 1.3 also supports an event faster handshake that doesn't require and round trips.
|
||||||
|
|
||||||
- Works only if the user has visited the website before.
|
- Works only if the user has visited the website before.
|
||||||
- The both parties can derive another shared secret from the first session.
|
- Both parties can derive another shared secret from the first session.
|
||||||
- **Resumption main secret**, **pre-shared key** (PSK)
|
- **Resumption main secret**, **pre-shared key** (PSK)
|
||||||
- The server sends a **session ticket** during the first session.
|
- The server sends a **session ticket** during the first session.
|
||||||
- The client sends this ticket along with the first encrypted message of the new session.
|
- The client sends this ticket along with the first encrypted message of the new session.
|
||||||
@@ -327,7 +329,8 @@ TLS 1.3 also supports an event faster handshake that doesn't require and round t
|
|||||||
|
|
||||||
Read more in [Introducing 0-RTT (Cloudflare Blog)](https://blog.cloudflare.com/introducing-0-rtt/).
|
Read more in [Introducing 0-RTT (Cloudflare Blog)](https://blog.cloudflare.com/introducing-0-rtt/).
|
||||||
|
|
||||||
[^1]: Source: [The SSL Store](https://www.thesslstore.com/blog/explaining-ssl-handshake/).
|
[^1]: We have to brute force this, since if a padding error occurs, we don't get to see the decrypted data. If we don't get a padding error, we will likely get a MAC error, so we still don't get to see the decrypted data. All we do is exploit the fact that a padding error didn't occur.
|
||||||
[^2]: Source: [Cryptography SE](https://crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls).
|
[^2]: Source: [The SSL Store](https://www.thesslstore.com/blog/explaining-ssl-handshake/).
|
||||||
[^3]: Source: [Forward secrecy (Wikipedia)](https://en.wikipedia.org/wiki/Forward_secrecy).
|
[^3]: Source: [Cryptography SE](https://crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls).
|
||||||
[^4]: The client is assuming that it knows the server's preferred key exchange method, since many insecure cipher suites have been removed. Now, the number of possible cipher suites has been reduced.
|
[^4]: Source: [Forward secrecy (Wikipedia)](https://en.wikipedia.org/wiki/Forward_secrecy).
|
||||||
|
[^5]: The client is assuming that it knows the server's preferred key exchange method, since many insecure cipher suites have been removed. Now, the number of possible cipher suites has been reduced.
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- security
|
- security
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,9 +14,9 @@ title: 1. One-Time Pad, Stream Ciphers and PRGs
|
|||||||
date: 2023-09-07
|
date: 2023-09-07
|
||||||
github_title: 2023-09-07-otp-stream-cipher-prgs
|
github_title: 2023-09-07-otp-stream-cipher-prgs
|
||||||
image:
|
image:
|
||||||
path: "assets/img/posts/Lecture Notes/Modern Cryptography/mc-01-ss.png"
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-01-ss.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
## Assumptions and Notations
|
## Assumptions and Notations
|
||||||
@@ -44,11 +45,11 @@ Some random variables:
|
|||||||
For a scheme to be perfectly secret, the *ciphertext should not reveal any information about the underlying plaintext*, so that the adversary learns absolutely nothing about the plaintext.
|
For a scheme to be perfectly secret, the *ciphertext should not reveal any information about the underlying plaintext*, so that the adversary learns absolutely nothing about the plaintext.
|
||||||
|
|
||||||
> **Definition**. An encryption scheme is **perfectly secret** if for any distribution of $M$ and any ciphertext $c \in \mathcal{C}$ such that $\Pr[C = c] > 0$,
|
> **Definition**. An encryption scheme is **perfectly secret** if for any distribution of $M$ and any ciphertext $c \in \mathcal{C}$ such that $\Pr[C = c] > 0$,
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \Pr[M = m \mid C = c] = \Pr[M = m]
|
> \Pr[M = m \mid C = c] = \Pr[M = m]
|
||||||
> $$
|
> $$
|
||||||
>
|
>
|
||||||
> for every $m \in \mathcal{M}$.
|
> for every $m \in \mathcal{M}$.
|
||||||
|
|
||||||
For example, the shift cipher with $\mathcal{M}$ as the set of all two-letter characters is not perfectly secure. Suppose that $c = \texttt{XX}$ is observed. Then the adversary learns that the plaintext must consist of the same letter, revealing some information.
|
For example, the shift cipher with $\mathcal{M}$ as the set of all two-letter characters is not perfectly secure. Suppose that $c = \texttt{XX}$ is observed. Then the adversary learns that the plaintext must consist of the same letter, revealing some information.
|
||||||
@@ -56,11 +57,11 @@ For example, the shift cipher with $\mathcal{M}$ as the set of all two-letter ch
|
|||||||
The above definition is equivalent to the following.
|
The above definition is equivalent to the following.
|
||||||
|
|
||||||
> **Definition**. An encryption scheme is **perfectly secret** if for any $m_1, m_2 \in \mathcal{M}$ and $c \in \mathcal{C}$, we have
|
> **Definition**. An encryption scheme is **perfectly secret** if for any $m_1, m_2 \in \mathcal{M}$ and $c \in \mathcal{C}$, we have
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \Pr[E(k, m_1) = c] = \Pr[E(k, m_2) = c]
|
> \Pr[E(k, m_1) = c] = \Pr[E(k, m_2) = c]
|
||||||
> $$
|
> $$
|
||||||
>
|
>
|
||||||
> where the probability is taken over the random choice $k \leftarrow \mathcal{K}$.
|
> where the probability is taken over the random choice $k \leftarrow \mathcal{K}$.
|
||||||
|
|
||||||
> **Proposition**. The above two definitions are equivalent.
|
> **Proposition**. The above two definitions are equivalent.
|
||||||
@@ -220,7 +221,7 @@ A negligible function is a function that tends to $0$ as $n \rightarrow \infty$,
|
|||||||
The following is evident from the definition.
|
The following is evident from the definition.
|
||||||
|
|
||||||
> **Lemma.** A function $f : \mathbb{N} \rightarrow \mathbb{R}$ is negligible if and only if for all $c > 0$,
|
> **Lemma.** A function $f : \mathbb{N} \rightarrow \mathbb{R}$ is negligible if and only if for all $c > 0$,
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \lim_{n \rightarrow \infty} f(n) n^c = 0.
|
> \lim_{n \rightarrow \infty} f(n) n^c = 0.
|
||||||
> $$
|
> $$
|
||||||
@@ -232,11 +233,11 @@ In practice, about $2^{-30}$ is non-negligible since it is likely to happen over
|
|||||||
The adversary will want to distinguish if some bit string is an output of a PRG or truly random. So PRGs must satisfy the notion of **unpredictability**, which says that no *efficient* algorithm can predict the next bit of PRGs.
|
The adversary will want to distinguish if some bit string is an output of a PRG or truly random. So PRGs must satisfy the notion of **unpredictability**, which says that no *efficient* algorithm can predict the next bit of PRGs.
|
||||||
|
|
||||||
> **Definition.** A PRG is **predictable** if there exists an efficient adversary $\mathcal{A}$ and $i < n$ such that
|
> **Definition.** A PRG is **predictable** if there exists an efficient adversary $\mathcal{A}$ and $i < n$ such that
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \Pr[\mathcal{A}(G(k)[0..i-1]) = G(k)[i]] > \frac{1}{2} + \epsilon
|
> \Pr[\mathcal{A}(G(k)[0..i-1]) = G(k)[i]] > \frac{1}{2} + \epsilon
|
||||||
> $$
|
> $$
|
||||||
>
|
>
|
||||||
> for non-negligible $\epsilon > 0$.
|
> for non-negligible $\epsilon > 0$.
|
||||||
|
|
||||||
The probability here is taken over $k \leftarrow \lbrace 0, 1 \rbrace^s$, and $G(k)[0..i-1]$ denotes the first $i$ bits of $G(k)$. Also, the probability has to be non-negligible compared to $\frac{1}{2}$, implying that the adversary should be better than random guessing.
|
The probability here is taken over $k \leftarrow \lbrace 0, 1 \rbrace^s$, and $G(k)[0..i-1]$ denotes the first $i$ bits of $G(k)$. Also, the probability has to be non-negligible compared to $\frac{1}{2}$, implying that the adversary should be better than random guessing.
|
||||||
@@ -266,7 +267,7 @@ would be a statistical test.
|
|||||||
Let $G : \lbrace 0, 1 \rbrace^s \rightarrow \lbrace 0, 1 \rbrace^n$ be a PRG and $\mathcal{A}$ be a statistical test on $\lbrace 0, 1 \rbrace^n$.
|
Let $G : \lbrace 0, 1 \rbrace^s \rightarrow \lbrace 0, 1 \rbrace^n$ be a PRG and $\mathcal{A}$ be a statistical test on $\lbrace 0, 1 \rbrace^n$.
|
||||||
|
|
||||||
> **Definition.** The **PRG advantage** is defined as
|
> **Definition.** The **PRG advantage** is defined as
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \mathrm{Adv}_\mathrm{PRG}[\mathcal{A} , G] = \left\lvert \Pr_{k \leftarrow \left\lbrace 0, 1 \right\rbrace^s}[\mathcal{A}(G(k)) = 1] - \Pr_{r \leftarrow \left\lbrace 0, 1 \right\rbrace^n}[\mathcal{A}(r) = 1] \right\rvert.
|
> \mathrm{Adv}_\mathrm{PRG}[\mathcal{A} , G] = \left\lvert \Pr_{k \leftarrow \left\lbrace 0, 1 \right\rbrace^s}[\mathcal{A}(G(k)) = 1] - \Pr_{r \leftarrow \left\lbrace 0, 1 \right\rbrace^n}[\mathcal{A}(r) = 1] \right\rvert.
|
||||||
> $$
|
> $$
|
||||||
@@ -292,7 +293,7 @@ We can deduce that if a PRG is predictable, then it is insecure.
|
|||||||
|
|
||||||
*Proof*. Let $\mathcal{A}$ be an efficient adversary (next bit predictor) that predicts $G$. Suppose that $i$ is the index chosen by $\mathcal{A}$. With $\mathcal{A}$, we construct a statistical test $\mathcal{B}$ such that $\mathrm{Adv}_\mathrm{PRG}[\mathcal{B}, G]$ is non-negligible.
|
*Proof*. Let $\mathcal{A}$ be an efficient adversary (next bit predictor) that predicts $G$. Suppose that $i$ is the index chosen by $\mathcal{A}$. With $\mathcal{A}$, we construct a statistical test $\mathcal{B}$ such that $\mathrm{Adv}_\mathrm{PRG}[\mathcal{B}, G]$ is non-negligible.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
1. The challenger PRG will send a bit string $x$ to $\mathcal{B}$.
|
1. The challenger PRG will send a bit string $x$ to $\mathcal{B}$.
|
||||||
- In experiment $0$, PRG gives pseudorandom string $G(k)$.
|
- In experiment $0$, PRG gives pseudorandom string $G(k)$.
|
||||||
@@ -318,17 +319,17 @@ The theorem implies that if next bit predictors cannot distinguish $G$ from true
|
|||||||
|
|
||||||
To motivate the definition of semantic security, we consider a **security game framework** (attack game) between a **challenger** (ex. the creator of some cryptographic scheme) and an **adversary** $\mathcal{A}$ (ex. attacker of the scheme).
|
To motivate the definition of semantic security, we consider a **security game framework** (attack game) between a **challenger** (ex. the creator of some cryptographic scheme) and an **adversary** $\mathcal{A}$ (ex. attacker of the scheme).
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $\mathcal{E} = (G, E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. For a given adversary $\mathcal{A}$, we define two experiments $0$ and $1$. For $b \in \lbrace 0, 1 \rbrace$, define experiment $b$ as follows:
|
> **Definition.** Let $\mathcal{E} = (G, E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. For a given adversary $\mathcal{A}$, we define two experiments $0$ and $1$. For $b \in \lbrace 0, 1 \rbrace$, define experiment $b$ as follows:
|
||||||
>
|
>
|
||||||
> **Experiment** $b$.
|
> **Experiment** $b$.
|
||||||
> 1. The adversary computes $m_0, m_1 \in \mathcal{M}$ and sends them to the challenger.
|
> 1. The adversary computes $m_0, m_1 \in \mathcal{M}$ and sends them to the challenger.
|
||||||
> 2. The challenger computes $k \leftarrow \mathcal{K}$, $c \leftarrow E(k, m_b)$ and sends $c$ to the adversary.
|
> 2. The challenger computes $k \leftarrow \mathcal{K}$, $c \leftarrow E(k, m_b)$ and sends $c$ to the adversary.
|
||||||
> 3. The adversary outputs a bit $b' \in \lbrace 0, 1 \rbrace$.
|
> 3. The adversary outputs a bit $b' \in \lbrace 0, 1 \rbrace$.
|
||||||
>
|
>
|
||||||
> Let $W_b$ be the event that $\mathcal{A}$ outputs $1$ in experiment $b$. i.e, the event that $\mathcal{A}(\mathrm{EXP}(b)) = 1$. Now define the **semantic security advantage** of $\mathcal{A}$ with respect to $\mathcal{E}$ as
|
> Let $W_b$ be the event that $\mathcal{A}$ outputs $1$ in experiment $b$. i.e, the event that $\mathcal{A}(\mathrm{EXP}(b)) = 1$. Now define the **semantic security advantage** of $\mathcal{A}$ with respect to $\mathcal{E}$ as
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \mathrm{Adv}_\mathrm{SS}[\mathcal{A}, \mathcal{E}] = \lvert \Pr [W_0] - \Pr[W_1] \rvert.
|
> \mathrm{Adv}_\mathrm{SS}[\mathcal{A}, \mathcal{E}] = \lvert \Pr [W_0] - \Pr[W_1] \rvert.
|
||||||
> $$
|
> $$
|
||||||
@@ -340,17 +341,17 @@ As we understood the advantage of PRG, semantic security advantage can be unders
|
|||||||
In the same way, we can define a security game for distinguishing two distributions.
|
In the same way, we can define a security game for distinguishing two distributions.
|
||||||
|
|
||||||
> **Definition.** Let $P_0$, $P_1$ be two distributions over a set $\mathcal{S}$. For any given efficient adversary $\mathcal{A}$, define experiments $0$ and $1$.
|
> **Definition.** Let $P_0$, $P_1$ be two distributions over a set $\mathcal{S}$. For any given efficient adversary $\mathcal{A}$, define experiments $0$ and $1$.
|
||||||
>
|
>
|
||||||
> **Experiment $b$.**
|
> **Experiment $b$.**
|
||||||
> 1. The challenger computes $x \leftarrow P_b$ and sends $x$ to the adversary.
|
> 1. The challenger computes $x \leftarrow P_b$ and sends $x$ to the adversary.
|
||||||
> 2. The adversary computes and outputs a bit $b' \in \lbrace 0, 1 \rbrace$.
|
> 2. The adversary computes and outputs a bit $b' \in \lbrace 0, 1 \rbrace$.
|
||||||
>
|
>
|
||||||
> Let $W_b$ the event that $\mathcal{A}$ outputs $1$ in experiment $b$. Then the advantage is defined as
|
> Let $W_b$ the event that $\mathcal{A}$ outputs $1$ in experiment $b$. Then the advantage is defined as
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \mathrm{Adv}[\mathcal{A}] = \lvert \Pr[W_0] - \Pr[W_1] \rvert
|
> \mathrm{Adv}[\mathcal{A}] = \lvert \Pr[W_0] - \Pr[W_1] \rvert
|
||||||
> $$
|
> $$
|
||||||
>
|
>
|
||||||
> If the advantage is negligible, we say that $P_0$ and $P_1$ are **computationally indistinguishable**, and write $P_0 \approx_c P_1$.
|
> If the advantage is negligible, we say that $P_0$ and $P_1$ are **computationally indistinguishable**, and write $P_0 \approx_c P_1$.
|
||||||
|
|
||||||
As an example, a PRG $G$ is secure if the two distributions $G(k)$ over $k \leftarrow \lbrace 0, 1 \rbrace^s$ and $r \leftarrow \lbrace 0, 1 \rbrace^n$ are *computationally indistinguishable*.
|
As an example, a PRG $G$ is secure if the two distributions $G(k)$ over $k \leftarrow \lbrace 0, 1 \rbrace^s$ and $r \leftarrow \lbrace 0, 1 \rbrace^n$ are *computationally indistinguishable*.
|
||||||
@@ -421,7 +422,7 @@ $$
|
|||||||
which is non-negligible, so it breaks the security of the PRG.
|
which is non-negligible, so it breaks the security of the PRG.
|
||||||
|
|
||||||
> **Corollary.** For any adversary $\mathcal{A}$ for the stream cipher $\mathcal{E}$, there exists an adversary $\mathcal{B}$ for a PRG $G$ such that
|
> **Corollary.** For any adversary $\mathcal{A}$ for the stream cipher $\mathcal{E}$, there exists an adversary $\mathcal{B}$ for a PRG $G$ such that
|
||||||
>
|
>
|
||||||
> $$
|
> $$
|
||||||
> \mathrm{Adv}_\mathrm{SS}[\mathcal{A}, \mathcal{E}] \leq 2 \cdot \mathrm{Adv}_\mathrm{PRG}[\mathcal{B}, G].
|
> \mathrm{Adv}_\mathrm{SS}[\mathcal{A}, \mathcal{E}] \leq 2 \cdot \mathrm{Adv}_\mathrm{PRG}[\mathcal{B}, G].
|
||||||
> $$
|
> $$
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,9 +14,9 @@ title: 2. PRFs, PRPs and Block Ciphers
|
|||||||
date: 2023-09-12
|
date: 2023-09-12
|
||||||
github_title: 2023-09-12-prfs-prps-block-ciphers
|
github_title: 2023-09-12-prfs-prps-block-ciphers
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-block-cipher.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-02-block-cipher.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
## Pseudorandom Functions (PRF)
|
## Pseudorandom Functions (PRF)
|
||||||
@@ -118,7 +119,7 @@ This is a matter of *collisions* of $f(x_i)$, so we use the facts from the birth
|
|||||||
|
|
||||||
A **block cipher** is actually a different name for PRPs. Since a PRP $E$ is a keyed function, applying $E(k, x)$ is in fact encryption, and applying its inverse is decryption.
|
A **block cipher** is actually a different name for PRPs. Since a PRP $E$ is a keyed function, applying $E(k, x)$ is in fact encryption, and applying its inverse is decryption.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Block ciphers commonly have the following form.
|
Block ciphers commonly have the following form.
|
||||||
- A key $k$ is chosen uniformly from $\left\lbrace 0, 1 \right\rbrace^s$.
|
- A key $k$ is chosen uniformly from $\left\lbrace 0, 1 \right\rbrace^s$.
|
||||||
@@ -140,7 +141,7 @@ Block ciphers commonly have the following form.
|
|||||||
|
|
||||||
Since block ciphers are PRPs, we have to build an invertible function. Suppose we are given **any** functions $F_1, \dots, F_d : \left\lbrace 0, 1 \right\rbrace^n \rightarrow \left\lbrace 0, 1 \right\rbrace^n$. Can we build an **invertible** function $F : \left\lbrace 0, 1 \right\rbrace^{2n} \rightarrow \left\lbrace 0, 1 \right\rbrace^{2n}$?
|
Since block ciphers are PRPs, we have to build an invertible function. Suppose we are given **any** functions $F_1, \dots, F_d : \left\lbrace 0, 1 \right\rbrace^n \rightarrow \left\lbrace 0, 1 \right\rbrace^n$. Can we build an **invertible** function $F : \left\lbrace 0, 1 \right\rbrace^{2n} \rightarrow \left\lbrace 0, 1 \right\rbrace^{2n}$?
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
It turns out the answer is yes. Given an $2n$-bit long input, $L_0$ and $R_0$ denote the left and right halves ($n$ bits) of the input, respectively. Define
|
It turns out the answer is yes. Given an $2n$-bit long input, $L_0$ and $R_0$ denote the left and right halves ($n$ bits) of the input, respectively. Define
|
||||||
|
|
||||||
@@ -160,7 +161,7 @@ Note that we did not require $F_i$ to be invertible. We can build invertible fun
|
|||||||
|
|
||||||
In DES, the function $F_i$ is the DES round function.
|
In DES, the function $F_i$ is the DES round function.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using $E$. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a permutation $P$ at the end, resulting in $32$ bit data.
|
The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunks. Each chunk is expanded to $6$ bits using $E$. Now, we have 48 bits of data, so apply XOR with the key for this round. Next, each $6$-bit block is compressed back to $4$ bits using a S-box. Finally, there is a permutation $P$ at the end, resulting in $32$ bit data.
|
||||||
|
|
||||||
@@ -168,7 +169,7 @@ The Feistel function takes $32$ bit data and divides it into eight $4$ bit chunk
|
|||||||
|
|
||||||
DES uses $56$ bit keys that generate $16$ rounds keys. The diagram below shows that DES has 16-round Feistel networks.
|
DES uses $56$ bit keys that generate $16$ rounds keys. The diagram below shows that DES has 16-round Feistel networks.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
The input goes through initial/final permutation, which are inverses of each other. These have no cryptographic significance, and just for engineering.
|
The input goes through initial/final permutation, which are inverses of each other. These have no cryptographic significance, and just for engineering.
|
||||||
|
|
||||||
@@ -176,7 +177,7 @@ The input goes through initial/final permutation, which are inverses of each oth
|
|||||||
|
|
||||||
DES is not secure, since key space and block length is too small. Thankfully, we have a replacement called the **advanced encryption standard** (AES).
|
DES is not secure, since key space and block length is too small. Thankfully, we have a replacement called the **advanced encryption standard** (AES).
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- DES key only had $56$ bits, so DES was broken in the 1990s
|
- DES key only had $56$ bits, so DES was broken in the 1990s
|
||||||
- NIST standardized AES in 2001, based on Rijndael cipher
|
- NIST standardized AES in 2001, based on Rijndael cipher
|
||||||
@@ -254,7 +255,7 @@ Then the key space has increased (exponentially). As for 2DES, the key space is
|
|||||||
|
|
||||||
Unfortunately, 2DES is only secure as DES, with the attack strategy called **meet in the middle**. The idea is that if $c = E(k_1, E(k_2, m))$, then $D(k_1, c) = E(k_2, m)$.
|
Unfortunately, 2DES is only secure as DES, with the attack strategy called **meet in the middle**. The idea is that if $c = E(k_1, E(k_2, m))$, then $D(k_1, c) = E(k_2, m)$.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Since we have the plaintext and the ciphertext, we first build a table of $(k, E(k_2, m))$ over $k_2 \in \mathcal{K}$ and sort by $E(k_2, m)$. Next, we check if $D(k_1, c)$ is in the table for all $k_1 \in \mathcal{K}$.
|
Since we have the plaintext and the ciphertext, we first build a table of $(k, E(k_2, m))$ over $k_2 \in \mathcal{K}$ and sort by $E(k_2, m)$. Next, we check if $D(k_1, c)$ is in the table for all $k_1 \in \mathcal{K}$.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -127,11 +128,11 @@ We learned how to encrypt a single block. How do we encrypt longer messages with
|
|||||||
|
|
||||||
There are many ways of processing multiple blocks, this is called the **mode of operation**.
|
There are many ways of processing multiple blocks, this is called the **mode of operation**.
|
||||||
|
|
||||||
Additional explanation available in [Modes of Operations (Internet Security)](../../internet-security/2023-09-18-symmetric-key-cryptography-2#modes-of-operations).
|
Additional explanation available in [Modes of Operations (Internet Security)](../../internet-security/2023-09-18-symmetric-key-cryptography-2/#modes-of-operations).
|
||||||
|
|
||||||
### Electronic Codebook Mode (ECB)
|
### Electronic Codebook Mode (ECB)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
- ECB mode encrypts each block with the same key.
|
- ECB mode encrypts each block with the same key.
|
||||||
- Blocks are independent of each other.
|
- Blocks are independent of each other.
|
||||||
@@ -139,7 +140,7 @@ Additional explanation available in [Modes of Operations (Internet Security)](..
|
|||||||
|
|
||||||
### Ciphertext Block Chain Mode (CBC)
|
### Ciphertext Block Chain Mode (CBC)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Let $X = \left\lbrace 0, 1 \right\rbrace^n$ and $E : \mathcal{K} \times X \rightarrow X$ be a **PRP**.
|
Let $X = \left\lbrace 0, 1 \right\rbrace^n$ and $E : \mathcal{K} \times X \rightarrow X$ be a **PRP**.
|
||||||
|
|
||||||
@@ -190,7 +191,7 @@ Note that if $k_1$ is the same as the key used for encrypting messages, then thi
|
|||||||
|
|
||||||
### Counter Mode (CTR)
|
### Counter Mode (CTR)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Let $F : \mathcal{K} \times X \rightarrow X$ be a secure **PRF**.
|
Let $F : \mathcal{K} \times X \rightarrow X$ be a secure **PRF**.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,9 +14,9 @@ title: 4. Message Authentication Codes
|
|||||||
date: 2023-09-21
|
date: 2023-09-21
|
||||||
github_title: 2023-09-21-macs
|
github_title: 2023-09-21-macs
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-mac-security.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-04-mac-security.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
Message authentication codes (MAC) were designed to provide message integrity. Bob receives a message from Alice and wants to know if this message was not modified during transmission. For MACs, the message itself does not have to be secret. For example, when we download a file the file itself does not have to be protected, but we need a way to verify that the file was not modified.
|
Message authentication codes (MAC) were designed to provide message integrity. Bob receives a message from Alice and wants to know if this message was not modified during transmission. For MACs, the message itself does not have to be secret. For example, when we download a file the file itself does not have to be protected, but we need a way to verify that the file was not modified.
|
||||||
@@ -26,7 +27,7 @@ On the other hand, MAC fixes data that is tampered in purpose. We will also requ
|
|||||||
|
|
||||||
## Message Authentication Code
|
## Message Authentication Code
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** A **MAC** system $\Pi = (S, V)$ defined over $(\mathcal{K}, \mathcal{M}, \mathcal{T})$ is a pair of efficient algorithms $S$ and $V$ where $S$ is a **signing algorithm** and $V$ is a **verification algorithm**.
|
> **Definition.** A **MAC** system $\Pi = (S, V)$ defined over $(\mathcal{K}, \mathcal{M}, \mathcal{T})$ is a pair of efficient algorithms $S$ and $V$ where $S$ is a **signing algorithm** and $V$ is a **verification algorithm**.
|
||||||
>
|
>
|
||||||
@@ -58,7 +59,7 @@ In the security definition of MACs, we allow the attacker to request tags for ar
|
|||||||
|
|
||||||
For strong MACs, the attacker only has to change the tag for the attack to succeed.
|
For strong MACs, the attacker only has to change the tag for the attack to succeed.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $\Pi = (S, V)$ be a MAC system defined over $(\mathcal{K}, \mathcal{M}, \mathcal{T})$. Given an adversary $\mathcal{A}$, the security game goes as follows.
|
> **Definition.** Let $\Pi = (S, V)$ be a MAC system defined over $(\mathcal{K}, \mathcal{M}, \mathcal{T})$. Given an adversary $\mathcal{A}$, the security game goes as follows.
|
||||||
>
|
>
|
||||||
@@ -123,7 +124,7 @@ The above construction uses a PRF, so it is restricted to messages of fixed size
|
|||||||
|
|
||||||
### CBC-MAC
|
### CBC-MAC
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** For any message $m = (m_0, m_1, \dots, m_{l-1}) \in \left\lbrace 0, 1 \right\rbrace^{nl}$, let $F_k := F(k, \cdot)$.
|
> **Definition.** For any message $m = (m_0, m_1, \dots, m_{l-1}) \in \left\lbrace 0, 1 \right\rbrace^{nl}$, let $F_k := F(k, \cdot)$.
|
||||||
>
|
>
|
||||||
@@ -211,7 +212,7 @@ Since CBC-MAC is vulnerable to extension attacks, we encrypt the last block agai
|
|||||||
|
|
||||||
ECBC-MAC doesn't require us to know the message length in advance, but it is relatively expensive in practice, since a block cipher has to be initialized with a new key.
|
ECBC-MAC doesn't require us to know the message length in advance, but it is relatively expensive in practice, since a block cipher has to be initialized with a new key.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Theorem.** Let $F : \mathcal{K} \times X \rightarrow X$ be a secure PRF. Then for any $l \geq 0$, $F_\mathrm{ECBC} : \mathcal{K}^2 \times X^{\leq l} \rightarrow X$ is a secure PRF.
|
> **Theorem.** Let $F : \mathcal{K} \times X \rightarrow X$ be a secure PRF. Then for any $l \geq 0$, $F_\mathrm{ECBC} : \mathcal{K}^2 \times X^{\leq l} \rightarrow X$ is a secure PRF.
|
||||||
>
|
>
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,9 +14,9 @@ title: 5. CCA-Security and Authenticated Encryption
|
|||||||
date: 2023-09-26
|
date: 2023-09-26
|
||||||
github_title: 2023-09-26-cca-security-authenticated-encryption
|
github_title: 2023-09-26-cca-security-authenticated-encryption
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-05-ci.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-05-ci.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
Previously, we focused on semantic security against **passive adversaries**, that only eavesdrop on the ciphertext. But in the real world, there are **active adversaries** that interfere with the communication, or even modify them.
|
Previously, we focused on semantic security against **passive adversaries**, that only eavesdrop on the ciphertext. But in the real world, there are **active adversaries** that interfere with the communication, or even modify them.
|
||||||
@@ -53,7 +54,7 @@ Now we define a stronger notion of security against **chosen ciphertext attacks*
|
|||||||
|
|
||||||
None of the encryption schemes already seen thus far is CCA secure.
|
None of the encryption schemes already seen thus far is CCA secure.
|
||||||
|
|
||||||
Recall a [CPA secure construction from PRF](../2023-09-19-symmetric-key-encryption#secure-construction-from-prf). This scheme is not CCA secure. Suppose that the adversary is given $c^* = (r, F(k, r) \oplus m_b)$. Then it can request a decryption for $c' = (r, s')$ for some $s'$ and receive $m' = s' \oplus F(k, r)$. Then $F(k, r) = m' \oplus s'$, so the adversary can successfully recover $m_b$.
|
Recall a [CPA secure construction from PRF](../2023-09-19-symmetric-key-encryption/#secure-construction-from-prf). This scheme is not CCA secure. Suppose that the adversary is given $c^* = (r, F(k, r) \oplus m_b)$. Then it can request a decryption for $c' = (r, s')$ for some $s'$ and receive $m' = s' \oplus F(k, r)$. Then $F(k, r) = m' \oplus s'$, so the adversary can successfully recover $m_b$.
|
||||||
|
|
||||||
In general, any encryption scheme that allows ciphertexts to be *manipulated* in a controlled way cannot be CCA secure.
|
In general, any encryption scheme that allows ciphertexts to be *manipulated* in a controlled way cannot be CCA secure.
|
||||||
|
|
||||||
@@ -83,7 +84,7 @@ The attacker shouldn't be able to create a new ciphertext that decrypts properly
|
|||||||
|
|
||||||
In this case, we fix the decryption algorithm so that $D : \mathcal{K} \times \mathcal{C} \rightarrow \mathcal{M} \cup \left\lbrace \bot \right\rbrace$, where $\bot$ means that the ciphertext was rejected.
|
In this case, we fix the decryption algorithm so that $D : \mathcal{K} \times \mathcal{C} \rightarrow \mathcal{M} \cup \left\lbrace \bot \right\rbrace$, where $\bot$ means that the ciphertext was rejected.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $\mathcal{E} = (E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. Given an adversary $\mathcal{A}$, the security game goes as follows.
|
> **Definition.** Let $\mathcal{E} = (E, D)$ be a cipher defined over $(\mathcal{K}, \mathcal{M}, \mathcal{C})$. Given an adversary $\mathcal{A}$, the security game goes as follows.
|
||||||
>
|
>
|
||||||
@@ -138,7 +139,7 @@ Most natural constructions of CCA secure schemes satisfy AE, so we don't need to
|
|||||||
|
|
||||||
We want to combine CPA secure scheme and strongly secure MAC to get AE. Rather than focusing on the internal structure of the scheme, we want a general method to compose these two secure schemes so that we can get a AE secure scheme. We will see 3 examples.
|
We want to combine CPA secure scheme and strongly secure MAC to get AE. Rather than focusing on the internal structure of the scheme, we want a general method to compose these two secure schemes so that we can get a AE secure scheme. We will see 3 examples.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
### Encrypt-and-MAC (E&M)
|
### Encrypt-and-MAC (E&M)
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,9 +14,9 @@ title: 6. Hash Functions
|
|||||||
date: 2023-09-28
|
date: 2023-09-28
|
||||||
github_title: 2023-09-28-hash-functions
|
github_title: 2023-09-28-hash-functions
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-merkle-damgard.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-06-merkle-damgard.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
Hash functions are functions that take some input an compress them to produce an output of fixed size, usually just called *hash* or *digest*. A desired property of hash function is **collision resistance**.
|
Hash functions are functions that take some input an compress them to produce an output of fixed size, usually just called *hash* or *digest*. A desired property of hash function is **collision resistance**.
|
||||||
@@ -106,7 +107,7 @@ Now we want to construct collision resistant hash functions that work for arbitr
|
|||||||
|
|
||||||
The Merkle-Damgård transform gives as a way to extend our input domain of the hash function by iterating the function.
|
The Merkle-Damgård transform gives as a way to extend our input domain of the hash function by iterating the function.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $h : \left\lbrace 0, 1 \right\rbrace^n \times \left\lbrace 0, 1 \right\rbrace^l \rightarrow \left\lbrace 0, 1 \right\rbrace^n$ be a hash function. The **Merkle-Damgård function derived from $h$** is a function $H$ that works as follows.
|
> **Definition.** Let $h : \left\lbrace 0, 1 \right\rbrace^n \times \left\lbrace 0, 1 \right\rbrace^l \rightarrow \left\lbrace 0, 1 \right\rbrace^n$ be a hash function. The **Merkle-Damgård function derived from $h$** is a function $H$ that works as follows.
|
||||||
>
|
>
|
||||||
@@ -149,9 +150,9 @@ See Joux's attack.[^2]
|
|||||||
|
|
||||||
Now we only have to build a collision resistant compression function. We can build these functions from either a block cipher, or by using number theoretic primitives.
|
Now we only have to build a collision resistant compression function. We can build these functions from either a block cipher, or by using number theoretic primitives.
|
||||||
|
|
||||||
Number theoretic primitives will be shown after we learn some number theory.[^3] An example is shown in [collision resistance using DL problem (Modern Cryptography)](../2023-10-03-key-exchange#collision-resistance-based-on-dl-problem).
|
Number theoretic primitives will be shown after we learn some number theory.[^3] An example is shown in [collision resistance using DL problem (Modern Cryptography)](../2023-10-03-key-exchange/#collision-resistance-based-on-dl-problem).
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $\mathcal{E} = (E, D)$ be a block cipher over $(\mathcal{K}, X, X)$ where $X = \left\lbrace 0, 1 \right\rbrace^n$. The **Davies-Meyer compression function derived from $E$** maps inputs in $X \times \mathcal{K}$ to outputs in $X$, defined as follows.
|
> **Definition.** Let $\mathcal{E} = (E, D)$ be a block cipher over $(\mathcal{K}, X, X)$ where $X = \left\lbrace 0, 1 \right\rbrace^n$. The **Davies-Meyer compression function derived from $E$** maps inputs in $X \times \mathcal{K}$ to outputs in $X$, defined as follows.
|
||||||
>
|
>
|
||||||
@@ -194,7 +195,7 @@ We needed a complicated construction for MACs that work on long messages. We mig
|
|||||||
|
|
||||||
Here are a few approaches. Suppose that a compression function $h$ is given and $H$ is a Merkle-Damgård function derived from $h$.
|
Here are a few approaches. Suppose that a compression function $h$ is given and $H$ is a Merkle-Damgård function derived from $h$.
|
||||||
|
|
||||||
Recall that [we can construct a MAC scheme from a PRF](../2023-09-21-macs#mac-constructions-from-prfs), so either we want a secure PRF or a secure MAC scheme.
|
Recall that [we can construct a MAC scheme from a PRF](../2023-09-21-macs/#mac-constructions-from-prfs), so either we want a secure PRF or a secure MAC scheme.
|
||||||
|
|
||||||
#### Prepending the Key
|
#### Prepending the Key
|
||||||
|
|
||||||
@@ -214,9 +215,9 @@ Define $S((k_1,k_2), m) = H(k_2 \parallel H(k_1 \parallel m))$. This can also be
|
|||||||
|
|
||||||
This can be thought of as blocking the length extension attack from prepending the key method.
|
This can be thought of as blocking the length extension attack from prepending the key method.
|
||||||
|
|
||||||
### HMAC
|
### HMAC Definition
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
This is a variant of the two-key nest, but the difference is that the keys $k_1', k_2'$ are not independent. Choose a key $k \leftarrow \mathcal{K}$, and set
|
This is a variant of the two-key nest, but the difference is that the keys $k_1', k_2'$ are not independent. Choose a key $k \leftarrow \mathcal{K}$, and set
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,9 +14,9 @@ title: 7. Key Exchange
|
|||||||
date: 2023-10-03
|
date: 2023-10-03
|
||||||
github_title: 2023-10-03-key-exchange
|
github_title: 2023-10-03-key-exchange
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-dhke.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-07-dhke.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
In symmetric key encryption, we assumed that the two parties already share the same key. We will see how this can be done.
|
In symmetric key encryption, we assumed that the two parties already share the same key. We will see how this can be done.
|
||||||
@@ -74,7 +75,7 @@ $$
|
|||||||
|
|
||||||
We assume that the description of $p$, $q$ and $g$ are generated at the setup and shared by all parties. Now the actual protocol goes like this.
|
We assume that the description of $p$, $q$ and $g$ are generated at the setup and shared by all parties. Now the actual protocol goes like this.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> 1. Alice chooses $\alpha \leftarrow \mathbb{Z}_q$ and computes $g^\alpha$.
|
> 1. Alice chooses $\alpha \leftarrow \mathbb{Z}_q$ and computes $g^\alpha$.
|
||||||
> 2. Bob chooses $\beta \leftarrow \mathbb{Z}_q$ and computes $g^\beta$.
|
> 2. Bob chooses $\beta \leftarrow \mathbb{Z}_q$ and computes $g^\beta$.
|
||||||
@@ -189,7 +190,7 @@ Taking $\mathcal{O}(N)$ steps is impractical in the real world, due to many comm
|
|||||||
|
|
||||||
We assumed that the adversary only eavesdrops, but if the adversary carries out active attacks, then DHKE is not enough. The major problem is the lack of **authentication**. Alice and Bob are exchanging keys, but they both cannot be sure that there are in fact communicating with the other. An attacker can intercept messages and impersonate Alice or Bob. This attack is called a **man in the middle attack**, and this attack works on any key exchange protocol that lacks authentication.
|
We assumed that the adversary only eavesdrops, but if the adversary carries out active attacks, then DHKE is not enough. The major problem is the lack of **authentication**. Alice and Bob are exchanging keys, but they both cannot be sure that there are in fact communicating with the other. An attacker can intercept messages and impersonate Alice or Bob. This attack is called a **man in the middle attack**, and this attack works on any key exchange protocol that lacks authentication.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
The adversary will impersonate Bob when communicating with Alice, and will do the same for Bob by pretending to be Alice. The values of $\alpha, \beta$ that Alice and Bob chose are not leaked, but the adversary can decrypt anything in the middle and obtain the plaintext.
|
The adversary will impersonate Bob when communicating with Alice, and will do the same for Bob by pretending to be Alice. The values of $\alpha, \beta$ that Alice and Bob chose are not leaked, but the adversary can decrypt anything in the middle and obtain the plaintext.
|
||||||
|
|
||||||
@@ -211,7 +212,7 @@ Before Diffie-Hellman, Merkle proposed an idea for secure key exchange protocol
|
|||||||
|
|
||||||
The idea was to use *puzzles*, which are problems that can be solved with some effort.
|
The idea was to use *puzzles*, which are problems that can be solved with some effort.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> Let $\mathcal{E} = (E, D)$ be a block cipher defined over $(\mathcal{K}, \mathcal{M})$.
|
> Let $\mathcal{E} = (E, D)$ be a block cipher defined over $(\mathcal{K}, \mathcal{M})$.
|
||||||
> 1. Alice chooses random pairs $(k_i, s_i) \leftarrow \mathcal{K} \times \mathcal{M}$ for $i = 1, \dots, L$.
|
> 1. Alice chooses random pairs $(k_i, s_i) \leftarrow \mathcal{K} \times \mathcal{M}$ for $i = 1, \dots, L$.
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -15,7 +16,6 @@ date: 2023-10-05
|
|||||||
github_title: 2023-10-05-number-theory
|
github_title: 2023-10-05-number-theory
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
## Background
|
## Background
|
||||||
|
|
||||||
### Number Theory
|
### Number Theory
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -18,7 +19,6 @@ attachment:
|
|||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
In symmetric encryption, we assumed that the two parties had a shared key in advance. If the two parties do not have a shared key, **public-key encryption** can be used to encrypt messages.
|
In symmetric encryption, we assumed that the two parties had a shared key in advance. If the two parties do not have a shared key, **public-key encryption** can be used to encrypt messages.
|
||||||
|
|
||||||
## Public Key Encryption
|
## Public Key Encryption
|
||||||
@@ -45,7 +45,7 @@ Public key $pk$ will be publicized. After Alice obtains $pk$, she can use it to
|
|||||||
|
|
||||||
The following notion of security is only for an eavesdropping adversary.
|
The following notion of security is only for an eavesdropping adversary.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $\mc{E} = (G, E, D)$ be a public key encryption scheme defined over $(\mc{M}, \mc{C})$. For an adversary $\mc{A}$, we define two experiments.
|
> **Definition.** Let $\mc{E} = (G, E, D)$ be a public key encryption scheme defined over $(\mc{M}, \mc{C})$. For an adversary $\mc{A}$, we define two experiments.
|
||||||
>
|
>
|
||||||
@@ -176,7 +176,7 @@ Similarly, 1CCA security implies CCA security, as in the above theorem. So to sh
|
|||||||
|
|
||||||
### Active Adversaries in Symmetric vs Public Key
|
### Active Adversaries in Symmetric vs Public Key
|
||||||
|
|
||||||
In symmetric key encryption, we studied [authenticated encryption (AE)](../2023-09-26-cca-security-authenticated-encryption/#authenticated-encryption-ae), which required the scheme to be CPA secure and provide ciphertext integrity. In symmetric key settings, AE implied CCA.
|
In symmetric key encryption, we studied [authenticated encryption (AE)](../2023-09-26-cca-security-authenticated-encryption/#authenticated-encryption-(ae)), which required the scheme to be CPA secure and provide ciphertext integrity. In symmetric key settings, AE implied CCA.
|
||||||
|
|
||||||
However in public-key schemes, adversaries can always create new ciphertexts using the public key, which makes the original definition of ciphertext integrity unusable. Thus we directly require CCA security.
|
However in public-key schemes, adversaries can always create new ciphertexts using the public key, which makes the original definition of ciphertext integrity unusable. Thus we directly require CCA security.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,12 +14,11 @@ title: 10. Digital Signatures
|
|||||||
date: 2023-10-26
|
date: 2023-10-26
|
||||||
github_title: 2023-10-26-digital-signatures
|
github_title: 2023-10-26-digital-signatures
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-10-dsig-security.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-10-dsig-security.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
## Digital Signatures
|
## Digital Signatures
|
||||||
|
|
||||||
> **Definition.** A **signature scheme** $\mc{S} = (G, S, V)$ is a triple of efficient algorithms, where $G$ is a **key generation** algorithm, $S$ is a **signing** algorithm, and $V$ is a **verification** algorithm.
|
> **Definition.** A **signature scheme** $\mc{S} = (G, S, V)$ is a triple of efficient algorithms, where $G$ is a **key generation** algorithm, $S$ is a **signing** algorithm, and $V$ is a **verification** algorithm.
|
||||||
@@ -57,7 +57,7 @@ $$
|
|||||||
|
|
||||||
The definition is similar to the [secure MAC](../2023-09-21-macs/#secure-mac-unforgeability). The adversary can perform a **chosen message attack**, but cannot create an **existential forgery**.
|
The definition is similar to the [secure MAC](../2023-09-21-macs/#secure-mac-unforgeability). The adversary can perform a **chosen message attack**, but cannot create an **existential forgery**.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $\mc{S} = (G, S, V)$ be a signature scheme defined over $(\mc{M}, \Sigma)$. Given an adversary $\mc{A}$, the game goes as follows.
|
> **Definition.** Let $\mc{S} = (G, S, V)$ be a signature scheme defined over $(\mc{M}, \Sigma)$. Given an adversary $\mc{A}$, the game goes as follows.
|
||||||
>
|
>
|
||||||
@@ -184,7 +184,7 @@ This scheme is originally from the **Schnorr identification protocol**.
|
|||||||
|
|
||||||
Let $G = \left\langle g \right\rangle$ be a cyclic group of prime order $q$. We consider an interaction between two parties, prover $P$ and a verifier $V$. The prover has a secret $\alpha \in \Z_q$ and the verification key is $u = g^\alpha$. **$P$ wants to convince $V$ that he knows $\alpha$, but does not want to reveal $\alpha$**.
|
Let $G = \left\langle g \right\rangle$ be a cyclic group of prime order $q$. We consider an interaction between two parties, prover $P$ and a verifier $V$. The prover has a secret $\alpha \in \Z_q$ and the verification key is $u = g^\alpha$. **$P$ wants to convince $V$ that he knows $\alpha$, but does not want to reveal $\alpha$**.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
The protocol $\mc{I}_\rm{sch} = (G, P, V)$ works as follows.
|
The protocol $\mc{I}_\rm{sch} = (G, P, V)$ works as follows.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -14,7 +15,6 @@ date: 2023-10-31
|
|||||||
github_title: 2023-10-31-advanced-topics
|
github_title: 2023-10-31-advanced-topics
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
## Ciphertext Indistinguishability
|
## Ciphertext Indistinguishability
|
||||||
|
|
||||||
- By **Shafi Goldwasser** and **Silvio Micali**
|
- By **Shafi Goldwasser** and **Silvio Micali**
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,12 +14,11 @@ title: 12. Zero-Knowledge Proof (Introduction)
|
|||||||
date: 2023-11-02
|
date: 2023-11-02
|
||||||
github_title: 2023-11-02-zkp-intro
|
github_title: 2023-11-02-zkp-intro
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-12-id-protocol.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-12-id-protocol.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
- In 1980s, the notion of *zero knowledge* was proposed by Shafi Goldwasser, Silvio micali and Charles Rackoff.
|
- In 1980s, the notion of *zero knowledge* was proposed by Shafi Goldwasser, Silvio micali and Charles Rackoff.
|
||||||
- **Interactive proof systems**: a **prover** tries to convince the **verifier** that some statement is true, by exchanging messages.
|
- **Interactive proof systems**: a **prover** tries to convince the **verifier** that some statement is true, by exchanging messages.
|
||||||
- What if the prover is trying to trick the verifier?
|
- What if the prover is trying to trick the verifier?
|
||||||
@@ -28,7 +28,7 @@ attachment:
|
|||||||
|
|
||||||
## Identification Protocol
|
## Identification Protocol
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** An **identification protocol** is a triple of algorithms $\mc{I} = (G, P, V)$ satisfying the following.
|
> **Definition.** An **identification protocol** is a triple of algorithms $\mc{I} = (G, P, V)$ satisfying the following.
|
||||||
>
|
>
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,12 +14,12 @@ title: 13. Sigma Protocols
|
|||||||
date: 2023-11-07
|
date: 2023-11-07
|
||||||
github_title: 2023-11-07-sigma-protocols
|
github_title: 2023-11-07-sigma-protocols
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-sigma-protocol.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-13-sigma-protocol.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
The previous [3-coloring example](./2023-11-02-zkp-intro.md#example-3-coloring) certainly works as a zero knowledge proof, but is quite slow, and requires a lot of interaction. There are efficient protocols for interactive proofs, we will study sigma protocols.
|
The previous [3-coloring example](../2023-11-02-zkp-intro/#example-3-coloring) certainly works as a zero knowledge proof, but is quite slow, and requires a lot of interaction. There are efficient protocols for interactive proofs, we will study sigma protocols.
|
||||||
|
|
||||||
## Sigma Protocols
|
## Sigma Protocols
|
||||||
|
|
||||||
@@ -26,7 +27,7 @@ The previous [3-coloring example](./2023-11-02-zkp-intro.md#example-3-coloring)
|
|||||||
|
|
||||||
> **Definition.** An **effective relation** is a binary relation $\mc{R} \subset \mc{X} \times \mc{Y}$, where $\mc{X}$, $\mc{Y}$, $\mc{R}$ are efficiently recognizable finite sets. Elements of $\mc{Y}$ are called **statements**. If $(x, y) \in \mc{R}$, then $x$ is called a **witness for** $y$.
|
> **Definition.** An **effective relation** is a binary relation $\mc{R} \subset \mc{X} \times \mc{Y}$, where $\mc{X}$, $\mc{Y}$, $\mc{R}$ are efficiently recognizable finite sets. Elements of $\mc{Y}$ are called **statements**. If $(x, y) \in \mc{R}$, then $x$ is called a **witness for** $y$.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> **Definition.** Let $\mc{R} \subset \mc{X} \times \mc{Y}$ be an effective relation. A **sigma protocol** for $\mc{R}$ is a pair of algorithms $(P, V)$ satisfying the following.
|
> **Definition.** Let $\mc{R} \subset \mc{X} \times \mc{Y}$ be an effective relation. A **sigma protocol** for $\mc{R}$ is a pair of algorithms $(P, V)$ satisfying the following.
|
||||||
>
|
>
|
||||||
@@ -104,9 +105,9 @@ Also note that **the simulator is free to generate the messages in any convenien
|
|||||||
|
|
||||||
## The Schnorr Identification Protocol Revisited
|
## The Schnorr Identification Protocol Revisited
|
||||||
|
|
||||||
The Schnorr identification protocol is actually a sigma protocol. Refer to [Schnorr identification protocol (Modern Cryptography)](./2023-10-26-digital-signatures.md#the-schnorr-identification-protocol) for the full description.
|
The Schnorr identification protocol is actually a sigma protocol. Refer to [Schnorr identification protocol (Modern Cryptography)](../2023-10-26-digital-signatures/#the-schnorr-identification-protocol) for the full description.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> The pair $(P, V)$ is a sigma protocol for the relation $\mc{R} \subset \mc{X} \times \mc{Y}$ where
|
> The pair $(P, V)$ is a sigma protocol for the relation $\mc{R} \subset \mc{X} \times \mc{Y}$ where
|
||||||
>
|
>
|
||||||
@@ -164,7 +165,7 @@ $$
|
|||||||
|
|
||||||
goes as follows.
|
goes as follows.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> 1. $P$ computes random $\alpha_t, \beta_t \la \bb{Z}_q$ and sends commitment $u_t \la g^{\alpha_t}h^{\beta_t}$ to $V$.
|
> 1. $P$ computes random $\alpha_t, \beta_t \la \bb{Z}_q$ and sends commitment $u_t \la g^{\alpha_t}h^{\beta_t}$ to $V$.
|
||||||
> 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
|
> 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
|
||||||
@@ -191,7 +192,7 @@ $$
|
|||||||
|
|
||||||
goes as follows.
|
goes as follows.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> 1. $P$ computes random $\beta_t \la \bb{Z}_q$ and sends commitment $v_t \la g^{\beta_t}$, $w_t \la u^{\beta_t}$ to $V$.
|
> 1. $P$ computes random $\beta_t \la \bb{Z}_q$ and sends commitment $v_t \la g^{\beta_t}$, $w_t \la u^{\beta_t}$ to $V$.
|
||||||
> 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
|
> 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
|
||||||
@@ -222,7 +223,7 @@ $$
|
|||||||
|
|
||||||
goes as follows.
|
goes as follows.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> 1. $P$ computes random $x_t \la \bb{Z}_n^{\ast}$ and sends commitment $y_t \la x_t^e$ to $V$.
|
> 1. $P$ computes random $x_t \la \bb{Z}_n^{\ast}$ and sends commitment $y_t \la x_t^e$ to $V$.
|
||||||
> 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
|
> 2. $V$ computes challenge $c \la \mc{C}$ and sends it to $P$.
|
||||||
@@ -424,7 +425,7 @@ Omitted. Works...
|
|||||||
|
|
||||||
### The Fiat-Shamir Signature Scheme
|
### The Fiat-Shamir Signature Scheme
|
||||||
|
|
||||||
Now we understand why the [Schnorr signature scheme](./2023-10-26-digital-signatures.md#schnorr-digital-signature-scheme) used hash functions. In general, the Fiat-Shamir transform can be used to convert sigma protocols into signature schemes.
|
Now we understand why the [Schnorr signature scheme](../2023-10-26-digital-signatures/#schnorr-digital-signature-scheme) used hash functions. In general, the Fiat-Shamir transform can be used to convert sigma protocols into signature schemes.
|
||||||
|
|
||||||
We need $3$ building blocks.
|
We need $3$ building blocks.
|
||||||
|
|
||||||
@@ -449,7 +450,7 @@ If an adversary can come up with a forgery, then the underlying sigma protocol i
|
|||||||
|
|
||||||
$n$ voters are casting a vote, either $0$ or $1$. At the end, all voters learn the sum of the votes, but we want to keep the votes secret for each party.
|
$n$ voters are casting a vote, either $0$ or $1$. At the end, all voters learn the sum of the votes, but we want to keep the votes secret for each party.
|
||||||
|
|
||||||
We can use the [multiplicative ElGamal encryption](./2023-10-19-public-key-encryption.md#the-elgamal-encryption) scheme in this case. Assume that a trusted vote tallying center generates a key pair, keeps $sk = \alpha$ to itself and publishes $pk = g^\alpha$.
|
We can use the [multiplicative ElGamal encryption](../2023-10-19-public-key-encryption/#the-elgamal-encryption) scheme in this case. Assume that a trusted vote tallying center generates a key pair, keeps $sk = \alpha$ to itself and publishes $pk = g^\alpha$.
|
||||||
|
|
||||||
Each voter encrypts the vote $b_i$ and the ciphertext is
|
Each voter encrypts the vote $b_i$ and the ciphertext is
|
||||||
|
|
||||||
@@ -467,7 +468,7 @@ where $\beta^{\ast} = \sum_{i=1}^n \beta_i$ and $b^{\ast} = \sum_{i=1}^n b_i$. N
|
|||||||
|
|
||||||
Since the ElGamal scheme is semantically secure, the protocol is also secure if all voters follow the protocol. But a dishonest voter can encrypt $b_i = -100$ or some arbitrary value.
|
Since the ElGamal scheme is semantically secure, the protocol is also secure if all voters follow the protocol. But a dishonest voter can encrypt $b_i = -100$ or some arbitrary value.
|
||||||
|
|
||||||
To fix this, we can make each voter prove that the vote is valid. Using the [Chaum-Pedersen protocol for DH-triples](2023-11-07-sigma-protocols.md#the-chaum-pedersen-protocol-for-dh-triples) and the [OR-proof construction](2023-11-07-sigma-protocols.md#or-proof-construction), the voter can submit a proof that the ciphertext is either a encryption of $b_i = 0$ or $1$. We can also apply the Fiat-Shamir transform here for efficient protocols, resulting in non-interactive proofs.
|
To fix this, we can make each voter prove that the vote is valid. Using the [Chaum-Pedersen protocol for DH-triples](../2023-11-07-sigma-protocols/#the-chaum-pedersen-protocol-for-dh-triples) and the [OR-proof construction](../2023-11-07-sigma-protocols/#or-proof-construction), the voter can submit a proof that the ciphertext is either a encryption of $b_i = 0$ or $1$. We can also apply the Fiat-Shamir transform here for efficient protocols, resulting in non-interactive proofs.
|
||||||
|
|
||||||
[^1]: The message flows in a shape that resembles the greek letter $\Sigma$, hence the name *sigma protocol*.
|
[^1]: The message flows in a shape that resembles the greek letter $\Sigma$, hence the name *sigma protocol*.
|
||||||
[^2]: A Graduate Course in Applied Cryptography.
|
[^2]: A Graduate Course in Applied Cryptography.
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -14,7 +15,7 @@ date: 2023-11-14
|
|||||||
github_title: 2023-11-14-garbled-circuits
|
github_title: 2023-11-14-garbled-circuits
|
||||||
---
|
---
|
||||||
|
|
||||||
A simple solution for two party computation would be to use oblivious transfers as noted [here](./2023-11-09-secure-mpc.md#ot-for-computing-14.-secure-multiparty-computation#ot-for-computing-$2$-ary-function-with-finite-domain$-ary-function-with-finite-domain). However, this method is inefficient. We will look at **Yao's protocol**, presented in 1986, for secure two-party computation.
|
A simple solution for two party computation would be to use oblivious transfers as noted [here](../2023-11-09-secure-mpc/#ot-for-computing-14.-secure-multiparty-computation#ot-for-computing-$2$-ary-function-with-finite-domain$-ary-function-with-finite-domain). However, this method is inefficient. We will look at **Yao's protocol**, presented in 1986, for secure two-party computation.
|
||||||
|
|
||||||
The term **garbled circuit** was used by Beaver-Micali-Rogaway (BMR), presenting a multiparty protocol using a similar approach to Yao's protocol.
|
The term **garbled circuit** was used by Beaver-Micali-Rogaway (BMR), presenting a multiparty protocol using a similar approach to Yao's protocol.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -13,12 +14,12 @@ title: 16. The GMW Protocol
|
|||||||
date: 2023-11-16
|
date: 2023-11-16
|
||||||
github_title: 2023-11-16-gmw-protocol
|
github_title: 2023-11-16-gmw-protocol
|
||||||
image:
|
image:
|
||||||
path: assets/img/posts/Lecture Notes/Modern Cryptography/mc-16-beaver-triple.png
|
path: assets/img/posts/lecture-notes/modern-cryptography/mc-16-beaver-triple.png
|
||||||
attachment:
|
attachment:
|
||||||
folder: assets/img/posts/Lecture Notes/Modern Cryptography
|
folder: assets/img/posts/lecture-notes/modern-cryptography
|
||||||
---
|
---
|
||||||
|
|
||||||
There are two types of MPC protocols, **generic** and **specific**. Generic protocols can compute arbitrary functions. [Garbled circuits](./2023-11-14-garbled-circuits.md#garbled-circuits) were generic protocols, since it can be used to compute any boolean circuits. In contrast, the [summation protocol](./2023-11-09-secure-mpc.md#example-secure-summation) is a specific protocol that can only be used to compute a specific function. Note that generic protocols are not necessarily better, since specific protocols are much more efficient.
|
There are two types of MPC protocols, **generic** and **specific**. Generic protocols can compute arbitrary functions. [Garbled circuits](../2023-11-14-garbled-circuits/#garbled-circuits) were generic protocols, since it can be used to compute any boolean circuits. In contrast, the [summation protocol](../2023-11-09-secure-mpc/#example-secure-summation) is a specific protocol that can only be used to compute a specific function. Note that generic protocols are not necessarily better, since specific protocols are much more efficient.
|
||||||
|
|
||||||
## GMW Protocol
|
## GMW Protocol
|
||||||
|
|
||||||
@@ -147,7 +148,7 @@ Indeed, $z_1, z_2$ are shares of $z$.[^2] See also Exercise 23.5.[^3]
|
|||||||
|
|
||||||
Now, in the actual computation of AND gates, proceed as follows.
|
Now, in the actual computation of AND gates, proceed as follows.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
> Each $P_i$ has a share of inputs $a_i, b_i$ and a Beaver triple $(x_i, y_i, z_i)$.
|
> Each $P_i$ has a share of inputs $a_i, b_i$ and a Beaver triple $(x_i, y_i, z_i)$.
|
||||||
> 1. Each $P_i$ computes $u_i = a_i + x_i$, $v_i = b_i + y_i$.
|
> 1. Each $P_i$ computes $u_i = a_i + x_i$, $v_i = b_i + y_i$.
|
||||||
@@ -192,7 +193,7 @@ Also note that $u_i, v_i$ does not reveal any information about $x_i, y_i$. Esse
|
|||||||
|
|
||||||
**Beaver triples are to be used only once!** If $u_1 = a_1 + x_1$ and $u_1' = a_1' + x_1$, then $u_1 + u_1' = a_1 + a_1'$, revealing information about $a_1 + a_1'$.
|
**Beaver triples are to be used only once!** If $u_1 = a_1 + x_1$ and $u_1' = a_1' + x_1$, then $u_1 + u_1' = a_1 + a_1'$, revealing information about $a_1 + a_1'$.
|
||||||
|
|
||||||
Thus, before the online phase, a huge amount of Beaver triples are shared to speed up the computation. This can be done efficiently using [OT extension](2023-11-16-gmw-protocol.md#ot-extension) described below.
|
Thus, before the online phase, a huge amount of Beaver triples are shared to speed up the computation. This can be done efficiently using [OT extension](../2023-11-16-gmw-protocol/#ot-extension) described below.
|
||||||
|
|
||||||
## Comparison of Yao and GMW
|
## Comparison of Yao and GMW
|
||||||
|
|
||||||
@@ -280,7 +281,7 @@ As for the receiver, the values $(x_j^0, x_j^1)$ are masked by a hash function,
|
|||||||
|
|
||||||
The extension technique allows us to run $n$ base OT instances to obtain $m$ OT instances. For each of the $m$ OT transfers, only a few hash operations are required, resulting in very efficient OT.
|
The extension technique allows us to run $n$ base OT instances to obtain $m$ OT instances. For each of the $m$ OT transfers, only a few hash operations are required, resulting in very efficient OT.
|
||||||
|
|
||||||
One may concern that we have to send a lot of information for each of the $n$ OT instances, since we have to send $m$ bit data for each OT. But this of not much concern. For example, if we used [OT based on ElGamal](./2023-11-09-secure-mpc.md#1-out-of-2-ot-construction-from-elgamal-encryption), we can choose primes large enough $> 2^m$ to handle $m$-bit data.
|
One may concern that we have to send a lot of information for each of the $n$ OT instances, since we have to send $m$ bit data for each OT. But this of not much concern. For example, if we used [OT based on ElGamal](../2023-11-09-secure-mpc/#1-out-of-2-ot-construction-from-elgamal-encryption), we can choose primes large enough $> 2^m$ to handle $m$-bit data.
|
||||||
|
|
||||||
Hence, with OT extensions, we can perform millions of OTs efficiently, which can be used especially for computing many Beaver triples during preprocessing.
|
Hence, with OT extensions, we can perform millions of OTs efficiently, which can be used especially for computing many Beaver triples during preprocessing.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -511,7 +512,7 @@ $$
|
|||||||
N^{L+1} \ra N^L \ra \cdots \ra N.
|
N^{L+1} \ra N^L \ra \cdots \ra N.
|
||||||
$$
|
$$
|
||||||
|
|
||||||
When we perform $L$ levels of computation and reach modulus $q_0 = N$, we cannot perform any multiplications. We must apply [bootstrapping](./2023-12-08-bootstrapping-ckks.md#bootstrapping).
|
When we perform $L$ levels of computation and reach modulus $q_0 = N$, we cannot perform any multiplications. We must apply [bootstrapping](../2023-12-08-bootstrapping-ckks/#bootstrapping).
|
||||||
|
|
||||||
Note that without modulus switching, we need $q_L > N^{2^L}$ for $L$ levels of computation, which is very large. Since we want $q$ to be small (for the hardness of the LWE problem), modulus switching is necessary. We now only require $q_L > N^{L+1}$.
|
Note that without modulus switching, we need $q_L > N^{2^L}$ for $L$ levels of computation, which is very large. Since we want $q$ to be small (for the hardness of the LWE problem), modulus switching is necessary. We now only require $q_L > N^{L+1}$.
|
||||||
|
|
||||||
@@ -5,6 +5,7 @@ math: true
|
|||||||
categories:
|
categories:
|
||||||
- Lecture Notes
|
- Lecture Notes
|
||||||
- Modern Cryptography
|
- Modern Cryptography
|
||||||
|
path: _posts/lecture-notes/modern-cryptography
|
||||||
tags:
|
tags:
|
||||||
- lecture-note
|
- lecture-note
|
||||||
- cryptography
|
- cryptography
|
||||||
@@ -116,7 +117,7 @@ Designing an FHE scheme without the circular security assumption is currently an
|
|||||||
|
|
||||||
## CKKS Scheme
|
## CKKS Scheme
|
||||||
|
|
||||||
The [BGV scheme](./2023-11-23-bgv-scheme.md#the-bgv-scheme) operates on $\Z_p$, so it doesn't work on real numbers. **Cheon-Kim-Kim-Song** (CKKS) scheme works on real numbers using approximate computation.
|
The [BGV scheme](../2023-11-23-bgv-scheme/#the-bgv-scheme) operates on $\Z_p$, so it doesn't work on real numbers. **Cheon-Kim-Kim-Song** (CKKS) scheme works on real numbers using approximate computation.
|
||||||
|
|
||||||
### Approximate Computation
|
### Approximate Computation
|
||||||
|
|
||||||
@@ -208,7 +209,7 @@ so the decryption results in $\Delta\inv \cdot (\mu + \mu') \approx m + m'$.
|
|||||||
|
|
||||||
### Multiplication in CKKS
|
### Multiplication in CKKS
|
||||||
|
|
||||||
We also use [tensor products](./2023-11-23-bgv-scheme.md#tensor-product), and their properties.
|
We also use [tensor products](../2023-11-23-bgv-scheme/#tensor-product), and their properties.
|
||||||
|
|
||||||
> Let $\bf{c} = (b, \bf{a})$ and $\bf{c}' = (b', \bf{a}')$ be encryptions of $m, m' \in \R$. Then,
|
> Let $\bf{c} = (b, \bf{a})$ and $\bf{c}' = (b', \bf{a}')$ be encryptions of $m, m' \in \R$. Then,
|
||||||
>
|
>
|
||||||
@@ -243,7 +244,7 @@ We have issues with multiplication, as we did in BGV.
|
|||||||
|
|
||||||
### Dimension Reduction
|
### Dimension Reduction
|
||||||
|
|
||||||
The relinearization procedure is almost the same as in [BGV relinearization](./2023-11-23-bgv-scheme.md#relinearization).
|
The relinearization procedure is almost the same as in [BGV relinearization](../2023-11-23-bgv-scheme/#relinearization).
|
||||||
|
|
||||||
For convenience, let $a_{i, j} = a_i a_j'$.
|
For convenience, let $a_{i, j} = a_i a_j'$.
|
||||||
|
|
||||||
@@ -287,7 +288,7 @@ Note that the proof is identical to that of BGV linearization, except for missin
|
|||||||
|
|
||||||
### Scaling Factor Reduction
|
### Scaling Factor Reduction
|
||||||
|
|
||||||
In BGV, we used modulus switching for [noise reduction](./2023-11-23-bgv-scheme.md#noise-reduction). It was for reducing the error and preserving the message. We also use modulus switching here, but for a different purpose. The message can have small numerical errors, we just want to reduce the scaling factor. This operation is called **rescaling**.
|
In BGV, we used modulus switching for [noise reduction](../2023-11-23-bgv-scheme/#noise-reduction). It was for reducing the error and preserving the message. We also use modulus switching here, but for a different purpose. The message can have small numerical errors, we just want to reduce the scaling factor. This operation is called **rescaling**.
|
||||||
|
|
||||||
Given $\bf{c} = (b, \bf{a}) \in \Z_q^{n+1}$ such that $b + \span{\bf{a}, \bf{s}} = \mu \pmod q$ and $\mu \approx \Delta^2 \cdot m$, we want to generate a new ciphertext of $m' \approx m$ that has a scaling factor reduced to $\Delta$. This can be done by dividing the ciphertext by $\Delta$ and then rounding it appropriately.
|
Given $\bf{c} = (b, \bf{a}) \in \Z_q^{n+1}$ such that $b + \span{\bf{a}, \bf{s}} = \mu \pmod q$ and $\mu \approx \Delta^2 \cdot m$, we want to generate a new ciphertext of $m' \approx m$ that has a scaling factor reduced to $\Delta$. This can be done by dividing the ciphertext by $\Delta$ and then rounding it appropriately.
|
||||||
|
|
||||||
@@ -329,7 +330,7 @@ $$
|
|||||||
\Delta^{L+1} \ra \Delta^L \ra \cdots \ra \Delta.
|
\Delta^{L+1} \ra \Delta^L \ra \cdots \ra \Delta.
|
||||||
$$
|
$$
|
||||||
|
|
||||||
When we reach $q_0 = \Delta$, we cannot perform any multiplications, so we apply [bootstrapping](2023-12-08-bootstrapping-ckks.md#bootstrapping) here.
|
When we reach $q_0 = \Delta$, we cannot perform any multiplications, so we apply [bootstrapping](../2023-12-08-bootstrapping-ckks/#bootstrapping) here.
|
||||||
|
|
||||||
### Multiplication in CKKS (Summary)
|
### Multiplication in CKKS (Summary)
|
||||||
|
|
||||||
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 9.5 KiB After Width: | Height: | Size: 9.5 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 270 KiB After Width: | Height: | Size: 270 KiB |
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 47 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 7.8 KiB After Width: | Height: | Size: 7.8 KiB |
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 7.0 KiB After Width: | Height: | Size: 7.0 KiB |
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 6.4 KiB After Width: | Height: | Size: 6.4 KiB |
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
Before Width: | Height: | Size: 6.0 KiB After Width: | Height: | Size: 6.0 KiB |
|
Before Width: | Height: | Size: 8.8 KiB After Width: | Height: | Size: 8.8 KiB |
|
Before Width: | Height: | Size: 8.1 KiB After Width: | Height: | Size: 8.1 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 9.3 KiB After Width: | Height: | Size: 9.3 KiB |
|
Before Width: | Height: | Size: 9.7 KiB After Width: | Height: | Size: 9.7 KiB |
|
Before Width: | Height: | Size: 153 KiB After Width: | Height: | Size: 153 KiB |
|
Before Width: | Height: | Size: 81 KiB After Width: | Height: | Size: 81 KiB |
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
|
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 68 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 68 KiB |
|
Before Width: | Height: | Size: 65 KiB After Width: | Height: | Size: 65 KiB |
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 47 KiB |