It looks like the leaf hash added to the Merkle tree is
ti69nN62xOf6NHpRjmsw7GxIa3IfKVUK/2EBQDUsNU8= - a one-bit difference from
the correct hash of ty69nN62xOf6NHpRjmsw7GxIa3IfKVUK/2EBQDUsNU8=.
I think the most likely explanation is that this was a hardware error
caused by a cosmic ray or the like, rather than a software bug. It's just
very bad luck :-(
Unfortunately, it's not possible for the log to recover from this event.
In the case of Nimbus 2018, the log operator was able to fix the
get-entries response to return entries matching the STH. In this case,
it can't be done because it would require breaking SHA-2's preimage
resistance to find the preimage of the bit-flipped hash. Yeti 2022
will never be able to return a get-entries response that matches STHs
with tree_size > 65562066.
Additionally, the SCT issued for entry 65562066 can't be audited,
because the client will attempt to audit the correct leaf hash, which
is not in the Merkle tree.
There are still entries being added to Yeti 2022. CAs should
immediately cease using this log, and ideally it would be made
read-only.
Regards,
Andrew
>
https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFK%3DoS8jrOyxtnndoJ55pO-pxE0pAtvV8jY2p98tXt862fQ18A%40mail.gmail.com.
from Hacker News https://ift.tt/3hAtxy2
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.