1 sat \ 4 replies \ @027c352e45 20 Jul 2023 \ on: RANT: Cryptography and Algorithm Papers Should Use Code, Not Math Notation tech
I disagree.
Very occasionally, the authors of these papers will write code themselves in support of their proposed algorithm, which i think is fantastic.
The issue is that cryptography is, fundamentally, mathematics so it should use mathematical formalism to be unambiguous.
That doesn't mean mathematical formalism is a panacea; the field is rife with slight ambiguities in papers leading to terrible mistakes - for one example, look up the 'frozen heart' vulnerability.
But replacing mathematical notation with pseudocode, will not make that better.
Adding pseudocode, where it's relevant, otoh, yeah, that can be a great idea. But it makes more sense one layer up - when you write protocol specs. For exa.ple, there was a tradition of using pseudocode in RFCs for internet protocols, e.g. tls 1.0, rfc2246
Well, I don't write papers, I never could. But I can design a protocol and adapt existing functions and primitives and respect their proper usage as best I can surmise how to do it, and from the various histories of flaws previously.
I think the shortest path from idea to code is better than formality. Build the thing and then critique it.
reply
Sounds like the Eth approach. Build it, break it, fix it, repeat until you got something as ugly as Eth.
But I presume you're are not talking baselayer bitcoin security. LN allows one to experiment without risking breaking the baselayer. So I mostly agree with you that one should build rather than theorize.
To a certain extent though. Experimenting at the LN Implementation level (LND, etc) or even Umbrel level... going to fast, it shows that bugs there also can have big consequences. Nothing too bad until now, but I've seen a few where I was not totally sure of the outcome.
Following the LN mailing list, often times again a new idea is proposed by someone not too familiar with the topic. Then, an OG, with good math knowledge responds and explains why or why not that would be a good idea avoiding breaking things.
Anyhow, happy to have math guys and builders like you. Both of you are what is moving this field forward.
I'm just an observer for now, so my opinion is moot.
reply
Yes I do have a lot of sympathy for the 'build it concretely first, rather than just theorize in abstract papers' point of view. There's wisdom in that. But for some kinds of system, there can be dangers of insufficient analysis of attacks.
Building it first means you get eyes on it. Analysing it theoretically first means you might spot the attacks before they're executed against innocent users.
reply
At this point, my own protocol design is sponsored by one person so from a business/economic side of things, it's critical to get a prototype running so the hype train leaves the station and people with fat stacks can throw them at people with Ph.Ds and outstanding reputations as whitehat hotdoggers.
Academic formalism is expensive. For business you need it in as far as it creates trust in the product.
reply