Hacker News 의견

• 디자인이 매우 영리함: CMAC 기반으로, 낮은 수준의 프리미티브가 없을 때 AES-CBC를 사용하여 키를 유도할 수 있음

  • AES-CBC 용어로 설명하면:

    1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
    2. MSB₁(L) = 0이면, K1 = L << 1;
       그렇지 않으면 K1 = (L << 1) ⊕ 0¹²⁰10000111
    3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
    4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
    5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
    6. Nₓ = N[12:]
    

  • AES-CBC-256은 첫 번째 128비트 블록을 반환하고, 패딩된 블록은 버림
  • 키를 유도한 후 표준 AES-GCM과 함께 사용
  • WebCrypto API를 기반으로 한 JS 구현 예시: GitHub 링크
  • AES-CBC용으로 의도된 적절한 CryptoKey를 수용하며, IndexedDB에 저장 가능

• Filippo의 작업이 훌륭함: 무작위 논스를 사용할 경우 약 2^32 메시지마다 키를 회전해야 하는 문제를 해결함

  • AES-GCM에서 논스 충돌은 치명적임 (공격자가 임의의 메시지에 서명할 수 있게 됨)
  • 무작위 논스를 사용할 필요는 없지만 일반적으로 권장됨
  • 두 가지 프리미티브(카운터 기반 KDF와 일반 GCM)를 사용하여 FIPS 준수하게 만든 것이 매우 영리함

• 이 기능이 몇 년 전 암호화 파일 시스템을 작성할 때 존재했으면 좋았을 것임

  • 논스 충돌은 대규모 파일 시스템 배포에서 큰 문제임
  • 2^32는 커 보이지만 초당 100k IOPS를 쓰는 PB 배열에서는 PRNG 무작위성에 의존할 경우 충돌 가능성이 거의 보장됨

• 이 기능이 아카이브 파일 암호화 용도로 FIPS 준수 변형 age[1]에 사용되기를 바람

  • 은행 산업 감사관들이 ChaCha 대신 AES를 사용하지 않아 age를 반대했음 (X25519 공개 키 부분은 NIST에서 최근 승인됨)
  • golang 경험은 없지만 age 사양에 따라 쉽게 적용될 것 같음
  • 시간이 허락하면 시도해볼 것임
  • "cage"라고 부를 것임 ("compliant actually good encryption"의 약자)

• 비암호학자의 질문: 왜 192비트 논스를 사용하고 256비트를 사용하지 않는지 궁금함

  • 실용적인 응용에서 추가 비트가 비용이 많이 들 것 같지 않음

• (2⁸⁰ 메시지에서 충돌 위험 2⁻³²)

  • AES 블록 크기가 128비트이기 때문에 그 전에 문제가 발생할 수 있는지 궁금함