01:20:04 <kayabanerve[m]> https://eprint.iacr.org/2023/331
01:20:04 <xmrack[m]> This article and paper is gaining traction online. Should we put out a blog post letting people know why it doesn’t affect Monero.
01:20:04 <Alex|LocalMonero> xmrack[m]: Sure, but isn't using bad nonces being insecure for ECDSA a widely-known thing?
01:20:05 <kayabanerve[m]> I don't believe we use the NIST submission code. Our library for keccak appears to be a third-round implementation, yet not the vulnerable submission. Instead, it appears to be a human readable alternative implementation (tiny_sha3).
01:20:05 <kayabanerve[m]> It also requires a ~4 GB message to trigger, which I'm unsure is reachable in Monero.
01:20:05 <kayabanerve[m]> So distinct impl, even if we used the buggy impl, we'd probably survive yet should do a release ASAP? But AFAICT, this doesn't affect us, so we don't need to do anything.
01:30:20 <xmrack[m]> From what I’ve heard these attacks have been known for decades. But this one is novel
01:30:20 <Alex|LocalMonero> That's true. Basically as soon as you learn about ECDSA you get told that the nonce must be from a CSRNG
01:30:21 <xmrack[m]> *not a cryptographer
01:31:11 <Alex|LocalMonero> So if someone uses Math.random() when they're writing their custom Bitcoin wallet I'm not sure how that's such a big news story.
01:31:20 <Alex|LocalMonero> But the press is going to love it.
01:33:01 <Alex|LocalMonero> And Monero is also not safe from someone using insecure practices when writing wallet software, so on a very abstract level this issue affects Monero as well.
01:34:10 <UkoeHB> kayabanerve[m]: the abstract says they have a test for detecting it