shinigami

What monumental cowardice. The "high ideological rhetoric" is something not even mildly "ideological". And then it's their fault that the shitty dudebros of HN had a fit?

Please ban me from the orange hellsite so that I'm never tempted on commenting something ever again, while you reflect on why you're defending such garbage people

> The layperson doesn't have to understand the intricacies of email protocols, it's enough that they consider email to be non-repudiable.

They consider it non-repudiable not because of DKIM, it's just a common misconception. People believed that before DKIM. They will still believe it if Google discloses its DKIM keys.

They totally should not believe it, though.

> So if I can't give the exact number of times that DKIM has helped in dispute resolution, then my argument "has zero basis in reality"?

Of course that's not what I meant, I don't care about exact numbers. Just give me some evidence that DKIM is relevant to solve disputes anywhere else other than in the minds of HN commenters. Otherwise your claim that the world is better off now with non-repudiable email has no basis in reality.

> they are choosing non-repudiation over privacy

They totally are not. They have no idea what are the properties of email. As an example, a non-tech friend of mine was once surprised that email does not provide any confidentiality.

> The only reason why laypersons consider email to be non-repudiable is because of additional protocols like SPF and DKIM that were implemented after the original spec

You really think that laypersons have any idea of what DKIM is?

> But the world would be worse off, not better.

That's the whole point of this discussion. You seem to be arguing that the world would be better with non-repudiable email. But then I ask how many disputes have been resolved with DKIM and you have no idea. So basically your argument has zero basis in reality.

You're asking for every email user to have non-repudiation enforced unwillingly to them in every email they send so that someone maybe someday may solve some imaginary dispute with Amazon by using DKIM.

You do realize that email is older than DKIM? And that commerce existed before emails? You don't need DKIM to solve the issues you've pointed out.

Again: How many disputes like that have been resolved with DKIM?

You can dispute that without DKIM.

How many disputes like that have been resolved with DKIM?

You didn't answer it. In which scenario Amazon would deny sending an email and you would be protected by DKIM?

Then digitally sign it. Sign and scan it. Do not require signing every single email you send to protect 0,1% of them.

Why do you need Amazon to digitally sign a contract?

So maybe digitally sign the contracts instead of unwillingly sign every single email you send?

Sure. So why do we need DKIM to authenticate contracts?

I meant: authenticating a contract via email. I guess you sign and scan them?

Sure. But what authenticates the contract? Do you sign and scan them?

So... no need for DKIM

It's still a terrible idea...

We could catch a lot of criminals if we every OS had a backdoor that the police could access. So, are you in favor of that?

Good luck arguing that Gmail forged and signed an email from you.

Entering an contract via an email is a ridiculous idea from the start.

Exactly, downvotes hurt so much!

It's the opposite, really. It improved a lot after the heartbleed issue.

If one implements ECDSA, but does not follow SECG, one is also doing it wrong on multiple levels. Yet here we are.

That simply does not work in the real world. Also, why does this only applies to crypto? A RCE vuln can have a much larger impact than mishandling cofactors. Should we have canonical implementations of every piece of software imaginable?

It's difficult to assess one's "comfort" with the math. I've been working with crypto for more then 10 years and I wouldn't say that I'm perfectly "comfortable" (e.g. the Ristretto stuff). Should I stop working with it?

> malleability is not one of them, if one is following RFC 8032

This is like claiming Weierstrass curves don't have any problems if you follow the NIST/SECG standards. The whole point of the "SafeCurves" it to be easier to get them right, but you can still get them wrong.

That's a good example of how a "SafeCurve" caused a vulnerability that wouldn't exist in Weierstrass curve.

But many smart people made many such mistakes in the past. If we gatekeep it to much then we won't have anyone left to implement crypto.

> Montgomery curves work well with the montgomery ladder, which is easy to use in constant time, and that any 32-byte string is a valid public key for ECDH.

You can also have Montgomery ladder an a 32-byte encoding with Weierstrass curve, even though it would be slower.

> The point of ristretto, and its precursor/similar project decaf, is to preserve group structure while using these curves, and also eliminating small subgroups.

Exactly. Because we are stuck with all these cofactor issues. Not to mention how clamping also "contaminated" EdDSA.

Exactly. Yes, it's still not as efficient... but it feels to me that if they were found before and were "marketed" as Curve25519 was, we would be using them instead.

There were always more efficient formats (binary curves, extension fields) but they never caught on, so efficiency isn't everything.

From a cursory reading, shouldn't that paper compare timings with a Ristretto implementation? The overhead may be small but must be measured for a fair comparison.

It's good to know that implementing Ristretto is much easier than understanding it - that website is very intimidating ;) I need to study it more.

It's sad that efficient complete formulas for Weierstrass curves were found only after Curve25519 was well established. Now we are stuck with all these cofactor issues. Ristretto is nice but so terribly complex: https://ristretto.group/details/isogenies.html

Subject Public Key Info is just an Algorithm Identifier and the public key. The Algorithm Identifier is an OID and the parameters (ECParameters when using EC keys). It's these parameters that can contain the custom EC domain parameters.

The certificate signature is preceded by another Algorithm Identifier that specifies the signature algorithm (and the parameters), and so it seems that Microsoft is using this value instead of the parameters in the signer certificate Subject Public Key Info?

Yes, and my point is that the "fear of becoming the next Venezuela" is purely paranoid and has no basis in reality.

> t seems to me that mainstream media was constantly attacking Bolsonaro during the election, so may I ask what is your evidence for claiming media wanted a far-right government?

It wanted a right-wing, not far-right.

You would just need to read what the media published at the time. There was non-stop attacks on the PT government and talking about the "crisis" which wasn't nowhere as bad as they painted. This distorted people's view of the economic situation, which fueled the anti-PT sentiment: https://www.redebrasilatual.com.br/economia/2015/06/pesquisa...

See also how the media kept talking about the crisis even when talking about stuff going well: https://www.pragmatismopolitico.com.br/2015/07/apesar-da-cri...

Also, you only need to study a bit of Brazil history to understand that Brazilian media has always been right-wing.

The fact that the media attacked Bolsonaro does not contradict this fact. When you have someone who does so many stupid things you can't help reporting them.

In 13 years of PT government, Brazil became nowhere near "becoming the next Venezuela".

Most of the anti-PT sentiment was fueled by the media, which wanted a right-wing government back. It spectacularly backfired since Bolsonaro is anti-media.