저장증명 편집하기
편집을 되돌릴 수 있습니다.
이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 저장해주세요.
| 최신판 | 당신의 편집 | ||
| 1번째 줄: | 1번째 줄: | ||
| − | + | '''저장증명'''(PoS; Proof of Storage)이란 증명자(prover)가 자신의 [[하드디스크]] 여유 공간에 [[데이터]]를 저장하고, 검증자(verifier)가 그것을 승인 또는 거절하는 방식으로 작동하는 [[합의 알고리즘]]이다. 이런 점에서 저장증명은 '''공간증명'''(Proof of Space)이라고도 한다. 저장증명은 [[용량증명]] 합의 알고리즘과 유사하다. | |
| − | |||
| − | '''저장증명'''(PoS; Proof of Storage)이란 증명자(prover)가 자신의 [[하드디스크]] 여유 공간에 [[데이터]]를 저장하고, 검증자(verifier)가 그것을 승인 또는 거절하는 방식으로 작동하는 [[합의 알고리즘]]이다. 이런 점에서 저장증명은 '''공간증명'''(Proof of Space)이라고도 한다. 저장증명은 [[용량증명]] 합의 알고리즘과 유사하다 | ||
==개요== | ==개요== | ||
| 17번째 줄: | 15번째 줄: | ||
논문의 핵심은, 서버가 M을 모르는 상태에서 Hash(M∥C)를 추측할 수는 없으므로, 서버가 M을 온전하게 저장하지도 않고 마치 저장한 척 클라이언트를 속일 수 없다는 것이다. 그러나 여기에는 함정이 있다. 현실적으로 해시는 입력을 [[블록]] 단위로 처리하면서 각 블록 사이의 중간 연쇄 값을 계산하는 반복 해시 함수일 것이다. 예를 들어 해시가 SHA-256이고, M이 512비트라고 하면 서버는 클라이언트를 속일 수 있다. 어떻게 그럴까? 서버는 M의 첫 512비트 블록 M₁과 SHA-256의 초기치 H₀을 이용해서 연쇄값 H₁=Compress(H₀, M₁)을 계산한다. 그런 다음에는 그 H₁을 메모리에 저장하고, M 자체는 폐기해 버린다. 그러면 서버는 더 이상 M을 저장한 상태가 아니다.<ref name="장필리프 오마송">장필리프 오마송, 〈[https://play.google.com/store/books/details?id=nNRmDwAAQBAJ&rdid=book-nNRmDwAAQBAJ&rdot=1&source=gbs_vpt_read&pcampaignid=books_booksearch_viewport 처음 배우는 암호화: 기초 수학부터 양자 컴퓨터 이후까지, 암호하그이 현재와 미래]〉, 《구글도서》, 2018-07-31</ref> | 논문의 핵심은, 서버가 M을 모르는 상태에서 Hash(M∥C)를 추측할 수는 없으므로, 서버가 M을 온전하게 저장하지도 않고 마치 저장한 척 클라이언트를 속일 수 없다는 것이다. 그러나 여기에는 함정이 있다. 현실적으로 해시는 입력을 [[블록]] 단위로 처리하면서 각 블록 사이의 중간 연쇄 값을 계산하는 반복 해시 함수일 것이다. 예를 들어 해시가 SHA-256이고, M이 512비트라고 하면 서버는 클라이언트를 속일 수 있다. 어떻게 그럴까? 서버는 M의 첫 512비트 블록 M₁과 SHA-256의 초기치 H₀을 이용해서 연쇄값 H₁=Compress(H₀, M₁)을 계산한다. 그런 다음에는 그 H₁을 메모리에 저장하고, M 자체는 폐기해 버린다. 그러면 서버는 더 이상 M을 저장한 상태가 아니다.<ref name="장필리프 오마송">장필리프 오마송, 〈[https://play.google.com/store/books/details?id=nNRmDwAAQBAJ&rdid=book-nNRmDwAAQBAJ&rdot=1&source=gbs_vpt_read&pcampaignid=books_booksearch_viewport 처음 배우는 암호화: 기초 수학부터 양자 컴퓨터 이후까지, 암호하그이 현재와 미래]〉, 《구글도서》, 2018-07-31</ref> | ||
| − | 클라이언트가 무작위 시도값 C를 보내면 서버는 C를 적절히 채워서 완전한 블록을 만든 후 Compress(H₁, C)를 계산하고, 그것을 Hash(M∥C)의 결과로서 클라이언트에게 보낸다. 클라이언트는 이를 믿을 수밖에 없다. 서버가 보낸 것이 실제로 Hash(M∥C)의 정확한 값이기 때문이다. 따라서 클라이언트는 서버가 자신의 파일을 잘 저장하고 | + | 클라이언트가 무작위 시도값 C를 보내면 서버는 C를 적절히 채워서 완전한 블록을 만든 후 Compress(H₁, C)를 계산하고, 그것을 Hash(M∥C)의 결과로서 클라이언트에게 보낸다. 클라이언트는 이를 믿을 수밖에 없다. 서버가 보낸 것이 실제로 Hash(M∥C)의 정확한 값이기 때문이다. 따라서 클라이언트는 서버가 자신의 파일을 잘 저장하고 있따고 믿게 된다. 그러나 앞에서 언급했듯이 서버는 파일을 이미 폐기해 버렸을 수 있다. 이 요령은 SHA-1과 SHA-2뿐만 아니라 SHA-3과 BLAKF2에도 통한다. 해결책은 간단하다. Hash(M∥C)가 아니라 Hash(C∥M)을 맞추어 보도록 프로토콜을 수정하면 된다.<ref name="장필리프 오마송"></ref> |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
{{각주}} | {{각주}} | ||
| 30번째 줄: | 21번째 줄: | ||
== 참고자료 == | == 참고자료 == | ||
* Keda Che, "[https://ulabs.tech/images/Universal-Labs-WhitePaper.pdf Universal Labs White Paper V.1.3 (Draft)]", 2018-05-25 | * Keda Che, "[https://ulabs.tech/images/Universal-Labs-WhitePaper.pdf Universal Labs White Paper V.1.3 (Draft)]", 2018-05-25 | ||
| − | |||
| − | |||
| − | |||
== 같이 보기 == | == 같이 보기 == | ||
| 39번째 줄: | 27번째 줄: | ||
* [[유토큰]] | * [[유토큰]] | ||
| − | {{ | + | {{알고리즘|토막글}} |
| + | |||
| + | [[분류:합의 알고리즘]] | ||
