
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
      <title>Chaos and Order</title>
      <link>https://www.youngju.dev/blog</link>
      <description>천천히 올바르게. AI Researcher &amp; DevOps Engineer Youngju&#39;s tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.</description>
      <language>ko</language>
      <managingEditor>fjvbn2003@gmail.com (Youngju Kim)</managingEditor>
      <webMaster>fjvbn2003@gmail.com (Youngju Kim)</webMaster>
      <lastBuildDate>Thu, 16 Jul 2026 00:00:00 GMT</lastBuildDate>
      <atom:link href="https://www.youngju.dev/tags/webpki/feed.xml" rel="self" type="application/rss+xml"/>
      
  <item>
    <guid>https://www.youngju.dev/blog/2026-07-16-pq-certificates-merkle-tree-certs</guid>
    <title>PQ 인증서가 아직 안 오는 이유 — ML-DSA 서명 크기, 10kB의 벽, 그리고 Merkle Tree Certificates</title>
    <link>https://www.youngju.dev/blog/2026-07-16-pq-certificates-merkle-tree-certs</link>
    <description>포스트양자 전환에서 키 교환(암호화)은 이미 상당히 진행됐지만, 인증서와 서명 쪽은 아직 출발선에 있습니다. 이유는 암호학이 아니라 크기입니다 — FIPS 204가 정한 ML-DSA-44 서명은 2,420바이트로 ECDSA P-256의 64바이트보다 훨씬 크고, 오늘날 웹 핸드셰이크가 서명 5개와 공개키 2개를 나르기 때문에 그대로 갈아끼우면 인증 데이터만 1만 바이트를 넘습니다. Cloudflare가 2021년에 실측한 바로는 인증서 체인에 10kB 넘게 더하면 클라이언트·미들박스 실패율이 급증하고, 9kB 미만이어도 핸드셰이크가 약 15% 느려졌습니다. 이 글은 그 숫자들이 어디서 나왔는지 1차 출처로 확인하고, 업계가 택한 우회로인 Merkle Tree Certificates(배치 서명 + 포함 증명)의 설계와 IETF PLANTS·Chrome·Let&#39;s Encrypt의 실제 일정, 그리고 이 접근에 붙은 조건과 반론(추정치의 가정, 클라이언트 최신성 의존, 핸드셰이크 시간 중심 관점에 대한 pushback)까지 정직하게 정리합니다.</description>
    <pubDate>Thu, 16 Jul 2026 00:00:00 GMT</pubDate>
    <author>fjvbn2003@gmail.com (Youngju Kim)</author>
    <category>security</category><category>post-quantum-cryptography</category><category>tls</category><category>webpki</category><category>certificates</category>
  </item>

    </channel>
  </rss>
