I went to give Crixet a try, and there was a AI assistant in the editor. I looked in the settings to turn it off and the setting to do so said "I prefer my ignorance handcrafted, organic, and 100% human-made."
I’m wondering what’s the proper way to draw Venn diagrams.
I’ve seen that Graphviz has a “nice to have” mention about them, and there are a few simple JS libraries - mostly for two sets. Here’s also my own attempt using an LLM [1].
But maybe someone knows a more general or robust solution - or a better way to achieve this?
In the future, I’d like to be able, for example, to find the intersection between two Venn diagrams of three sets each etc.
the comments here https://news.ycombinator.com/item?id=45742907 have some discussion about projects that take a "focused algorithm for various different diagram types" approach vs graphviz's one size fits all approach. worth checking to see if any of them do venn diagrams.
It would be premature to review now because there are some missing features and stuff that has to be cleaned up.
But I am interested in finding someone experienced in Zig to help the maintainer with a sanity check to make best practices are being followed. (Would be willing to pay for their time.)
If comptime is used, it would be minimal. This is because code-generation is being done anyway so that can be an explicit alternative to comptime. But we have considered using it in a few places to simplify the code-generation.
There are many other so-called models of computation that are useful for representing ideas such as actor models, abstract rewriting systems, decision trees, and so on. Without them, you might feel that something is missing, so relying on assembly alone would not be enough.
I found out about milk.com when I was thinking about how to make an Android app completely from scratch (assembling DEX bytes from zero, kind of like writing an assembler for the Dalvik VM). That’s when I came across the author of the DEX format, Dan Bornstein — and I was surprised he actually owns a domain like that.
There is an existing concept called an exokernel. Moreover, I think Zig could be very suitable for this, because it already encourages passing allocators to functions to make memory allocation explicit. Recently, I/O has been (and is still being) reworked in a similar way.
Just wondering — has anyone come across a course or resource that explores how cryptographic systems are built up from smaller building blocks?
Like, using something like SageMath for algebraic structures, a prover like Lean to verify properties — to get a feel for how things actually fit together.
There's something cool about trying to reimplement known standards just to understand them better (with the usual "don’t roll your own crypto" warning, of course). By the way, it would be nice to have a kind of sandbox for the more formal path to explore how to build my own SP-network, prove that the Decisional Diffie-Hellman assumption holds or something.
When I learned crypto 5-10 years ago, it turned out that a lot of "building blocks" are mostly hacks. Looking back from 2020s we see that some of the standards that we use for the last 20-30 years can in principle be thrown out of the window (they can't for compatibility reasons, though) and replaced with much cleaner and more universal replacements.
If we do not talk about modern exotic stuff (post-quantum crypto, zkSNARKS, homomorphic encryption), the 99% of everyday cryptography is based on two building blocks:
1. Symmetric crypto for ciphers and hash functions.
2. Algebraic group with "hard discrete log problem" for key exchange, signatures, asymmetric encryption and simple zero-knowledge proofs.
Historically, these two categories are filled with a zoo of protocols. E.g. AES is a block cipher, but SHA(1,2) is a hash function.
Today, you can roughly achieve everything of the above with two universal building blocks:
- Keccak for all of symmetric crypto: it is suited both for encryption, hashing, duplex transcripts for ZK protocols etc.
- Ristretto255 group based on Curve 25519: for diffie-hellman, signatures, key derivation, threshold schemes, encryption and more.
The problem is that none of the described features is implemented in a turnkey standard, and we are still stuck using older crypto. Heck, even Git is using SHA-1 still.
Then, after you have your building blocks, there are more hairy stuff such as application-specific protocols: TLS, Signal, PAKE/OPAQUE, proprietary hardware security schemes for full disk encryption and access controls etc.
>Keccak for all of symmetric crypto: it is suited both for encryption, hashing, duplex transcripts for ZK protocols etc.
Unfortunately, Keccak and sponge constructions in general are inherently sequential. Even with hardware acceleration it heavily restricts possible performance. For example, AES-CBC encryption is 4-8 times slower than AES-CTR on high-end CPUs with AES-NI available. VAES makes the difference even bigger. Algorithms like AES-GCM, ChaCha20, and BLAKE3 are designed specifically to allow parallelization.
How much does the lack of parallelization matter in practice though? Sure, AES-CTR can be parallelized, but the authentication function you're probably pairing it with likely can't. And in a lot of cases I'm aware of where encryption parallelism is important for performance (e.g. line-rate VPN encryption), you can achieve parallelism for the operation as a whole without achieving stream based parallelism. In the VPN example, even if you can't encrypt all the blocks in a single packet in parallel, you can probably achieve just as much parallelism speedup by encrypting multiple packets in parallel.
> Unfortunately, Keccak and sponge constructions in general are inherently sequential.
Couldn't you simply using BLAKE3 instead? To my knowledge BLAKE3 exactly was designed to solve this "parallelism problem" by combining the "cryptographic ideas" of BLAKE2 with the binary tree structure of Bao (the latter was designed to make the hash construction easy to parallelize).
Fwiw I don't think there's anything inherently sequential about the Keccak permutation itself. KangarooTwelve is a fully parallelizable hash built on Keccak. (Though they did use the sponge construction on the XOF side, so that part is serial.)
I meant the absorb and squeeze part. The permutation itself (or more specifically its round) could be efficiently implemented in hardware, but you can't mask latency by parallel application of the permutation. Yes, KangarooTwelve is an improvement in this regard, but the grandparent was talking specifically about Keccak/SHA-3.
Sorry for lack of clarity, but i was saying “Keccak” and not “sha3” for that specific reason: it’s a permutation building block suitable for a whole range of constructions - cshake, kangaroo etc. sha3 specifically is an overkill and unnecessary imho.
CShake128 is much better replacement for hmac and sha512 in (zk)proofs, while Kangaroo for things like FDE and massive volumes of data.
I'm absolutely clueless about crypto, isn't there also a trade-off between being mathematically superior and well optimized in software/hardware implementation?
The tradeoff is not that simple (I wish it was :-).
Usually it goes like that: someone made something useful optimised for a specific use-case with certain time (or competence) constraints, within a total lack of decent alternatives. Then people adopt and use it, it becomes the standard. Then people want to do more things with it, and try to build around that thing, or on top of that thing and Frankenstein monsters get born and also become standard.
If you start from scratch you can do a crypto protocol that is both better designed (causes less UX pain and critical bugs) AND performs better on relevant hardware. Also do not forget that performance is easily solved by hardware: Moore's law and then custom hardware extensions are a thing.
Example: Keccak is so much better from the composition perspective, that when used ubiquitously you'd definitely have ubiquitous hardware support. But if everyone continues to use a mishmash of AES and SHA constructions on the pretext of "Keccak" is not as fast, then we'd never move forward. People would continue building over-complicated protocols, bearing subpar performance and keeping the reputation of dark wizardry inaccessible for mere mortals.
> Also do not forget that performance is easily solved by hardware: Moore's law
"Just write slow algorithms, hardware will eventually get faster" doesn't really work when talking about performance implications now. If the hash algorithm used million of times doesn't perform on current user hardware, then the algorithm is simply not a good fit.
> and then custom hardware extensions are a thing.
That's the kind of trade-off I eluded to as well. As a developer of a tool (e.g. git), I'd pick hash algorithms that do have hardware extensions on the most common hardware and not use something, that may eventually get hardware extensions.
I guess developing such protocols right now for the future might still be advisable, but it seems odd to critic software that use well-optimized algorithms and fulfill the requirements.
This is a justification that was made up after Git came under increasing criticism for its poor choise of a hash function after the shattered attack. It was already known that SHA-1 is weak before Git was invented.
The problem is... it doesn't line up with the facts.
Git has been using SHA-1 hashes for signatures since very early on. It also has claims in its documentation about "cryptographic security". It does not rigorously define what "cryptographic security" means, but plausibly, it should mean using a secure hash function without known weaknesses.
"So that was one of the issues. But one of the issues really was, I knew I needed it to be distributed, but it needed to be really, really stable. And people kind of think that using the SHA-1 hashes was a huge mistake. But to me, SHA-1 hashes were never about the security. It was about finding corruption.
Because we’d actually had some of that during the BitKeeper things, where BitKeeper used CRCs and MD5s, right, but didn’t use it for everything. So one of the early designs for me was absolutely everything was protected by a really good hash."
That's a valid point. However, modern hardware and crypto algorithms are fast enough that it pays off to have "do it all" protocols, with as little tradeoffs as possible.
Example: Git users do need both corruption protection AND secure authentication. If authentication is not built in, it will have to be built around. Building around is always going to be more costly in the end.
Unfortunately, 20-30 years ago considerations such as "sha1 is shorter + faster" were taken seriously, plus all the crypto that existed back then sucked big time. Remember Snowden scandal in 2013? That, plus Bitcoin and blockchains moving towards mainstream brought about review of TLS, started SHA-3 competition. Many more brains turned to crypto since then and the new era began.
If this were true, then wouldn't MD5 have been the better choice?
Also, SHA-1's preimage resistance (which still isn't broken) is necessary for the security of signed commits, regardless of the hash function used for the signature itself, since a commit object references its tree and predecessor commit by their SHA-1 hashes.
the types of arguments and proofs used in cryptography are notoriously difficult to mechanize, a little bit of lean isn’t going to go get anywhere close to stating a security property.
Just to add to the above for clarity a proof that key based encryption isn't reversible requires a proof of P!=NP which hasn't been done.
That may surprise people but we have no proof of the robustness of the encryption we use. In fact it might not work! Consider a one time pad for really extreme security needs. One time pads do have a proof (see the work of Shannon).
Shor's algorithm suggests that a lot of encryption doesn't actually work, but of course it requires a quantum computer that hasn't yet been built, and may not be practical to build, so fingers crossed. At least there are quantum-resistant encryption algorithms, and OTPs are still provably secure like you say.
On "finger's crossed" - I think it's important to say that the majority of web traffic has switched over to PQC algorithms for key exchange that are not susceptible (thanks Cloudflare). We're not close to building a machine suitable for running Shor's in a practical sense, so even potential "store now, break later" attacks are now kinda pointless. Things like SSH keys are trivially revokable and often have enforced expirations, so they're not really a viable attack vector anyway.
The symmetric encryption used for the vast majority of actual encryption has always been safe. Grover's algorithm does not scale appropriately (exponential on key length) unlike Shor's and cannot be parallelized. Worst case, AES-128 becomes as week as AES-64. So we bump it to AES-256 and we're back at the same difficulty as before (impossible). There's a degree of confidence this will always hold true.
What you described is pretty much exactly how modern provable cryptography field works today. Reduction to assumptions about certain primitives and constructing the boundaries of security given such assumptions.
E.g. "Assuming AES block cipher is a perfect pseudorandom function, prove AES-GCM construction is secure up to certain number of messages"
There is an approach that I like and I think allows one to compress quite a few different description models from different domains. Take a look at this image from wikipedia: https://commons.wikimedia.org/wiki/File:Systematik-Philosoph... You see "Theoretische" and "Praktische" philosophy in the rectangle with a diagonal which probably could mean that you can sort something based on the relation between matter and information, where something is more practical and less theoretical (say 30% practice and 70% theory) add a stimulus-response diagram at the bottom and various information-material circuits inside that allow you to show how something is transformed.
There is an development of this idea from some author which leads to something like https://imgur.com/a/AmF7AJe and currently the author tries to find the connection between syllogistics, Boolean algebra, Euler-Venn diagrams, and more.
You can take a look at https://www.youtube.com/@Syllogist/videos
Many of the recent videos have English subtitles
It's hard to describe the whole idea at once, but maybe someone will have the courage to learn something from it.
This is the problem I have with any study of "systems". It all just feels like overly ornate verbiage for "hey, this thing kinda looks like this other thing if you squint". It's very difficult to distinguish that imgur image from complete Time-Cube-level quackery. "Volume (more than 3 points) <==> deep cause-and-effect relationships <==> trivalent linguistics (he gives the book to his brother)" ... really? Is this really helping humanity understand anything?
In some ways it’s my fault that I didn’t present it very well, but perhaps this should be taken less strictly, as something of a source of inspiration, like some kind of painting. Someone can then take it more strictly and make some kind of Curry-Howard isomorphism, or from the idea that the information concept of a file corresponds to the material concept of force, something in dimensional analysis can grow.
That is, it may be less formal at the beginning, but then a craftsman may be found who will do everything quite strictly.
Nevertheless, now this author is developing the theory of syllogistics and there are quite practical results, for example, that the logic textbooks for lawyers can be translated into boolean algebra and made more precise.
> Writing is an effective way to achieve this because you don’t need to find another person who wants to hear about your idea
Shouldn't you still have some sort of idea of the audience you're writing for? And for example, I am more accustomed to seeing myself in different spheres of life, where I behave differently, is it possible to combine all of this?
If your goal is publishing something, I think it's great to keep an audience in mind. But if you're struggling to get a writing habit going, forget about all that stuff and just write. Thinking about all that stuff is why it's so hard to get started! It's the root of writer's block. I talk about that a bunch in the guide.
That’s usually the same advice I give to people when they ask the question in the context of personal blogs: just write. About whatever. Anything you find interesting to you is a worthy subject.
reply