4 ms·
Well, by 2030 the non-repudiation will be considered lost if that’s the case. Maybe even 2027. But today, in 2020, a verified DKIM is strong indication about th
by beagle3 6y ago
Well, by 2030 the non-repudiation will be considered lost if that’s the case. Maybe even 2027. But today, in 2020, a verified DKIM is strong indication about the identity of the writer, or that the keys weren’t safely stored.
- woodruffw 6y ago> Maybe even 2027. But today, in 2020, a verified DKIM is strong indication about the identity of the writer, or that the keys weren’t safely stored. Except that we're talking about leaks of emails that date back by years: the earliest Podesta emails are from 2010, back when Google was using 512-bit (!) keys for DKIM. Those were leaked in 2016, at which point 1024-bit keys were already considered crackable by a motivated attacker. This isn't to say that those emails were faked, only that "an email written in 2020 that's verifiable in 2020" is not the target of interest.
- beagle3 6y ago..... so? That means in 2016, the DKIM was already deniable. And it made no difference whatsoever. The DKIM signature is proof only that whoever signed the email possessed the key, nothing more, nothing less. This, in turn, is a suggestion about the identity of the signer and possibly the author - but not proof. Did DKIM change anything about the podesta emails? Or were they basically acknowledged as authentic regardless, and had a lot of other verifyable info in them?
- woodruffw 6y ago> ..... so? That means in 2016, the DKIM was already deniable. And it made no difference whatsoever. Both journalists and investigative groups (and conspiracy theorists) treat DKIM as a sign of authenticity, even when the key material is long past its prime. Wikileaks still prominently displays a "verified" marker next to their archives. > Did DKIM change anything about the podesta emails? Or were they basically acknowledged as authentic regardless, and had a lot of other verifyable info in them? That's hard to say, but it's also not the point. The point with being able to crack the key is that a motivated party could intersperse false information with otherwise verifiable information. And, well, what's a conspiracy theorist to do? Only believe the non-juicy parts?
- beagle3 6y agoI don’t understand the fascination with DKIM on this thread. Yes, journalists verified it. But they consider it supporting data, just as they wouldn’t automatically ignore any email that had no DKIM signature. Phone calls are never authenticated. Does anyone automatically believe or disbelieve recorded phone calls? I mean, “conspiracy theorists” (in the common usage of that terms) already believe only what they want to believe.
- woodruffw 6y agoI don't think it's a fascination, it's what the OP is about. We're talking about the subject of a blog post, no? I think the point boils down to expectation management: journalists (and ...) barely understand non-repudiation, much less why each of the following scenarios pans out: * 2006 email + 512-bit RSA, leaked in 2006: probably authentic * 2008 email + 512-bit RSA, leaked in 2012: potentially inauthentic * 2008 email + 1024-bit RSA, leaked in 2008: probably authentic * 2008 email + 1024-bit RSA, leaked in 2016: potentially inauthentic ...and so on. In sum: we're making life harder for the people doing real investigative work (since they're not technical), and we're giving fodder to the people who want to conspiracize. All because we're using a spam mitigation technique to provide properties that it was never intended to provide.
- beagle3 6y agoThe right solution in this case is to educate journalists - they are up to date on things like deep fakes and should be on DKIM. The wrong solution is to make previously private keys public to make any reasoning about past data impossible in the name of “hut journalists might get a wrong impression”
- couchand 6y agoThe OP is looking for a systemic solution to the problem, somewhat akin to the way establishing a bug bounty program aligns incentives. Your solution is like asking your team to please work harder to not release exploitable bugs.