How much time should people receive to repair a weakness before the means of exploiting it become easier to obtain? Google’s February 23, 2017 account of joint research with CWI made that question concrete. Researchers released two different PDFs with the same SHA-1 digest, but announced a 90-day delay before publishing code to generate such pairs under specified conditions. [announcing-first-sha1-collision]

The distinction between showing the weakness and releasing generation code matters to an ethical assessment. Google also said it had added detection of this PDF technique to Gmail and GSuite and provided a public detector. These were vendor claims about a particular defense, not a guarantee for every record. The constructed collision did not prove an ability to forge any existing signed document. [announcing-first-sha1-collision]

A related tension appeared in Google’s November 16, 2016 Chrome plan. It allowed an enterprise policy for certificates chaining to local trust anchors to give organizations additional migration time. Yet that exception could not override an operating-system cryptographic library that disabled SHA-1. The notice described a temporary accommodation, not an unconditional promise of continued access; it did not prove deployment outcomes. [sha-1-certificates-in-chrome]

For interfaith and nonreligious ethical reflection, the question is what record custodians owe the people who must rely on them. No single religious answer is established here. Giving administrators time can serve continuity; treating that time as permission to defer indefinitely asks counterparties to carry unresolved risk. Our judgment is that an honest transition should distinguish a limited detector from a replacement plan, and explain remaining dependencies. The two Google-origin accounts support that deliberation without supplying independent proof that either the disclosure timetable or the migration was completed. [announcing-first-sha1-collision][sha-1-certificates-in-chrome]

Source documents

  1. Announcing the first SHA1 collisionhttps://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
  2. SHA-1 Certificates in Chromehttps://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html