วิธีแคร็กคีย์ DKIM 512 บิตด้วยค่าใช้จ่ายคลาวด์ต่ำกว่า $8

 (dmarcchecker.app)
3 คะแนน โดย GN⁺ 2025-01-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการสำรวจเว็บไซต์ 1 ล้านอันดับแรก พบ คีย์สาธารณะ DKIM ที่มีขนาดต่ำกว่า 1,024 บิต มากกว่า 1,700 คีย์ และการทดลองนี้ตรวจสอบว่าคีย์ RSA DKIM ขนาด 512 บิตของ redfin.com สามารถถูกนำไปใช้โจมตีได้จริงหรือไม่
  • ถอดรหัสแท็ก p ของเรคคอร์ด DKIM เพื่อให้ได้โมดูลัส RSA n และเลขชี้กำลังสาธารณะ e=65537 จากนั้นใช้ CADO-NFS แยกตัวประกอบโมดูลัส
  • บนเซิร์ฟเวอร์ของ Hetzner ที่มี 8 dedicated vCPU, RAM 32GB ใช้เวลาประมาณ 86 ชั่วโมงในการแยก n ออกเป็นจำนวนเฉพาะสองตัว p, q และสร้างคีย์ส่วนตัว RSA ขึ้นใหม่จากค่านั้น
  • เมื่อลงนามอีเมลที่ส่งจาก security@redfin.com ด้วยคีย์ส่วนตัวที่สร้างขึ้นใหม่ Gmail และ Outlook ปฏิเสธ แต่ Yahoo Mail, Mailfence, Tuta ส่งกลับผล dkim=pass
  • ภายใต้นโยบาย DMARC p=reject; pct=100 ของ redfin.com การผ่าน DKIM นำไปสู่การผ่าน DMARC ดังนั้นผู้ให้บริการอีเมลควรปฏิเสธ ลายเซ็น RSA DKIM ที่ต่ำกว่า 1,024 บิต

ปัญหาคีย์ DKIM 512 บิตที่ยังหลงเหลืออยู่

  • จากการสำรวจเรคคอร์ด SPF, DKIM, DMARC ของเว็บไซต์ 1 ล้านอันดับแรก พบคีย์ DKIM สาธารณะที่มีความยาว ต่ำกว่า 1,024 บิต มากกว่า 1,700 คีย์
  • คีย์ RSA ต่ำกว่า 1,024 บิตถือว่าไม่ปลอดภัย และใน DKIM มีสถานะถูกแนะนำให้เลิกใช้มาตั้งแต่ RFC 8301 ในปี 2018
  • เป้าหมายการทดลองคือ คีย์สาธารณะ RSA 512 บิต ที่พบใน key1._domainkey.redfin.com
  • เป้าหมายคือการตรวจสอบว่าสามารถกู้คืนคีย์ส่วนตัวจากคีย์สาธารณะเพียงอย่างเดียว แล้วลงนามอีเมลเสมือนเป็นผู้ส่งจากโดเมนเดิมได้หรือไม่
  • พร้อมกันนั้นยังตรวจสอบด้วยว่าผู้ให้บริการอีเมลรายใหญ่อย่าง Gmail, Outlook.com, Yahoo Mail จะยอมให้ลายเซ็น DKIM ที่สร้างด้วยคีย์สั้นผ่านหรือไม่

ดึงองค์ประกอบ RSA จากคีย์สาธารณะ DKIM

  • แท็ก p ของเรคคอร์ด DKIM บรรจุคีย์สาธารณะที่ถูกเข้ารหัสในรูปแบบ ASN.1 DER แล้วเข้ารหัสซ้ำเป็น Base64
  • ใช้ Crypto.PublicKey.RSA.import_key ของ Python อ่านคีย์สาธารณะและดึงองค์ประกอบ RSA ออกมา
    • โมดูลัส n: 10709580243955269690347257968368575486652256021267387585731784527165077094358215924099792804326677548390607229176966588251215467367272433485332943072098119
    • เลขชี้กำลังสาธารณะ e: 65537

แยกตัวประกอบโมดูลัสด้วย CADO-NFS

  • ในการสร้างคีย์ส่วนตัว RSA ต้องแยกโมดูลัส n ให้เป็นผลคูณของจำนวนเฉพาะสองตัว p และ q
  • ใช้ CADO-NFS ในการแยกตัวประกอบ
    • CADO-NFS เป็นอิมพลีเมนต์ของอัลกอริทึม Number Field Sieve(NFS) ที่ใช้แยกตัวประกอบจำนวนเต็มขนาดใหญ่
  • เพื่อไม่ให้เครื่องคอมพิวเตอร์ภายในถูกใช้งานต่อเนื่องหลายวัน จึงเช่าเซิร์ฟเวอร์คลาวด์ของ Hetzner
    • สเปกเซิร์ฟเวอร์คือ 8 dedicated vCPU, AMD EPYC 7003 series, RAM 32GB
    • OS คือ Ubuntu
    • เพิ่ม swap 32GB เพื่อให้มีหน่วยความจำเพียงพอสำหรับงาน
  • ป้อนโมดูลัส n ให้ cado-nfs.py เพื่อรันการแยกตัวประกอบ
  • งานทั้งหมดใช้เวลาประมาณ 86 ชั่วโมง บนเซิร์ฟเวอร์ 8-vCPU และ n ถูกแยกเป็นจำนวนเฉพาะสองตัวดังนี้
    • p = 97850895333751392558280999318309697780438485965134147739065017624372104720767
    • q = 109447953515671602102748820944693252789237215829169932130613751100276125683257
  • หากใช้เซิร์ฟเวอร์ที่ทรงพลังกว่านี้หรือกระจายงานบนหลายระบบก็สามารถลดเวลาได้ และ CADO-NFS ทำให้งานแบบกระจายทำได้ง่ายขึ้น

สร้างคีย์ส่วนตัว RSA ขึ้นใหม่

  • หลังจากได้ p, q, e แล้ว ใช้ Python และ PyCryptodome สร้างคีย์ส่วนตัว RSA
  • การคำนวณใช้ค่าและขั้นตอนต่อไปนี้
    • n = p * q
    • phi = (p-1) * (q-1)
    • d = inverse(e, phi)
    • RSA.construct((n, e, d, p, q))
  • ผลลัพธ์คือคีย์ส่วนตัว RSA ในรูปแบบ PEM และนำไปรวมเข้ากับการตั้งค่า OpenDKIM เพื่อใช้ลงนามอีเมลทดสอบ

ผลการตรวจสอบ DKIM แยกตามผู้ให้บริการอีเมล

  • ใส่คีย์ส่วนตัวที่สร้างขึ้นใหม่ใน OpenDKIM แล้วส่งอีเมลทดสอบด้วยที่อยู่ FROM security@redfin.com ไปยังบริการโฮสติ้งอีเมลหลายราย
  • ผู้ให้บริการส่วนใหญ่เห็นว่าคีย์ 512 บิตไม่ปลอดภัยและปฏิเสธลายเซ็น DKIM แต่มี 3 รายส่งกลับผล dkim=pass
  • ผลแยกตามผู้ให้บริการมีดังนี้
    • Gmail: FAIL
    • Outlook: FAIL
    • Yahoo Mail: PASS
    • Zoho: FAIL
    • Fastmail: FAIL
    • Proton Mail: FAIL
    • Mailfence: PASS
    • Tuta: PASS
    • GMX: FAIL
    • OnMail: FAIL
  • redfin.com มี เรคคอร์ด DMARC ที่ถูกต้องในรูปแบบ v=DMARC1;p=reject;pct=100;...
  • การผ่านการตรวจสอบ DKIM สำหรับ redfin.com นำไปสู่การผ่านการตรวจสอบ DMARC และยังเป็นไปตามข้อกำหนดของ BIMI ด้วย

ค่าใช้จ่ายและมาตรการเชิงปฏิบัติการ

  • เมื่อ 30 ปีก่อน การเจาะคีย์สาธารณะ RSA 512 บิตเป็นงานระดับซูเปอร์คอมพิวเตอร์ แต่ปัจจุบันทำได้บนเซิร์ฟเวอร์คลาวด์ด้วยค่าใช้จ่าย ต่ำกว่า US$8
  • หากมีคอมพิวเตอร์ใช้ในบ้านที่ทรงพลังและมี 16 คอร์ขึ้นไป ก็อาจทำได้เร็วกว่าและถูกกว่า
  • ไม่มีเหตุผลที่จะยังคงใช้คีย์ DKIM ขนาด 512 บิตหรือ 768 บิต และผู้ให้บริการอีเมลควรปฏิเสธลายเซ็น DKIM ที่สร้างด้วย คีย์ RSA ต่ำกว่า 1,024 บิต โดยอัตโนมัติ
  • ได้แจ้งผลการทดลองและคำแนะนำไปยัง Yahoo, Mailfence, Tuta แล้ว
  • เจ้าของโดเมนควรตรวจสอบเรคคอร์ด DKIM เก่าในการตั้งค่า DNS
    • สามารถตรวจสอบแท็ก p ของเรคคอร์ด DKIM ได้ง่าย ๆ โดยนับจำนวนอักขระ Base64
    • คีย์สาธารณะ RSA 1,024 บิตจะมีความยาวอย่างน้อย 216 อักขระ เมื่ออิงตาม Base64

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-09
ความคิดเห็นบน Hacker News

  • แม้เมื่อ 14 ปีก่อน คีย์ DKIM RSA ขนาด 512 บิต ก็สามารถถูกเจาะได้แล้ว: https://blog.jgc.org/2010/06/facebooks-dkim-rsa-key-should-b...

    • อยู่ช่วงหนึ่ง การใช้คีย์ DKIM ที่อ่อนแอถูกมองแบบไม่เป็นทางการราวกับเป็นฟีเจอร์ด้วยซ้ำ
      ตรรกะคือ ถ้าคีย์สั้น ลายเซ็น DKIM จะไม่คงอยู่เป็นหลักฐานได้นาน ทำให้ภายหลังพิสูจน์ได้ยากว่าอีเมลฉบับใดเป็นของจริง จึงรักษา ความสามารถในการปฏิเสธความรับผิดชอบ ได้
      แน่นอนว่าไม่ได้หมายความว่าบริษัทส่วนใหญ่ใช้คีย์สั้นด้วยเหตุผลนั้น แต่หมายถึงเคยมีบรรยากาศว่าคีย์สั้นไม่ได้แย่ไปเสียทั้งหมด
      เรื่องการปฏิเสธความรับผิดชอบของ DKIM เป็นหัวข้อที่ผมสนใจมานาน [1] และแม้คีย์สั้นแบบนี้จะไม่ใช่ทางออกอย่างชัดเจน แต่ผมมองว่ามันเป็นผลจากวิธีคิดที่สับสนรอบ ๆ DKIM และบรรยากาศในชุมชนที่ไม่อยากยอมรับนัยของระบบลงลายเซ็นอีเมลทุกแบบ
      [1] https://blog.cryptographyengineering.com/2020/11/16/ok-googl...
    • นึกถึงเรื่องของคนที่เจาะคีย์ DKIM เพราะคิดว่าเป็นโจทย์ท้าทายรับสมัครงานของ Google
      https://www.wired.com/2012/10/dkim-vulnerability-widespread/
    • ในปี 1999 การแยกตัวประกอบ RSA-155 ด้วยคอมพิวเตอร์หลายร้อยเครื่องแสดงให้เห็นว่า คีย์ 512 บิต สามารถถูกเจาะได้ในทางปฏิบัติ และมีคนบอกว่าตอนนี้ฮาร์ดแวร์ทั่วไปก็ทำได้ภายในไม่กี่สัปดาห์
      กล่าวคือในราว 14 ปี ลดจากไม่กี่สัปดาห์เหลือ 8 ชั่วโมง
    • อนึ่ง ผู้เขียนคอมเมนต์แม่คือ CTO ของ CloudFlare
    • บล็อกนั้นถูกพูดถึงในคอมเมนต์ของ http://www.wired.com/threatlevel/2012/10/dkim-vulnerability-... ด้วย

  • ถ้าอยากลองเล่น ๆ ก็ลองสร้าง คีย์ DKIM ขนาด 4096 บิต ดู
    ตัวตรวจสอบ DKIM/SPF ออนไลน์จะดูแค่ DNS แล้วบอกว่าทุกอย่างปกติ แต่เมลทดสอบจะล้มเหลว
    มันจะแสดงคำอธิบายยอดเยี่ยมประมาณ STATUS: Fail, DKIM: Pass, SPF: Pass
    การใช้คีย์ที่ใหญ่กว่า 2048 บิตในรายการ DKIM นั้นอนุญาตและถือว่าถูกต้อง แต่ตัวตรวจสอบไม่ได้จำเป็นต้องรองรับคีย์ที่ใหญ่กว่า 2048 บิต
    ผมเสียเส้นผมไปไม่น้อยกว่าจะเรียนรู้เรื่องนี้ด้วยตัวเอง

    • เพิ่มเติมคือ ถ้าจะเห็นการตรวจสอบล้มเหลว ต้องตั้งค่า นโยบาย DMARC ที่เข้มงวด
      น่าสนใจที่เว็บไซต์ต่าง ๆ บอกว่าทั้งสามรายการถูกต้องและใช้งานได้ทั้งหมด แต่เมลกลับถูกจัดว่าล้มเหลว
      น่าจะเป็นเพราะซอฟต์แวร์ที่ใช้ตรวจ DNS record กับที่ใช้ยืนยันอีเมลเป็นคนละตัวกัน
    • RFC ล่าสุดคือ RFC8301 มีข้อกำหนดไว้
      ตัวตรวจสอบต้องสามารถตรวจลายเซ็นที่ใช้คีย์ตั้งแต่ 512 บิตถึง 2048 บิตได้ และระบุว่าสามารถตรวจคีย์ที่ใหญ่กว่านั้นได้ด้วย
      เมื่อปีก่อนผมเขียนวิทยานิพนธ์ปริญญาโทในหัวข้อนี้ และผู้ให้บริการอีเมลรายใหญ่ทุกเจ้าปัจจุบันรองรับ 4096 บิตแล้ว บางเจ้ารองรับถึง 16384 บิตด้วย

  • สงสัยว่าทำไมเราไม่เพิ่ม ขนาดคีย์ ให้ใหญ่ขึ้นโดยรวมในงานเข้ารหัสทั้งหมด
    แม้จะไม่ใช่ทางออก แต่ดูเหมือนเป็นมาตรการซื้อเวลาได้
    สมรรถนะการคำนวณเพิ่มขึ้นเร็ว และก็มีการพูดถึงคอมพิวเตอร์ควอนตัมอยู่เรื่อย ๆ แต่ทุกคนดูนิ่งเฉย
    แน่นอนว่าคีย์ใหญ่มีต้นทุนคำนวณมากกว่า แต่ทรัพยากรคำนวณของเราก็เพิ่มขึ้นแล้ว จึงน่าจะเอาไปใช้กับการป้องกันด้วย ไม่ใช่แค่ฝั่งโจมตี
    แค่เรื่องง่าย ๆ อย่างการบังคับใช้ TLS 1.3 แทน TLS 1.2 ฝั่งไคลเอนต์ก็ทำให้หลายอย่างพัง รวมถึงเว็บ HN ด้วย

    • บทความเก่าแต่ยังเกี่ยวข้องอยู่: https://www.schneier.com/blog/archives/2009/09/the_doghouse_...
      ตัวเลขเหล่านี้เกี่ยวข้องกับขีดจำกัดสูงสุดที่อุณหพลศาสตร์อนุญาต ไม่ใช่ระดับเทคโนโลยีของอุปกรณ์
      สรุปคือ การเจาะ AES-256 หรือ RSA-4096 ด้วย brute force เป็นไปไม่ได้ทางฟิสิกส์
    • เราทำแบบนั้นกันอยู่แล้ว
      คีย์ 1024 บิต ถูกเลิกใช้ในระบบเข้ารหัสหลายประเภทมากว่า 10 ปีแล้ว
      ยกเว้นกรณีล้าหลังบางจุดเท่านั้น และสิ่งเดียวที่คุกคามคีย์ 2048 บิตคือคอมพิวเตอร์ควอนตัม ซึ่งคุกคาม RSA ทั้งระบบอยู่แล้ว
      ความก้าวหน้าไม่ได้เป็นเชิงเส้น ดังนั้นการที่ 1024 อ่อนแอลงไม่ได้แปลว่า 2048 จะพังตามแบบกลไกในเร็ว ๆ นี้ และแม้แต่ 1024 ในวันนี้ก็ยังโจมตีจริงได้ไม่ง่าย
    • RSA-2048 ยังไม่ถูกเจาะ และขั้นต่อไปก็สามารถพึ่ง RSA-4096 ซึ่งพบได้ทั่วไปอยู่แล้วในการใช้งาน RSA ส่วนใหญ่
      DKIM เป็นหนึ่งในข้อยกเว้น
      ฝั่ง DKIM กำลังรอให้ Ed25519 ถูกใช้อย่างแพร่หลาย และเมื่อถึงตอนนั้นความไม่สะดวกหลายอย่างก็น่าจะหมดไป
    • เพราะถ้าจะบังคับใช้ สุดท้ายก็ต้องทำให้บางอย่างพัง
      โดยมากความเจ็บปวดนั้นไม่ได้ตกกับผู้ให้บริการ แต่ตกถึงผู้ใช้โดยตรง แล้วโครงสร้างก็หวังให้ผู้ใช้บ่นเสียงดังจนผู้ให้บริการสนใจ
      แต่ผู้ใช้ก็มีแนวโน้มสูงที่จะย้ายไปหาคู่แข่งที่ทำให้เรื่องเล็ก ๆ อย่างความปลอดภัยไม่มาขวางรายได้
    • แม้เมื่อ 8 ปีก่อน ตอนที่ผมทำงานในอุตสาหกรรมอีเมล DKIM 512 บิต ก็พบได้น้อยมากแล้ว
      พูดจริง ๆ นี่เหมือนถามว่า “ทำไมเราไม่ทำสิ่งที่เราทำกันอยู่แล้ว”

  • ใช้ CADO-NFS แล้วทำได้ง่ายกว่าที่คิด
    เมื่อไม่กี่สัปดาห์ก่อน ผมแยกตัวประกอบคีย์ RSA DKIM ขนาด 512 บิตด้วยคอมพิวเตอร์เดสก์ท็อปเพราะเรื่องงาน ใช้เวลาแค่ 28 ชั่วโมง
    รุ่นที่ใช้คือ AMD Zen 5 9900X
    น่าเสียดายที่คีย์ 1024 บิตยังยากเกินกว่าจะทำในระดับงานอดิเรก แต่ถ้าเป็นโปรเจกต์วิชาการระดับเดียวกับที่เคยแยกตัวประกอบคีย์ 768 บิตในปี 2010 ก็อาจเป็นไปได้: https://eprint.iacr.org/2010/006.pdf

  • เมื่อวานได้รับอีเมลจาก Bank of America เกี่ยวกับปัญหาการตั้งค่าบัญชี
    จริงอยู่ที่ผมเพิ่งสร้างบัญชีใหม่ และอีเมลนั้นก็รู้เรื่องนี้ รวมถึงชื่อบริษัท ฯลฯ
    ไม่มีลิงก์ มีแค่คำแนะนำให้โทรไปที่หมายเลขธุรกิจของ BofA และเมื่อเช็กหมายเลขบนเว็บไซต์ BofA ก็พบว่าตรงกัน เลยโทรไป
    แต่ไม่มีใครบอกได้ว่าทำไมผมถึงได้รับอีเมล หรือบัญชีมีปัญหาอะไร และเจ้าหน้าที่ก็หา record การส่งอีเมลนี้ไม่เจอด้วย
    ผมมั่นใจ 100% ว่าอีเมลนี้มาจาก Bank of America
    ไม่มีองค์ประกอบของ phishing ไม่มีลิงก์ และไม่มีหมายเลขโทรศัพท์อันตราย
    SPF, DKIM, DMARC ทั้งหมดผ่านใน ARC-Authentication-Results ของ Google และ DKIM key ก็เป็น 2048 บิต
    พอขอให้ Bank of America ตรวจสอบ พวกเขากลับบอกว่า “น่าจะเป็นข้อความ phishing” แล้วส่งลิงก์วิธีระวัง phishing มาให้
    เป็นไปได้สูงว่าเป็นเพียงข้อผิดพลาดธรรมดาจากระบบบางตัวที่รัน consistency check เร็วเกินไประหว่างการสร้างบัญชี แล้วสร้างอีเมลขึ้นมา
    แต่เพราะพวกเขาบอกว่าเป็น “phishing” ผมจึงแนบเอกสารทั้งหมดแล้วส่ง FedEx ไปถึง CTO
    มีได้สองกรณี: DKIM key รั่ว ดังนั้นต้องออกคำเตือนสาธารณะทันที หรือไม่ก็เป็นพนักงานกับระบบ IT ที่ไร้ความสามารถทำให้ผมถูกโยนไปโยนมาและเสียเวลาไปหนึ่งชั่วโมง
    ไม่ว่าจะกรณีไหน ผมต้องการให้มีการสอบสวนและแก้ไขอย่างครบถ้วน

  • ผู้ให้บริการ DNS บางรายแย่มากจนตั้งค่าได้แค่ key ความยาว 1024 บิต เท่านั้น
    เช่น wordpress.com เป็นแบบนั้น

    • 1024 บิตแตกยากกว่า 512 บิตหลายลำดับขั้น
      สำหรับข้อมูลอ้างอิง RSA number ล่าสุดที่ถูกแตกได้คือ RSA-250 หรือ 829 บิต และในปี 2020 ใช้เวลา 2700 core-year [1]
      ขณะที่ RSA-155 หรือ 512 บิต ถูกแยกตัวประกอบไปแล้วตั้งแต่ปี 1999
      จึงยังไม่ใช่สภาพที่อันตราย
      [1]: https://sympa.inria.fr/sympa/arc/cado-nfs/2020-02/msg00001.h...
    • NIST ตั้งใจจะแบนแม้แต่ 2048-bit RSA ภายในปี 2035
      เหตุผลคือให้ระดับความปลอดภัยไม่เพียงพอ
    • RSA-1024 ถือได้ว่าดีกว่า RSA-512 ราว 8 ล้านเท่า ดังนั้นถ้าจะเจาะก็น่าจะมีค่าใช้จ่ายด้านการคำนวณอย่างเดียวประมาณ 64 ล้านดอลลาร์
      อาจไม่ถึงขั้นกัน NSA ได้ แต่เมื่อคิดว่า DKIM เป็นหนึ่งในหลายชั้นการป้องกัน ก็ดูเพียงพอสำหรับกันสแปมเมอร์
    • DKIM record ก็เป็นแค่ DNS TXT record
      สงสัยว่ามีข้อจำกัดเรื่องขนาดของ TXT record หรือเปล่า หรือว่าระบบพยายาม parse TXT record ที่ดูเหมือน DKIM โดยไม่จำเป็น แล้วล้มเหลวจนปฏิเสธไม่ให้เพิ่ม

  • การ crack 512-bit key เพื่อสาธิตที่ดีนั้น แม้จะเคยมีคนทำไปแล้ว ก็ยังเป็นงานวิจัยความปลอดภัยที่มีคุณค่ามาก
    การเปิดเผยว่า “นี่คือรายชื่อที่ยังใช้ 512 บิตอยู่ ควรย้ายออก” ก็สมเหตุสมผล
    แต่การ crack key ของโลกจริงที่ใช้งานอยู่จริงโดยตรง ส่วนตัวรู้สึกไม่สบายใจ เพราะเหมือนล้ำเส้นทางจริยธรรม
    ผมไม่ใช่ทนาย แต่ก็ดูเหมือนอาจเป็นอาชญากรรมได้ และดูไม่จำเป็นสักเท่าไร

    • เขาแจ้งช่องโหว่ให้บริษัทนั้นทราบ แก้ไขแล้วจึงเผยแพร่บทความ
      ลองค้น now no longer available ในต้นฉบับได้
      โดยทั่วไป เมื่อจะแสดงว่าระบบออนไลน์มีช่องโหว่ ก็จะจำลองช่องโหว่ด้วยเจตนาดี จัดทำเอกสารงานวิจัย แล้วขอให้ตรวจสอบ
      ไม่ว่าจะเป็นการทำลายระบบเข้ารหัส การได้รันโค้ดใดก็ได้บนเกมคอนโซลที่ถูกล็อก การพิสูจน์ว่าสามารถแก้ไขข้อมูลเครื่องลงคะแนนได้ หรือการแสดงว่าสามารถแก้คอมเมนต์ Q&A ของ Google Meet ได้ กระบวนการก็เหมือนกัน
      ถ้าแค่บอกว่ามีช่องโหว่ อาจถูกเมินได้ แต่ถ้าบอกและพิสูจน์ว่ามีช่องโหว่ ก็เมินได้ยากขึ้น
      และถ้ากำหนดเส้นตายการเปิดเผยตามมาตรฐานอุตสาหกรรม พร้อมพยายามติดต่อราว 60 วันก่อนจะเปิดเผยช่องโหว่ โอกาสที่จะเมินก็แทบไม่เหลือ
    • การ crack key ไม่ใช่อาชญากรรม
      มันก็แค่ คณิตศาสตร์
      สิ่งที่ผิดกฎหมายคือการอาศัยคณิตศาสตร์นั้นเพื่อส่งอีเมลที่เป็นการฉ้อโกงหรือเข้าข่ายละเมิดกฎหมายในเขตอำนาจศาลบางแห่ง
      แก่นสำคัญไม่ใช่คณิตศาสตร์ แต่เป็นการกระทำและเจตนา
      การชี้ว่ามีใครกำลังทำเรื่องโง่ ๆ อยู่ก็ไม่ผิดกฎหมายเช่นกัน แต่พวกเขาอาจพยายามทำให้ชีวิตคุณลำบากได้
    • งานวิจัยความปลอดภัยจำนวนมากก็พูดแบบเดียวกันได้
      ประมาณว่า “แสดงให้เห็นว่า bug exploit ได้ก็โอเค แต่การเขียน proof-of-concept code นั้นล้ำเส้น”
      ปัญหาคือถ้าไม่แสดงให้เห็นว่าทำได้จริง คนส่วนใหญ่ก็ไม่ฟังงานวิจัยความปลอดภัย
    • ในบรรดาโดเมนประมาณ 1700 แห่งที่ใช้ key สั้นกว่า 1024 บิต มีเพียงแห่งเดียวที่ถูกเปิดเผยชื่อจริง
      แต่สำหรับผู้ให้บริการอีเมลรายใหญ่ 3 จาก 10 รายที่ไม่ปฏิบัติตาม DKIM RFC อย่างถูกต้อง ได้แก่ Yahoo, Tuta, Mailfence ได้ถูกเปิดเผยหลังจากแจ้งไปแล้ว
    • หากใช้เพียงข้อมูลสาธารณะและไม่ได้ทำอะไรกับผลลัพธ์ การ crack key ที่ใช้งานจริงอยู่ในโลกจริงเองก็ดูมีแนวโน้มสูงว่าไม่ใช่อาชญากรรม

  • นี่คือเหตุผลที่ต้องเลิกให้ Hover จัดการ DNS
    ไม่รองรับ TXT record ที่ยาวกว่า 255 ตัวอักษร และก็หาเคสที่ split record ใช้งานได้บน Hover ไม่เจอ
    สุดท้ายเลยต้องใช้ Digital Ocean
    ถ้าปัญหาแบบนี้จะลากต่อไปอีก 10 ปี ก็อยากให้ elliptic-curve cryptography กลายเป็นมาตรฐาน

  • จากส่วนที่ว่า “ผู้ให้บริการส่วนใหญ่ระบุได้ถูกต้องว่า key 512 บิตไม่ปลอดภัยและปฏิเสธ DKIM signature แต่ผู้ให้บริการรายใหญ่สามราย — Yahoo Mail, Mailfence, Tuta — รายงาน dkim=pass” สงสัยว่า Google ล้มเหลวเพราะ DKIM signature ไม่ปลอดภัยจริง ๆ หรือเพราะ SPF failed กันแน่

    • การตรวจสอบ DKIM ล้มเหลวตาม RFC 8301 ด้วยผลลัพธ์ dkim=policy (weak key)
      ตรงตามข้อกำหนดที่ว่า “ตัวตรวจสอบต้องไม่ถือว่า signature ที่ใช้ RSA key ต่ำกว่า 1024 บิตเป็น signature ที่ถูกต้อง”

  • ตัวเลข 512 บิตจะมากหรือน้อยขึ้นอยู่กับว่าเป็น การเข้ารหัสแบบสมมาตร หรือ การเข้ารหัสแบบอสมมาตร
    โดยทั่วไปมองได้ว่าการเข้ารหัสแบบอสมมาตรอ่อนกว่าการเข้ารหัสแบบสมมาตร 8 เท่าเสมอ
    DKIM เป็นแบบอสมมาตร ดังนั้น DKIM 512 บิตจึงเทียบได้กับ 64 บิตเมื่อเทียบกับแฮชแบบสมมาตร และอยู่ในระดับที่ถูกทำลายได้ไปนานแล้ว
    แม้แต่ SHA-1 ขนาด 160 บิตก็ถือว่าถูกทำลายแล้ว
    หากเป็น DKIM ที่มีความแข็งแกร่งใกล้เคียงกับ SHA-3 ขนาด 512 บิต ก็ต้องมีอย่างน้อย 4096 บิต และถึงอย่างนั้นก็ยังไม่ได้รวมเทคนิคบรรเทาการโจมตีแบบส่งซ้ำของ SHA-3 ด้วย

    • DKIM ไม่ใช่อัลกอริทึมการเข้ารหัส
      แต่เป็นมาตรฐานสำหรับใส่ ลายเซ็น ในเฮดเดอร์อีเมลแล้วตรวจสอบ
      น่าเสียดายที่ DKIM รองรับเฉพาะลายเซ็น rsa-sha1 และ rsa-sha256 เท่านั้น: https://datatracker.ietf.org/doc/html/rfc6376/#section-3.3
      คงจะดีถ้า DKIM ได้รับการปรับปรุงให้รองรับ Ed25519 หรือรูปแบบลายเซ็นที่คล้ายกัน
    • การเข้ารหัส RSA อ่อนกว่า การเข้ารหัสแบบเส้นโค้งวงรี 10 เท่า
      ตัวอย่างเช่น ECC 224 บิตมีความแข็งแกร่งใกล้เคียงกับ RSA 2048 บิต
      ทั้งคู่เป็นแบบอสมมาตร
      ในทางกลับกัน เส้นโค้งวงรีแบบอสมมาตรมีความแข็งแกร่งใกล้เคียงกับ AES ซึ่งเป็นการเข้ารหัสแบบสมมาตร
      แน่นอนว่ายังเปราะบางต่อคอมพิวเตอร์ควอนตัม