LabHub
배우기 러닝패스 코스

빌드는 초록불이었는데 그 라이브러리는 누가 넣었나 · 서명은 멀쩡한데 그 키를 우리가 회수했다 · 퀴즈

퀴즈: 서명과 검증

LabHub 에서 이어서 보기

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

  1. 서명을 파일 전체가 아니라 다이제스트에 거는 결과로 따라오는 성질은?

    1. 서명 파일이 원본과 같은 크기가 된다
    2. 한 바이트만 달라져도 같은 서명으로 맞출 수 없게 된다
    3. 같은 파일에 두 번 서명하면 서명이 합쳐진다
    4. 공개키 없이도 검증할 수 있게 된다
  2. 회수한 옛 키로 만든 서명이 '위조' 와 다른 점은?

    1. 해시 알고리즘이 다르게 쓰였다는 점
    2. 서명 파일의 형식이 표준을 벗어난다는 점
    3. 수학적으로는 멀쩡한 서명이고 그 키의 공개키로는 통과한다는 점
    4. 서명한 시각이 기록되지 않는다는 점
  3. sigstore 의 기본 흐름에서 서명 직후 비밀키는 어떻게 되는가?

    1. 곧 파기되고 짧은 수명의 인증서도 만료된다
    2. 투명성 로그에 암호화되어 보관된다
    3. 인증 기관이 대신 보관해 준다
    4. 사용자의 키 저장소에 자동으로 저장된다
  4. 검증 명령의 종료 코드를 파이프라인에서 보지 않으면 어떤 상태가 되는가?

    1. 검증이 느려져 빌드 시간이 늘어난다
    2. 다음 빌드에서 서명이 자동으로 다시 만들어진다
    3. 검증 결과가 투명성 로그에 남지 않는다
    4. 서명을 안 붙인 것보다 나쁜 상태가 된다 — 모두가 보호받는다고 믿는다
  5. 키를 교체할 때 옛 키를 등록부에서 그냥 지우는 대신 기한을 적는 이유는?

    1. 지우면 등록부 파일이 손상될 수 있어서
    2. 지운 키는 나중에 복구할 수 없어서
    3. 옛 키로 서명된 아직 배포되지 않은 릴리스가 전부 막히기 때문에
    4. 기한이 있어야 검증 속도가 빨라지기 때문에
  6. cosign 이 KMS 제공자를 URI 로 가리키게 한 것이 검증 쪽에 주는 이점은?

    1. 서명 파일이 작아져 저장 비용이 줄어든다
    2. 비밀키는 보관 자리에 둔 채 공개키만 꺼내 검증할 수 있다
    3. 검증할 때 인터넷 연결이 아예 필요 없어진다
    4. 투명성 로그를 쓰지 않아도 검증이 성립한다