20210528
REF
[1]"https://youtu.be/_160oMzblY8" ★★★★★
[2] "https://www.youtube.com/watch?v=Y6GGzzKm2Ig "
[3] "https://www.youtube.com/watch?v=YEBfamv-_do" Public key cryptography - Diffie-Hellman Key Exchange (full version) ★
[4] "https://www.youtube.com/watch?v=TmA2QWSLSPg "
[5] "https://www.youtube.com/watch?v=GSTiKjnBaes "
[6] "https://www.youtube.com/watch?v=AQDCe585Lnc "
01 해시
SHA256 = 모든 입력을 Random한 256자리 2진수로 바꾸어 준다.
01 블록, 해시
비트코인은 블록의 정보를 해싱해서 나오는 결과값이 특정 조건을 만족하도록 요구한다. 이 조건을 조정해서 블록생성하는데 걸리는 시간을 조정한다.(쉽게 블록을 생성할 수 없게 한다)
01 Nones 논스 [1]
Number which is used only ONE time
하나의 블록에 들어 있는 정보는 임의로 정할수 없다(자유도 0)..순번, 거래내역(금액, 준 사람, 받은 사람) 등.
따라서 이 정보로만 해쉬를 만들면 자유도가 0이다. 즉 내가 원하는대로(또는 특정 조건에 맞는) 해시를 만들 수 없다.
따라서 특정 조건을 만족하는 해시를 만들기 위해 조정하는 부분이 '넌스'이다
02 블록체인에 사용된 두 가지 기술 [2]
Hashing & Digital Signature |
1/ 거래의 두 가지 위험 : 금전거래의 두 가지 사기 방법
① 현재 이 사람이 정당한 돈의 소유자인지,
② 기록된 거래가 변조될 수 없는지..
2/ Digital Signature : 현재의 위험
-- 권한이 있는 자가 돈을 사용할 수 있도록 보장
-- Digital Signature를 이용하면서 생기는 Bitcoint Wallet의 재밌는 현상 [5]
** 계좌번호(public key)를 블록체인에 등록하는 게 아니다. Private key를 종이에 적어서 "물리적"으로 선물 할 수도 있다.
3/ Hashing : 과거의 위험 1
-- 그렇게 기록된 정보(과거)가 변경될 수 없도록 stopping
04 데이터의 암호화 : Asymmetric Key [6]
1/ 보통의 자물쇠는 잠근 열쇠로 열 수 있다. 즉 잠그는 열쇠와 푸는 열쇠가 같다.
-- 예) zip 파일을 암호화 할 때
-- 혼자 파일을 잠그고 푼다면 OK. 하지만 잠그는 사람과 여는 사람이 다르다면, 게다가 두 사람이 미리 만날 수 없다면?
-- 예) 물건을 사기 위해 카드번호를 온라인 판매자에 보내야 한다면.. 2
2/ 비대칭키
잠그는 열쇠와 푸는 열쇠가 다르다면...
온라인 판매자는 잠그는 열쇠를 아무데나 뿌리고 다닌다.
구매자는 잠그는 열쇠를 이용해서 카드번호를 잠근다. 그리고 그것을 판매자에게 보낸다.
-- 중간에 해커가 이 파일을 낚아채도 열어 볼 수가 없다.
판매자는 이 파일을 받아서, 본인의 푸는 열쇠로 이를 푼다.
Public Key로 잠그고, Private Key로 연다. |
⭐📎🟢🌈🏛⭕더 좋은 설명
갑은 "자물쇠"를 공공장소에 뿌린다. 3
을은 편지를 써서 상자에 담고 그 자물쇠로 잠근다.
상자를 갑에게 보낸다.
3/ 구현 방법 [3]
-- Diffie-Hellman ; Discrete Logarithm <-> Discrete Exponential
-- RSA
05 디지털 서명
1/ Asymmetric Key의 "비대칭성을 이용"해서 본인 증명에도 사용할 수 있다. 단, 암호화 때와 열쇠의 방향이 반대다.
Private Key로 잠그고, Public Key로 연다! |
1/ 디지털 서명도 Hash와 Asymmetric Key를 동시에 사용한다( ⇒ Blockchain도 그러네!!) [4] 4
(A가 서류를 작성해서 B에게 제출하는 경우를 가정해보자)
2/ A는 서류(it's just data, plain text) 작성하고, 그것을 입력해서 해시를 만든다. That's called "Digest"
3/ A는 Digest를 Private Key로 암호화 한다. 이 두 개를 B에게 보낸다.
4/ B는 A의 서류를 해시한다. then B have the Digest
5/ B는 A의 Public Key로 암호화 된 Digest를 복호화 한다.
6/ 두 Digest(위 4, 5)가 일치하면 A가 작성한 문서가 맞다(위조, 변도 되지 않았다.)
(note) 당연하지만, A의 Private Key를 A만 가지고 있어야 한다.
06 응용, 디지털 서명
회사에서 서류에 결재를 하는 경우를 생각해보자.
(개인의 서명감 등록)
1/ 사원들은 개인암호를 만든다. 사원들은 이 암호를 이용해서 public key를 만든다. 그리고..
2/ 만들어진 public key를 회사(문서팀)에서 보관한다.
(문서의 결재)
1/ 갑이 문서를 만들고, 사인을 한다(문서의 해시를 만들고 해시를 암호화 한다). 5
2/ 문서팀은 이를 검증한다(문서의 해시를 만들고, 문서에 첨부된 Digest를 복호화해서 비교).
(활용)
1/ 나중에 대출이 부도가 나면 갑에게 책임을 묻는다.
2/ 갑은 자신이 서명하지 않았다고 발뺌한다.
3/ 문서팀은 갑 이외의 사람이 서명할 수 없음을 증명한다.
(문제1) 문서팀에서 갑이 실제로 서명하지 않았는데 서명한 것으로 위조할 수 있는가?
-- 갑이 제출한 "암호화된 Digest"는 갑만이 만들 수 있다. 문서팀에서 가진 Public Key는 복호화만 가능하다.
-- 만약 다른 사람이 다른private key로 Digest를 암호화했다면, 문서팀에서 갑의 public key로 복호화했을때 엉뚱한 Digest 6가 나왔을 것이다. 7
(문제2)문서 자체를 암호화하지않고 왜 문서를 해시해서 Digest를 만든 다음 Digest를 암호화하는 것일까?
(Digest는 필수과정이 아닌 것 같은데...?)
(이유1) 문서를 직접 암호화하면, 문서를 볼때마다 매번 복호화를 해야해서 번거럽다.
이런 번거로움 보다 더 치명적인 이유는..
(이유2) ★ 만약 엉뚱한 Public Key로 문서를 복호화했을 때, 우연히 "을이 책임진다"는 내용으로 복호화될 수도 있는데, 이 경우 이 내용이 원본과 같지 않음에도 불구하고 갑이 원본과 같다고 주장할 수 있다.
'이유2'에 대한 반박 : "엉뚱한 Public Key"를 가정하면 안된다. 문서팀은 정당한 Public Key를 가지고 있다는 전제가 필요하다. ⇒ ★★★★★ 좀더 강력한 이유가 없나?
- 과거 거래 변조를 방지하기 위해서는 Hashing과 함께 원장의 공유 distribution, 다수결 원칙, 작업증명 등의 추가적 방법이 필요하다. [본문으로]
- 판매자는 믿을 수 있는 사람이라고 가정하자. [본문으로]
- 자물쇠가 있는데 잠그는 열쇠와 여는 열쇠가 다르다고 생각하는 것 보다는 공개키를 자물쇠로 바꾸는게 더 이해하기 쉬울 것같다. [본문으로]
그런데 Hash는 필수 사항은 아닌 것 같다. 아래의 "06.문제2"를 참고[본문으로]- 예를 들어 만약 이 대출이 부도나면 내가 책임진다는 내용. [본문으로]
- 갑의 private key가 아닌 [본문으로]
- 원래 Digest가 아닌 [본문으로]