I think it is due to the homotopy type theory book. There is an elegant connection between category theory and type theory. I guess most of the people submitting category theory to hacker news (or any graduate math) just do it to flex and seem clever.
The precise mathematical definition of obfuscation and what is considered obfuscation for an average software engineer are two very different things.
In fact, the article is only about indistinguishability obfuscation. What is mostly discussed in this thread is the notion of virtual black box obfuscation (VBB).
VBB has been proven to be impossible in the general case (see https://www.wisdom.weizmann.ac.il/~oded/PS/obf4.pdf). There are a few special programs where VBB is feasible, such as point functions, but in general in cannot be achieved.
Indistinguishability obfuscation (iO) means that if you obfuscate two programs that compute the same function, then you cannot distinguish them. Or put in different words, if you get two obfuscated programs, then there is no better way than random guessing (except for a factor that is negligible in some security parameter) to find out if they stem from the same original program.
I am much more familiar with the development in the chess world.
Since Deep Blue beat Kasparov in 1997, there was a lot of progress in the development and the architecture of chess engines. Back then, we did not have neural networks. A lot of the strategies of chess engines are now used by chess grandmasters. As an example, the value of the activity of pieces was underrated in contrast to the value of material.
As there are more generations of chess engines than go engines, it would be quite interesting to pull something similar off against them. My intuition is that it maybe works against Leela, as LeelaChess basically uses only neural networks (think alphago but for chess), whereas it should not work with Stockfish, as some parts of Stockfishs evaluation function are still adjusted by hand.
Users cannot be enumerated using the login, but using the signup. The author then argues that they should add the user enumeration function to the login.
This is similar to: The door is locked, but the window is open. And then consequently it makes no sense to close the door at all, as an attacker can sneak through the window.
Instead, the window should be locked as well, i.e., it should be impossible to enumerate users with the signup function.
Note that hashquines, i.e., programs that print their own hash when executed do not depend on the hash function being broken. In fact, they are a fun little exercise.
The magic to me is that the CPU glitches are caused completely on the software side. With dedicated hardware such as flying probe testers this attack is state-of-the-art afaik.
But glitching the CPU only with software, i.e., causing hardware bugs only with software is what really surprised me.
I would recommend "Seven Sketches in Compositionality", as it does not progressively get harder, but each chapter starts off very easily. So you can catch up, if you got lost.
Thank you for the answer and a big kudos for the project.
Regarding the memory violation, could symbolica deal with symbolic memory? Can it deal with symbolic files as input? How about syscalls with symbolic inputs? These are the main problems I had when I worked on my toy symbolic execution engine. If yes, you should definitely market these features.
Cool. I have a background in IT security and am sometimes doing symbolic (or concolic) execution on binaries instead of source code. So I may not be the target audience.
Nevertheless I think you should do a comprehensive list what your tool can detect and what not, instead of some examples. From the sample programs i learned that it can check two programs for semantical equivalence and can detect undefined behavior.
I did not get the example with the memory violation, as symbolica.h is not included in the code.
Additionally, your tool could create test cases that trigger the error, afaik.
Regarding the feedback for the user, as multiple others have mentioned, the running time is very long and thus a simple timer may not be sufficient. But I do not have an idea how to improve that.
I am not sure if you are working on the target program directly, or on the compiled binary. In the example with the division by zero, there is a print statement in order to stop the compiler from removing dead code. But I do not understand where you need a compiler, if you are working directly on C. On the other hand, when you are working on the compiled binary, then your tool is very similar to other symbolic execution engines, such as angr.
I am currently learning chess tactics using the Woodpecker method, i.e., a modified version of spaced repetition. The idea is to do chess puzzles over a fixed duration, say 4 weeks, and then repeat the same puzzles, each time aiming at halving the necessary time.
I cannot yet comment on its effectiveness, but Tikkanen, the author, used it to get from International Master to Grandmaster.
I never expected that one could process music so effortlessly, until I saw some of his videos. E.g., in some of his videos, he listens to a melody once and can then immediately play it on guitar or piano. If you want to dip your toes, I recommend starting with videos of the "What makes this song great" series.
The article is very light on details. I would have liked to have more information than just learning a new word.
That being said, I think it is valuable to be aware of why I don't read my books.
Currently, I am sometimes reading Baudrillard's "Simulacra and Simulation". Despite being a good book that has definitely helped me understand a novel viewpoint on postmodern society, it is written so dense that I can read no more than one of its essays per week.
Then there is "The five invitations". This book is about death and dying and how we can live so we do not regret anything at our deathbed. Reading it sometimes makes me uncomfortable. I do not want to be confronted with death. But then again, I am not the one to decide when I have to face death. Again, this leads to putting the book back in the shelf and reading it only sporadically.
And then there are a bunch of books which i stopped reading when I thought I got the gist of it or which were just not relevant to me anymore.
Don't bother with that large table at the bottom.