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
You're demonstrating the very vector into internet dudgeon that I'm talking about.
Yes, commenters do bear some responsibility for the subthreads that come from their comments. These things are pretty predictable, after all. (To be fair, I probably came down on cryptohacks a little too harshly—it's an occupational hazard, especially after hours of cleaning up shit—sorry, cryptohacks. But the principles hold good.)
I don't agree that it's cowardice to go for substantive discussion rather than people screaming at each other and losing their minds off-topically. I'd say it takes some courage to do that. What strikes me as closer to cowardice (not the best way to put it, but we'll go with your word) is defining one side of these bloodbaths-in-a-teacup as virtuous and the other side as "garbage people", instead of facing the truth that they are co-creations.
Btw, I like Graeber. I personally protected his account on HN and made sure he got to say everything he wanted to here. I think his death was a loss for intellectual life—he may not have been a meticulous scholar but his creativity is not the sort of thing that comes along very often. I think making a big deal out of that one lame sentence about Apple is an example of the stupidest sort of internet battle. At the same time, of course he was an ideological writer and of course that paragraph is ideological rhetoric. That it also contains facts doesn't change that; that's what good rhetoricians do.
Nor is there anything wrong with that paragraph in its original context in a book—a genre where the volume knob needs to be turned up quite a bit at times, and generally wielded with a lot of variation. But McLuhan got it right, the medium is the message, and copy-pasting that paragraph into an internet thread on an inflammatory topic is definitely flamebait. We're trying to learn how to avoid that here because the threads it produces are repetitive, and therefore tedious, and therefore turn nasty. That's really all I'm saying—anything else people are adding onto it (such as secret political agendas, positions on Haitian history, or whatever) is imaginary.
I don't know about your country, but in mine (The Netherlands), it is a completely and utterly valid way to enter a contract.
Actually, you are free to enter a contract in any way possible. It is vormvrij (translated: form-free). Excluded is the purchase of a house, as far as I know. But for the rest, you are free to come to an agreement via WhatsApp, Facebook, email, or a scrawl on a piece of paper.
Because, without DKIM, a dishonest party can repudiate the email. Just as a written contract is superior to an oral contract, a non repudiable written contract is superior to a repudiable written contract.
> In which scenario Amazon would deny sending an email and you would be protected by DKIM?
You want a specific scenario of a dispute between a vendor and a customer? Ok. Let's say I email Amazon's customer support to ask them if a specific order is going to incur customs fees, and the Amazon representative emails me back that the order is not going to incur customs fees. Then I make the order, and to my surprise, I do have to pay custom fees. I contact Amazon to ask them to compensate me for the fees, but Amazon now claims that they are not responsible for custom fees. At this point I would be protected by a copy of the email where they claimed that I would incur no customs fees. If I can demonstrate to Amazon that I have proof of their false claims, prior to the purchase, they will be inclined to compensate. If they refuse to compensate, I can (depending on jurisdiction) take my claim to small claims court and present my evidence there. In this case it's unlikely for anyone to actually validate the DKIM signatures, but it does matter whether email is generally considered to be non-repudiable. If you run a campaign to make email repudiable, and make sure people should know email is repudiable, then this email will be less convincing as evidence.
If you run a campaign to make email repudiable, and make sure people should know email is repudiable, then emails will no longer be convincing evidence.
The original email spec doesn't provide any security against forgeries. The "sent from" field in email is about as secure as the "sent from" field in physical letters. 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. Without these protocols email would be considered repudiable, which OP considers to be a preferrable outcome.
> And that commerce existed before emails?
Yes, and? I'm not claiming that all commerce would come to a halt immediately if this campaign for email repudiability was successful. Of course commerce would continue to exist. But the world would be worse off, not better. There would be slightly more disputes, and dishonest parties would increase their chances of defrauding honest parties.
> You don't need DKIM to solve the issues you've pointed out.
Are you alluding to hypothetical alternative protocols for authenticating contracts? If you can make the world move off from email, that's great! Email is horrible! But if you can't make people move away from email, you won't make the world a better place by making email less secure.
> Again: How many disputes like that have been resolved with DKIM?
How many? As in, you expect me to have statistics on it? Are we pretending that when people resolve disputes, they mark their disputes in some kind of global database that we can query for statistics? You're not making any sense.
> 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 really think that laypersons have any idea of what DKIM is?
The layperson doesn't have to understand the intricacies of email protocols, it's enough that they consider email to be non-repudiable. This is why a copy of an email typically suffices as "proof" of a contract. If you successfully run a campaign to make email repudiable, then laypersons will no longer consider email to be non-repudiable, and emails no longer suffice as "proof" of a contract. If you disagree with something I said here, can you specify which part it is exactly that you disagree with?
> You seem to be arguing that the world would be better with non-repudiable email.
Yes, the world is better off now, at a time when laypersons consider e-mail to be non-repudiable, compared to a hypothetical future where this is no longer the case.
> 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.
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"? This doesn't make any sense. If I said that "the existence of courts prevents vigilantes", you could say the same thing: "well what's the exact number of times that the existence of courts has prevented vigilanteeism? ha! you don't know the exact number! your argument has zero basis in reality then." We could apply your logic to many other scenarios: what's the number of times that existence of guards has prevented prison breaks? What's the number of infections prevented by vaccines? We don't know the exact numbers for any of these things, and yet we can logicly deduce that courts prevent vigilantes, guards prevent prison breaks, vaccines prevent infections, and DKIM prevents breaking contracts.
> 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.
Laypersons already believe that emails have non-repudiation property. People are free to use secure messengers to communicate privately. When people choose to communicate with email, they are choosing non-repudiation over privacy. You are the one who is asking to change e-mail protocols so that they would work differently than people currently expect. I'm the one saying e-mail should work like people expect e-mail to work.
> 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.
We're discussing a campaign whose goal is to increase the deniability of email. When you say things like "they will still believe [email is non-repudiable] if Google discloses its DKIM keys", you're essentially saying that this campaign will not be successful in its ultimate goal - that even if the campaign manages to get Google to periodically rotate and publish their DKIM keys, it will not achieve the desired effect of increasing the deniability of email. So, you're saying that this campaign is a fool's errand?
I don't have a strong opinion on the chances of success that this campaign has. What I am saying is that if the campaign was successful in increasing the repudiability of email, that would make it easier for people to repudiate emails that they've sent, and that would be a bad thing in the context of resolving disputes. Do you agree?
A signed and scanned PDF is also commonly used, same as an old-school fax-based contract where you sign and send it back. But, yes, the DKIM definitely does not matter for contract purposes.
I had something similar. My comment actually had a lot of upvotes, but dang rebuked me for being inflammatory. Really made me rethink whether I am writing something to share knowledge or just to anger someone.
No. But I trust that dang will roll out self references to his old comments circling in an infinite recursion to explain what he means when he is scolding. Most mods online don't even do that. He might be wrong sometimes as all humans will be but you can ask him to clarify.
He has to regularly see multiple sides of the site. HN is pretty diverse depending on what you click and as such, I do think he is less biased in some ways we are and more biased in others as he work as a mod for hn.
Downvotes don't hurt, but I wonder how many people here would stick around if HN forced all users to use their real names. How many people would instantly self-censored or completely change the way they share opinion and respond.
A lot of us would. I figure that in 10 years clever AI systems will be pretty good at attaching pseudonymous accounts with lots of posts to real people. That's why I put my Github with my real name in my profile, to remind myself.
I use my real name and censor myself heavily. Pseudonymous speech is much more honest, but I'm not prepared to quietly defy a court order to protect a pseudonym from legal discovery if an employer gets sued. And now apparently journalists might attack your opsec…
What's your point? 'Think before you speak' and 'speech has consequences' isn't exactly a new notion. Under a throwaway account on here I just write whatever pops up in my mind, when I co-author a paper under my and my colleague's real life names that's going to be read and cited, everyone triple checks everything so that as few innacurate or dumb things get published. How is this new or shocking in any way?
The thread of comments started with the mention of 2 papers discussing how people are reluctant to sharing their opinion because the "social cost" may be too high.
A reply comments on how HN is somewhat similar. People censoring themselves due to fear of being downvoted. I pointed out that IMO downvotes are a very mild sanction and truly, people don't need to censor themselves on HN, but the true cost would come if everyone had to comment with their real names.
> 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.
Daniel J. Bernstein et al's original paper (High-Speed High-Security Signatures), didn't feel the need to take as many precautions as RFC 8032. For instance, they didn't care about malleability.
You seem to think they should have. May I ask why?
I'm interested in Thai's response to this question too, as I would be in any comment anyone managed to solicit from him about this topic, but an easy point to make here is that Bernstein was himself involved in RFC 8032, at least as a reviewer and contributor to the process, as you can quickly learn by reading the CFRG mailing list.
Oh, so DJB changed his mind then? Makes sense considering the application of EdDSA beyond signatures (I've heard malleability is a problem with zero-knowledge proofs, but I haven't studied that subject).
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
Have you seen Curve9767 [0] ? Short-Weierstrass, prime-order, but the implementation does not use the complete formulas. Competitive performance, on the ARM Cortex-M0+ at least.
> efficient complete formulas for Weierstrass curves were found only after Curve25519 was well established
Assuming you are talking about the Renes–Costello–Batina formulas, they're complete, but not necessarily efficient. According to [1], optimized short Weierstrass with the complete formulas is still 1.5 to 3 times slower than Curve25519. I imagine the numbers won't be much better for Edwards25519, either. There's definitely a ton of potential for a better complete addition formula on Weierstrass still left.
> Ristretto is nice but so terribly complex
Ristretto is nice, terribly complex, and you don't actually need to care about the conceptual complexity. As an implementer, your only job is to execute the explicit formulas in section 5 of the Ristretto website. You do not have to be able to follow the hard math (just how you do not have to be able to follow the hard math involved in making the explicit formulas). Plus the entire thing can be trivially constant-time given a constant-time selection primitive and constant-time field arithmetic. It's not that much more difficult than doing regular point compression on your own.
>Ristretto is nice, terribly complex, and you don't actually need to care about the conceptual complexity. As an implementer, your only job is to execute the explicit formulas in section 5 of the Ristretto website. You do not have to be able to follow the hard math (just how you do not have to be able to follow the hard math involved in making the explicit formulas).
I don't think one should blindly follow an instruction without understanding why in any fields, let alone in crypto where a small, subtle difference can make or break it. Also, understanding crypto requires less math than inventing (and attacking) crypto, so it takes some effort, but it's doable even for hobbyists. If the math makes one uncomfortable, maybe one shouldn't try to roll their own crypto for production use in the first place.
Case in point: the author of this article that we're commenting on made a deadly mistake because they did not understand the math behind point conversion between Ed25519 and Curve25519 [1].
Below I also point out a mistake in their claim about malleability in EdDSA.
> Case in point: the author of this article that we're commenting on made a deadly mistake because they did not understand the math behind point conversion between Ed25519 and Curve25519
By the way, since you seem to work on Wycheproof: would you take a look at my pull request? The EdDSA test vectors would have saved me (and my users), but the front page didn't mention them, so I didn't know they even existed for over a year. I initially believed you were concentrating on other, even more error prone, primitives.
Others might be in my position: letting bugs through because they think Whycheproof is not relevant to their project. A pity, considering how amazing Whycheproof is (I'm now systematically integrating any new test vector I learn about).
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?
Maybe we should gatekeep it so much though. As long as there exist at least two people capable of implementation per programming language (one to implement, another to audit), there will only ever be one, single, canonical implementation and there's no way around it. It is not and should not be an inherent right to be allowed to implement cryptography (that is put into production or made publicly available). The gatekeeping is there for a reason and it's important that we uphold it. Fewer implementations means that more people will be focused on having to write and check less code overall. Patents could be used to help with this by only permitting one upstream implementation to exist, but that's now how they end up being used in practice, and that's ignoring the fact that patent expiry is impractically short (compared to copyright expiry especially so).
Gate keeping is a double edged, and somewhat blunt, sword.
First, some Maverick is going to ignore what everyone says and implement crypto for serious applications. Like yours truly.
Second, I've seen it go a bit too far when I implemented Argon2i: there was a discrepancy between the specs and the reference implementations, and the authors haven't corrected the specs. I figured this was because not enough independent implementers bugged them about that. (Now, 3 years later, the specs still aren't fixed, so maybe the authors are really really busy. At least but the issue is still open: https://github.com/P-H-C/phc-winner-argon2/issues/183 )
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?
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 not that complex once you have formulas for computing square roots. I've recently implemented it in TypeScript using bigints for browsers & nodejs. Quite readable & performant. See index.ts file here: https://github.com/paulmillr/noble-ed25519
Wish ristretto folks added the library to their website though.
> It's sad that efficient complete formulas for Weierstrass curves were found only after Curve25519 was well established
This is not the only motivating factor for curve25519. There is also: that 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.
> Now we are stuck with all these cofactor issues.
They are not a major problem for ECDH. If you are doing only ECDH and don't care about group structure, you can simply use the existing clamping mitigations.
The point of ristretto, and its precursor/similar project decaf, is to preserve group structure while using these curves, and also eliminating small subgroups.
> 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.
From what I can tell, they were trying to get it adopted as RFC, but then a couple more things popped up on the CFRG, so they're planning a new version[1]. It's been adopted by the CFRG officially[2]. I haven't seen any sign of when the next version may be out (which will be draft-irtf-cfrg-ristretto-00[3]), however.
I kind of hope they'll also add ristretto448 since RFC 7748 and 8032 include X448/Ed448, so that the draft has feature parity (and covers the h = 4 case properly).
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?
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.
> In 13 years of PT government, Brazil became nowhere near "becoming the next Venezuela".
Brazil has a a more diverse economy. Even though PT left Brazil in economic crisis, it surely wouldn't fall as much is Venezuela (which had an oil dependent economy when oil prices dropped dramatically).
I'm merely explaining the sentiment that took over the country and resulted in Bolsonaro being elected.
> Most of the anti-PT sentiment was fueled by the media, which wanted a right-wing government back
It 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?
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...
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.
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