Compare commits

...

21 Commits

Author SHA1 Message Date
78691732a8 build: remove toc-status 2024-11-12 23:07:58 +09:00
de3c6a1d4e build: fix build failure 2024-11-12 23:05:39 +09:00
b8d0068e6d chore: update layouts 2024-11-12 22:56:23 +09:00
746023e0b7 build: disable internal hash check 2024-11-12 22:47:28 +09:00
c446506f4a chore: fix all broken links 2024-11-12 22:47:01 +09:00
e1b1ec6fc5 [PUBLISHER] upload files #169 2024-11-12 22:42:25 +09:00
7a6e58dac5 chore: Pull-Request [calofmijuck-11-12-2024] from Obsidian (#168)
* PUSH NOTE : 02. Symmetric Key Cryptography (1).md

* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-09-07-otp-stream-cipher-prgs.md
2024-11-12 22:34:21 +09:00
4f013805b5 [PUBLISHER] upload files #167
* PUSH NOTE : 02. Symmetric Key Cryptography (1).md

* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-09-07-otp-stream-cipher-prgs.md
2024-11-12 22:22:40 +09:00
6d574c1004 [PUBLISHER] upload files #166
* PUSH NOTE : 02. Symmetric Key Cryptography (1).md

* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-09-07-otp-stream-cipher-prgs.md
2024-11-12 22:20:03 +09:00
a6ab9d49fd [PUBLISHER] upload files #165
* PUSH NOTE : 02. Symmetric Key Cryptography (1).md

* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-09-11-symmetric-key-cryptography-1/2023-09-11-symmetric-key-cryptography-1.md

* DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-07-otp-stream-cipher-prgs/2023-09-07-otp-stream-cipher-prgs.md
2024-11-12 22:01:32 +09:00
0d6dc88470 [PUBLISHER] upload files #164
* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-07-otp-stream-cipher-prgs/2023-09-07-otp-stream-cipher-prgs.md
2024-11-12 22:01:19 +09:00
f394e395b0 [PUBLISHER] upload files #163
* PUSH NOTE : 02. Symmetric Key Cryptography (1).md

* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-09-11-symmetric-key-cryptography-1.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-09-11-symmetric-key-cryptography-1/2023-09-07-otp-stream-cipher-prgs.md
2024-11-12 21:43:41 +09:00
b5e3a4a3b2 [PUBLISHER] upload files #162
* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* PUSH ATTACHMENT : mc-01-prg-game.png

* PUSH ATTACHMENT : mc-01-ss.png

* DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-07-otp-stream-cipher-prgs/mc-01-prg-game.png

* DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-07-otp-stream-cipher-prgs/mc-01-ss.png
2024-11-12 21:40:58 +09:00
25f93569b0 [PUBLISHER] upload files #161
* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* PUSH ATTACHMENT : mc-01-prg-game.png

* PUSH ATTACHMENT : mc-01-ss.png

* DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-07-otp-stream-cipher-prgs.md

* DELETE FILE : assets/img/posts/lecture-notes/modern-cryptography/mc-01-prg-game.png

* DELETE FILE : assets/img/posts/lecture-notes/modern-cryptography/mc-01-ss.png
2024-11-12 21:35:08 +09:00
6b769209bd [PUBLISHER] upload files #160
* PUSH NOTE : 09. Transport Layer Security.md

* PUSH NOTE : 03. Symmetric Key Cryptography (2).md

* PUSH NOTE : 5. CCA-Security and Authenticated Encryption.md

* PUSH NOTE : 3. Symmetric Key Encryption.md

* PUSH NOTE : 6. Hash Functions.md

* PUSH NOTE : 7. Key Exchange.md

* PUSH NOTE : 4. Message Authentication Codes.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-09-26-cca-security-authenticated-encryption.md
2024-11-12 20:56:06 +09:00
307bb79179 [PUBLISHER] upload files #159
* PUSH NOTE : 09. Transport Layer Security.md

* PUSH ATTACHMENT : is-09-tls-handshake.png

* PUSH NOTE : 08. Public Key Infrastructure.md

* PUSH ATTACHMENT : is-08-certificate-validation.png

* PUSH NOTE : 07. Public Key Cryptography.md

* PUSH NOTE : 06. RSA and ElGamal Encryption.md

* PUSH NOTE : 05. Modular Arithmetic (2).md

* PUSH NOTE : 04. Modular Arithmetic (1).md

* PUSH NOTE : 03. Symmetric Key Cryptography (2).md

* PUSH ATTACHMENT : is-03-feistel-function.png

* PUSH ATTACHMENT : is-03-ecb-encryption.png

* PUSH ATTACHMENT : is-03-cbc-encryption.png

* PUSH ATTACHMENT : is-03-cfb-encryption.png

* PUSH ATTACHMENT : is-03-ofb-encryption.png

* PUSH ATTACHMENT : is-03-ctr-encryption.png

* PUSH NOTE : 02. Symmetric Key Cryptography (1).md

* PUSH NOTE : 01. Security Introduction.md

* PUSH ATTACHMENT : is-01-cryptosystem.png

* PUSH NOTE : 9. Public Key Encryption.md

* PUSH ATTACHMENT : mc-09-ss-pke.png

* PUSH NOTE : 7. Key Exchange.md

* PUSH ATTACHMENT : mc-07-dhke.png

* PUSH ATTACHMENT : mc-07-dhke-mitm.png

* PUSH ATTACHMENT : mc-07-merkle-puzzles.png

* PUSH NOTE : 6. Hash Functions.md

* PUSH ATTACHMENT : mc-06-merkle-damgard.png

* PUSH ATTACHMENT : mc-06-davies-meyer.png

* PUSH ATTACHMENT : mc-06-hmac.png

* PUSH NOTE : 5. CCA-Security and Authenticated Encryption.md

* PUSH ATTACHMENT : mc-05-ci.png

* PUSH ATTACHMENT : mc-05-etm-mte.png

* PUSH NOTE : 4. Message Authentication Codes.md

* PUSH ATTACHMENT : mc-04-mac.png

* PUSH ATTACHMENT : mc-04-mac-security.png

* PUSH ATTACHMENT : mc-04-cbc-mac.png

* PUSH ATTACHMENT : mc-04-ecbc-mac.png

* PUSH NOTE : 2. PRFs, PRPs and Block Ciphers.md

* PUSH ATTACHMENT : mc-02-block-cipher.png

* PUSH ATTACHMENT : mc-02-feistel-network.png

* PUSH ATTACHMENT : mc-02-des-round.png

* PUSH ATTACHMENT : mc-02-DES.png

* PUSH ATTACHMENT : mc-02-aes-128.png

* PUSH ATTACHMENT : mc-02-2des-mitm.png

* PUSH NOTE : 16. The GMW Protocol.md

* PUSH ATTACHMENT : mc-16-beaver-triple.png

* PUSH NOTE : 13. Sigma Protocols.md

* PUSH ATTACHMENT : mc-13-sigma-protocol.png

* PUSH ATTACHMENT : mc-10-schnorr-identification.png

* PUSH ATTACHMENT : mc-13-okamoto.png

* PUSH ATTACHMENT : mc-13-chaum-pedersen.png

* PUSH ATTACHMENT : mc-13-gq-protocol.png

* PUSH NOTE : 12. Zero-Knowledge Proofs (Introduction).md

* PUSH ATTACHMENT : mc-12-id-protocol.png

* PUSH NOTE : 10. Digital Signatures.md

* PUSH ATTACHMENT : mc-10-dsig-security.png

* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* PUSH ATTACHMENT : mc-01-prg-game.png

* PUSH ATTACHMENT : mc-01-ss.png

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-10-security-intro.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-11-symmetric-key-cryptography-1.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-18-symmetric-key-cryptography-2.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-09-25-modular-arithmetic-1.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-04-modular-arithmetic-2.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-04-rsa-elgamal.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-09-public-key-cryptography.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-16-pki.md

* DELETE FILE : _posts/Lecture Notes/Internet Security/2023-10-18-tls.md

* DELETE FILE : _posts/lecture-notes/internet-security/2023-10-19-public-key-encryption.md

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-01-cryptosystem.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-cbc-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-cfb-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-ctr-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-ecb-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-feistel-function.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-03-ofb-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-08-certificate-validation.png

* DELETE FILE : assets/img/posts/Lecture Notes/Internet Security/is-09-tls-handshake.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-01-prg-game.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-01-ss.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-2des-mitm.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-DES.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-aes-128.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-block-cipher.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-des-round.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-02-feistel-network.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-cbc-mac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-ecbc-mac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-mac-security.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-04-mac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-05-ci.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-05-etm-mte.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-davies-meyer.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-hmac.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-06-merkle-damgard.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-dhke-mitm.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-dhke.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-07-merkle-puzzles.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-09-ss-pke.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-10-dsig-security.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-10-schnorr-identification.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-12-id-protocol.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-chaum-pedersen.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-gq-protocol.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-okamoto.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-13-sigma-protocol.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/mc-16-beaver-triple.png
2024-11-12 20:54:38 +09:00
187179afaf [PUBLISHER] upload files #158
* PUSH NOTE : 9. Public Key Encryption.md

* PUSH NOTE : 3. Symmetric Key Encryption.md

* PUSH ATTACHMENT : is-03-ecb-encryption.png

* PUSH ATTACHMENT : is-03-cbc-encryption.png

* PUSH ATTACHMENT : is-03-ctr-encryption.png

* PUSH NOTE : 03. Symmetric Key Cryptography (2).md

* PUSH NOTE : 5. CCA-Security and Authenticated Encryption.md

* DELETE FILE : _posts/lecture-notes/modern-cryptography/2023-09-18-symmetric-key-cryptography-2.md

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/is-03-cbc-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/is-03-ctr-encryption.png

* DELETE FILE : assets/img/posts/Lecture Notes/Modern Cryptography/is-03-ecb-encryption.png
2024-11-12 20:44:37 +09:00
eeba575c28 chore: Delete lecture-notes/modern-cryptography directory 2024-11-12 20:42:44 +09:00
68fcbab46c [PUBLISHER] upload files #157
* PUSH NOTE : 9. Public Key Encryption.md

* PUSH NOTE : 8. Number Theory.md

* PUSH NOTE : 7. Key Exchange.md

* PUSH NOTE : 6. Hash Functions.md

* PUSH NOTE : 5. CCA-Security and Authenticated Encryption.md

* PUSH NOTE : 4. Message Authentication Codes.md

* PUSH NOTE : 3. Symmetric Key Encryption.md

* PUSH NOTE : 2. PRFs, PRPs and Block Ciphers.md

* PUSH NOTE : 18. Bootstrapping & CKKS.md

* PUSH NOTE : 17. BGV Scheme.md

* PUSH NOTE : 16. The GMW Protocol.md

* PUSH NOTE : 15. Garbled Circuits.md

* PUSH NOTE : 14. Secure Multiparty Computation.md

* PUSH NOTE : 13. Sigma Protocols.md

* PUSH NOTE : 12. Zero-Knowledge Proofs (Introduction).md

* PUSH NOTE : 11. Advanced Topics.md

* PUSH NOTE : 10. Digital Signatures.md

* PUSH NOTE : 0. Introduction.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-05-introduction.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-12-prfs-prps-block-ciphers.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-19-symmetric-key-encryption.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-21-macs.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-26-cca-security-authenticated-encryption.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-28-hash-functions.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-10-03-key-exchange.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-10-05-number-theory.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-10-19-public-key-encryption.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-10-26-digital-signatures.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-10-31-advanced-topics.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-11-02-zkp-intro.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-11-07-sigma-protocols.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-11-09-secure-mpc.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-11-14-garbled-circuits.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-11-16-gmw-protocol.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-11-23-bgv-scheme.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-12-08-bootstrapping-ckks.md
2024-11-12 20:41:08 +09:00
d55c927a9d [PUBLISHER] upload files #156 2024-11-12 20:36:57 +09:00
b606549af6 [PUBLISHER] upload files #155
* PUSH NOTE : 1. OTP, Stream Ciphers and PRGs.md

* DELETE FILE : _posts/Lecture Notes/Modern Cryptography/2023-09-07-otp-stream-cipher-prgs.md

* DELETE FILE : _posts/You and Your Research, Richard Hamming.md
2024-11-12 20:34:26 +09:00
71 changed files with 249 additions and 270 deletions

View File

@@ -54,7 +54,8 @@ jobs:
run: |
bundle exec htmlproofer _site \
\-\-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
uses: actions/upload-pages-artifact@v3

View File

@@ -2,17 +2,10 @@
<!-- commons -->
{% assign urls = site.data.origin[type].jquery.js
| append: ','
| append: site.data.origin[type].bootstrap.js
| append: ','
| append: site.data.origin[type].search.js
%}
{% assign urls = site.data.origin[type].search.js %}
<!-- layout specified -->
{% assign js_dist = '/assets/js/dist/' %}
{% if page.layout == 'post' or page.layout == 'page' or page.layout == 'home' %}
{% assign urls = urls | append: ',' | append: site.data.origin[type]['lazy-polyfill'].js %}
@@ -20,7 +13,7 @@
<!-- image lazy-loading & popup & clipboard -->
{% assign urls = urls
| append: ','
| append: site.data.origin[type]['magnific-popup'].js
| append: site.data.origin[type].glightbox.js
| append: ','
| append: site.data.origin[type].clipboard.js
%}
@@ -33,7 +26,7 @@
or page.layout == 'category'
or page.layout == 'tag'
%}
{% assign locale = site.lang | split: '-' | first %}
{% assign locale = include.lang | split: '-' | first %}
{% assign urls = urls
| append: ','
@@ -67,11 +60,13 @@
{% assign js = 'commons' %}
{% endcase %}
{% capture script %}{{ js_dist }}{{ js }}.min.js{% endcapture %}
<script defer src="{{ script | relative_url }}"></script>
{% capture script %}/assets/js/dist/{{ js }}.min.js{% endcapture %}
<script src="{{ script | relative_url }}"></script>
{% if page.math %}
<!-- MathJax -->
<script src="{{ '/assets/js/data/mathjax.js' | relative_url }}"></script>
<script>
/* see: <https://docs.mathjax.org/en/latest/options/input/tex.html#tex-options> */
MathJax = {
@@ -148,7 +143,7 @@
}
};
</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>
{% endif %}
@@ -166,10 +161,17 @@
{% endif %}
{% endif %}
{% if page.mermaid %}
{% include mermaid.html %}
{% endif %}
{% if jekyll.environment == 'production' %}
<!-- PWA -->
{% 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: '' }}&register={{ site.pwa.cache.enabled }}"
></script>
{% endif %}
<!-- Web Analytics -->

View File

@@ -11,7 +11,7 @@ tail_includes:
{% include lang.html %}
<article class="px-1">
<article class="px-1" data-toc="{{ enable_toc }}">
<header>
<h1 data-toc-skip>{{ page.title }}</h1>
{% if page.description %}
@@ -75,6 +75,45 @@ tail_includes:
</div>
</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="post-tail-wrapper text-muted">

View File

@@ -2,11 +2,16 @@
share: true
toc: true
math: true
categories: [Mathematics, Coq]
tags: [math, coq, proof-verification]
title: "Rules of Inference with Coq"
date: "2023-07-08"
github_title: "2023-07-08-rules-of-inference"
categories:
- Mathematics
- Coq
tags:
- 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)
@@ -188,7 +193,7 @@ Lemma distributive_conjunction : forall P Q R : Prop,
Proof.
split; intros.
- 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.
Lemma material_implication_converse : forall P Q : Prop,

View File

@@ -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?*

View File

@@ -5,6 +5,7 @@ math: false
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- network
- security
@@ -13,9 +14,9 @@ title: 01. Security Introduction
date: 2023-09-10
github_title: 2023-09-10-security-intro
image:
path: /assets/img/posts/Lecture Notes/Internet Security/is-01-cryptosystem.png
attachment:
folder: assets/img/posts/Lecture Notes/Internet Security
path: /assets/img/posts/lecture-notes/internet-security/is-01-cryptosystem.png
attachment:
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
@@ -155,7 +156,7 @@ There are many ways of achieving security.
### Basics of a Cryptosystem
![is-01-cryptosystem.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-01-cryptosystem.png)
![is-01-cryptosystem.png](../../../assets/img/posts/lecture-notes/internet-security/is-01-cryptosystem.png)
- A **message** in *plaintext* is given to an **encryption algorithm**.
- The encryption algorithm uses an **encryption key** to create a *ciphertext*.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- security
- 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$.
- 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
> **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].
> $$
>
>
> 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]
> $$
>
>
> where $k$ is chosen uniformly in $\mathcal{K}$.
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$.
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

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- lecture-note
- security
@@ -13,9 +14,9 @@ title: 03. Symmetric Key Cryptography (2)
date: 2023-09-18
github_title: 2023-09-18-symmetric-key-cryptography-2
image:
path: /assets/img/posts/Lecture Notes/Internet Security/is-03-feistel-function.png
attachment:
folder: assets/img/posts/Lecture Notes/Internet Security
path: /assets/img/posts/lecture-notes/internet-security/is-03-feistel-function.png
attachment:
folder: assets/img/posts/lecture-notes/internet-security
---
## Block Cipher Overview
@@ -63,7 +64,7 @@ $$
#### The Feistel Function
![is-03-feistel-function.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-feistel-function.png)
![is-03-feistel-function.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-feistel-function.png)
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)
![is-03-ecb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ecb-encryption.png)
![is-03-ecb-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ecb-encryption.png)
- Codebook is a mapping table.
- 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)
![is-03-cbc-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cbc-encryption.png)
![is-03-cbc-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-cbc-encryption.png)
- Two identical messages produce to different ciphertexts.
- Two identical messages produce two different ciphertexts.
- This prevents chosen plaintext attacks
- Blocks are linked together in the encryption process
- **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**
- 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.
- Define Eve's new message $m' = \mathrm{IV} _ {\mathrm{E}} \oplus \mathrm{IV} _ {\mathrm{A}} \oplus g$, where
- $\mathrm{IV} _ \mathrm{A}$ and $\mathrm{IV} _ \mathrm{E}$ are Alice and Eve's IVs
- Suppose Eve obtains $(\mathrm{IV}_1, E_k(\mathrm{IV}_1 \oplus m))$.
- 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$.
- Since Eve can encrypt any message, $m'$ can be encrypted.
- $c' = E _ k(\mathrm{IV} _ \mathrm{E} \oplus m') = E _ k(\mathrm{IV} _ \mathrm{A} \oplus g)$.
- Then Eve can compare $c'$ and the original $c = E _ k(\mathrm{IV} _ \mathrm{A} \oplus m)$ to recover $m$.
- Eve requests an encryption of $m'$
- $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{1} \oplus m)$ to recover $m$.
- Useful when there are not many cases for $m$ (or most of the message is already known).
### Cipher Feedback Mode (CFB)
![is-03-cfb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-cfb-encryption.png)
![is-03-cfb-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-cfb-encryption.png)
- The message is treated as a stream of bits; similar to stream cipher
- **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)
![is-03-ofb-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ofb-encryption.png)
![is-03-ofb-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ofb-encryption.png)
- Very similar to stream cipher.
- 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)
![is-03-ctr-encryption.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-03-ctr-encryption.png)
![is-03-ctr-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ctr-encryption.png)
- Without chaining, we use a counter (typically incremented by $1$).
- Counter starts from the initialization vector.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- lecture-note
- security
@@ -20,7 +21,7 @@ github_title: 2023-09-25-modular-arithmetic-1
## Divisibility
> **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$.
> 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.
> **Lemma.** Let $a, b, c \in \mathbb{Z}$.
>
>
> 1. If $a \mid b$ and $a \mid c$, then $a \mid (b + c)$.
> 2. If $a \mid b$, then $a \mid bc$.
> 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.
> **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$.
> 2. $ac \equiv bd \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
> **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.
> $$
@@ -153,11 +154,11 @@ In $\mathbb{Z}_n$, the additive identity is $0$, the multiplicative identity is
### Inverse
> **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.
> $$
>
>
> We write $x = a^{-1}$.
In the language of modular arithmetic, $x$ is the inverse of $a$ if

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- lecture-note
- security

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- lecture-note
- 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
$$
\tag{$*$}
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.
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

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- lecture-note
- 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.
- *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.
- *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.
> 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
@@ -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$.
> - 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.
- 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.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- lecture-note
- security
@@ -12,7 +13,7 @@ title: 08. Public Key Infrastructure
date: 2023-10-16
github_title: 2023-10-16-pki
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?*
@@ -83,7 +84,7 @@ We have a root CA at the top. Then there are issuing CAs below. We usually reque
### Certificate Validation
![is-08-certificate-validation.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-08-certificate-validation.png)[^1]
![is-08-certificate-validation.png](../../../assets/img/posts/lecture-notes/internet-security/is-08-certificate-validation.png)[^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.
@@ -149,13 +150,13 @@ CRL checking is done in the following way.
> 2. The client queries the certificate revocation server and downloads CRLs.
> 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)
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.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Internet Security
path: _posts/lecture-notes/internet-security
tags:
- lecture-note
- security
@@ -12,9 +13,9 @@ title: 09. Transport Layer Security
date: 2023-10-18
github_title: 2023-10-18-tls
image:
path: /assets/img/posts/Lecture Notes/Internet Security/is-09-tls-handshake.png
attachment:
folder: assets/img/posts/Lecture Notes/Internet Security
path: /assets/img/posts/lecture-notes/internet-security/is-09-tls-handshake.png
attachment:
folder: assets/img/posts/lecture-notes/internet-security
---
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
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.
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
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).
@@ -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)$.
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.
@@ -113,7 +114,7 @@ $$
## 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
@@ -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.
> 4. Both parties generate a symmetric key from the shared secret.
![is-09-tls-handshake.png](/assets/img/posts/Lecture%20Notes/Internet%20Security/is-09-tls-handshake.png)[^1]
![is-09-tls-handshake.png](../../../assets/img/posts/lecture-notes/internet-security/is-09-tls-handshake.png)[^2]
- `ServerKeyExchange`, `ClientKeyExchange` is optional. Used sometimes if Diffie-Hellman is 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`?
- To provide greater consistency between TLS cipher suites.[^2]
- To provide greater consistency between TLS cipher suites.[^3]
## Version Rollback Attack (SSL)
@@ -252,9 +253,9 @@ These two protocols run over the record protocol.
### 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**.
- 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.
- The client sends $g^c \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
@@ -297,12 +298,13 @@ We previously had 2 round trips, but now we have one. The main difference is the
- **Client hello**
- 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 has client random, parameters and cipher suites.
- Using the server random, generate the master secret.
- **Server hello** and **Finished**
- 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.
- **Client 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.
- 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)
- 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.
@@ -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/).
[^1]: Source: [The SSL Store](https://www.thesslstore.com/blog/explaining-ssl-handshake/).
[^2]: Source: [Cryptography SE](https://crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls).
[^3]: Source: [Forward secrecy (Wikipedia)](https://en.wikipedia.org/wiki/Forward_secrecy).
[^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.
[^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: [The SSL Store](https://www.thesslstore.com/blog/explaining-ssl-handshake/).
[^3]: Source: [Cryptography SE](https://crypto.stackexchange.com/questions/24780/what-is-the-purpose-of-pre-master-secret-in-ssl-tls).
[^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.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- security

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,9 +14,9 @@ title: 1. One-Time Pad, Stream Ciphers and PRGs
date: 2023-09-07
github_title: 2023-09-07-otp-stream-cipher-prgs
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:
folder: assets/img/posts/Lecture Notes/Modern Cryptography
folder: assets/img/posts/lecture-notes/modern-cryptography
---
## 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.
> **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]
> $$
>
>
> 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.
@@ -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.
> **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]
> $$
>
>
> where the probability is taken over the random choice $k \leftarrow \mathcal{K}$.
> **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.
> **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.
> $$
@@ -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.
> **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
> $$
>
>
> 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.
@@ -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$.
> **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.
> $$
@@ -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.
![mc-01-prg-game.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-prg-game.png)
![mc-01-prg-game.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-01-prg-game.png)
1. The challenger PRG will send a bit string $x$ to $\mathcal{B}$.
- 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).
![mc-01-ss.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-01-ss.png)
![mc-01-ss.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-01-ss.png)
> **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$.
> 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.
> 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
>
>
> $$
> \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.
> **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$.**
> 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$.
>
>
> 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
> $$
>
>
> 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*.
@@ -421,7 +422,7 @@ $$
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
>
>
> $$
> \mathrm{Adv}_\mathrm{SS}[\mathcal{A}, \mathcal{E}] \leq 2 \cdot \mathrm{Adv}_\mathrm{PRG}[\mathcal{B}, G].
> $$

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,9 +14,9 @@ title: 2. PRFs, PRPs and Block Ciphers
date: 2023-09-12
github_title: 2023-09-12-prfs-prps-block-ciphers
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:
folder: assets/img/posts/Lecture Notes/Modern Cryptography
folder: assets/img/posts/lecture-notes/modern-cryptography
---
## 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.
![mc-02-block-cipher.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-block-cipher.png)
![mc-02-block-cipher.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-block-cipher.png)
Block ciphers commonly have the following form.
- 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}$?
![mc-02-feistel-network.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-feistel-network.png)
![mc-02-feistel-network.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-feistel-network.png)
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.
![mc-02-des-round.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-des-round.png)
![mc-02-des-round.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-des-round.png)
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.
![mc-02-DES.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-DES.png)
![mc-02-DES.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-DES.png)
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).
![mc-02-aes-128.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-aes-128.png)
![mc-02-aes-128.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-aes-128.png)
- DES key only had $56$ bits, so DES was broken in the 1990s
- 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)$.
![mc-02-2des-mitm.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-02-2des-mitm.png)
![mc-02-2des-mitm.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-02-2des-mitm.png)
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}$.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- 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**.
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)
![is-03-ecb-encryption.png](/assets/img/posts/is-03-ecb-encryption.png)
![is-03-ecb-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ecb-encryption.png)
- ECB mode encrypts each block with the same key.
- Blocks are independent of each other.
@@ -139,7 +140,7 @@ Additional explanation available in [Modes of Operations (Internet Security)](..
### Ciphertext Block Chain Mode (CBC)
![is-03-cbc-encryption.png](/assets/img/posts/is-03-cbc-encryption.png)
![is-03-cbc-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-cbc-encryption.png)
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)
![is-03-ctr-encryption.png](/assets/img/posts/is-03-ctr-encryption.png)
![is-03-ctr-encryption.png](../../../assets/img/posts/lecture-notes/internet-security/is-03-ctr-encryption.png)
Let $F : \mathcal{K} \times X \rightarrow X$ be a secure **PRF**.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,9 +14,9 @@ title: 4. Message Authentication Codes
date: 2023-09-21
github_title: 2023-09-21-macs
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:
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.
@@ -26,7 +27,7 @@ On the other hand, MAC fixes data that is tampered in purpose. We will also requ
## Message Authentication Code
![mc-04-mac.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-mac.png)
![mc-04-mac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-mac.png)
> **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.
![mc-04-mac-security.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-mac-security.png)
![mc-04-mac-security.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-mac-security.png)
> **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
![mc-04-cbc-mac.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-cbc-mac.png)
![mc-04-cbc-mac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-cbc-mac.png)
> **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.
![mc-04-ecbc-mac.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-04-ecbc-mac.png)
![mc-04-ecbc-mac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-04-ecbc-mac.png)
> **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.
>

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,9 +14,9 @@ title: 5. CCA-Security and Authenticated Encryption
date: 2023-09-26
github_title: 2023-09-26-cca-security-authenticated-encryption
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:
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.
@@ -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.
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.
@@ -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.
![mc-05-ci.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-ci.png)
![mc-05-ci.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-05-ci.png)
> **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.
![mc-05-etm-mte.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-05-etm-mte.png)
![mc-05-etm-mte.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-05-etm-mte.png)
### Encrypt-and-MAC (E&M)

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,9 +14,9 @@ title: 6. Hash Functions
date: 2023-09-28
github_title: 2023-09-28-hash-functions
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:
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**.
@@ -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.
![mc-06-merkle-damgard.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-merkle-damgard.png)
![mc-06-merkle-damgard.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-06-merkle-damgard.png)
> **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.
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).
![mc-06-davies-meyer.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-davies-meyer.png)
![mc-06-davies-meyer.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-06-davies-meyer.png)
> **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$.
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
@@ -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.
### HMAC
### HMAC Definition
![mc-06-hmac.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-06-hmac.png)
![mc-06-hmac.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-06-hmac.png)
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

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,9 +14,9 @@ title: 7. Key Exchange
date: 2023-10-03
github_title: 2023-10-03-key-exchange
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:
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.
@@ -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.
![mc-07-dhke.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke.png)
![mc-07-dhke.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-07-dhke.png)
> 1. Alice chooses $\alpha \leftarrow \mathbb{Z}_q$ and computes $g^\alpha$.
> 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.
![mc-07-dhke-mitm.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-dhke-mitm.png)
![mc-07-dhke-mitm.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-07-dhke-mitm.png)
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.
![mc-07-merkle-puzzles.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-07-merkle-puzzles.png)
![mc-07-merkle-puzzles.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-07-merkle-puzzles.png)
> 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$.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -15,7 +16,6 @@ date: 2023-10-05
github_title: 2023-10-05-number-theory
---
## Background
### Number Theory

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -18,7 +19,6 @@ attachment:
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.
## 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.
![mc-09-ss-pke.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-09-ss-pke.png)
![mc-09-ss-pke.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-09-ss-pke.png)
> **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
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.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,12 +14,11 @@ title: 10. Digital Signatures
date: 2023-10-26
github_title: 2023-10-26-digital-signatures
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:
folder: assets/img/posts/Lecture Notes/Modern Cryptography
folder: assets/img/posts/lecture-notes/modern-cryptography
---
## 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.
@@ -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**.
![mc-10-dsig-security.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-10-dsig-security.png)
![mc-10-dsig-security.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-10-dsig-security.png)
> **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$**.
![mc-10-schnorr-identification.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-10-schnorr-identification.png)
![mc-10-schnorr-identification.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-10-schnorr-identification.png)
The protocol $\mc{I}_\rm{sch} = (G, P, V)$ works as follows.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -14,7 +15,6 @@ date: 2023-10-31
github_title: 2023-10-31-advanced-topics
---
## Ciphertext Indistinguishability
- By **Shafi Goldwasser** and **Silvio Micali**

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,12 +14,11 @@ title: 12. Zero-Knowledge Proof (Introduction)
date: 2023-11-02
github_title: 2023-11-02-zkp-intro
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:
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.
- **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?
@@ -28,7 +28,7 @@ attachment:
## Identification Protocol
![mc-12-id-protocol.png](/assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-12-id-protocol.png)
![mc-12-id-protocol.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-12-id-protocol.png)
> **Definition.** An **identification protocol** is a triple of algorithms $\mc{I} = (G, P, V)$ satisfying the following.
>

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,12 +14,12 @@ title: 13. Sigma Protocols
date: 2023-11-07
github_title: 2023-11-07-sigma-protocols
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:
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
@@ -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$.
![mc-13-sigma-protocol.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-sigma-protocol.png)
![mc-13-sigma-protocol.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-sigma-protocol.png)
> **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 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.
![mc-10-schnorr-identification.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-10-schnorr-identification.png)
![mc-10-schnorr-identification.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-10-schnorr-identification.png)
> 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.
![mc-13-okamoto.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-okamoto.png)
![mc-13-okamoto.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-okamoto.png)
> 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$.
@@ -191,7 +192,7 @@ $$
goes as follows.
![mc-13-chaum-pedersen.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-chaum-pedersen.png)
![mc-13-chaum-pedersen.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-chaum-pedersen.png)
> 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$.
@@ -222,7 +223,7 @@ $$
goes as follows.
![mc-13-gq-protocol.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-13-gq-protocol.png)
![mc-13-gq-protocol.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-13-gq-protocol.png)
> 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$.
@@ -424,7 +425,7 @@ Omitted. Works...
### 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.
@@ -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.
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
@@ -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.
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*.
[^2]: A Graduate Course in Applied Cryptography.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -14,7 +15,7 @@ date: 2023-11-14
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.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -13,12 +14,12 @@ title: 16. The GMW Protocol
date: 2023-11-16
github_title: 2023-11-16-gmw-protocol
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:
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
@@ -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.
![mc-16-beaver-triple.png](../../../assets/img/posts/Lecture%20Notes/Modern%20Cryptography/mc-16-beaver-triple.png)
![mc-16-beaver-triple.png](../../../assets/img/posts/lecture-notes/modern-cryptography/mc-16-beaver-triple.png)
> 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$.
@@ -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'$.
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
@@ -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.
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.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -511,7 +512,7 @@ $$
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}$.

View File

@@ -5,6 +5,7 @@ math: true
categories:
- Lecture Notes
- Modern Cryptography
path: _posts/lecture-notes/modern-cryptography
tags:
- lecture-note
- cryptography
@@ -116,7 +117,7 @@ Designing an FHE scheme without the circular security assumption is currently an
## 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
@@ -208,7 +209,7 @@ so the decryption results in $\Delta\inv \cdot (\mu + \mu') \approx m + m'$.
### 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,
>
@@ -243,7 +244,7 @@ We have issues with multiplication, as we did in BGV.
### 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'$.
@@ -287,7 +288,7 @@ Note that the proof is identical to that of BGV linearization, except for missin
### 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.
@@ -329,7 +330,7 @@ $$
\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)

View File

Before

Width:  |  Height:  |  Size: 7.8 KiB

After

Width:  |  Height:  |  Size: 7.8 KiB

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

View File

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

View File

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

View File

Before

Width:  |  Height:  |  Size: 6.4 KiB

After

Width:  |  Height:  |  Size: 6.4 KiB

View File

Before

Width:  |  Height:  |  Size: 21 KiB

After

Width:  |  Height:  |  Size: 21 KiB

View File

Before

Width:  |  Height:  |  Size: 8.8 KiB

After

Width:  |  Height:  |  Size: 8.8 KiB

View File

Before

Width:  |  Height:  |  Size: 9.3 KiB

After

Width:  |  Height:  |  Size: 9.3 KiB

View File

Before

Width:  |  Height:  |  Size: 153 KiB

After

Width:  |  Height:  |  Size: 153 KiB

View File

Before

Width:  |  Height:  |  Size: 68 KiB

After

Width:  |  Height:  |  Size: 68 KiB