You implied you weren't a fan of capital and compute driving math. How would you feel about a result that required 1200 hours of time on a powerful mainframe computer?
One thing that wasn't obvious to me or adults around me when I was younger: most laws define whatever acts a law punishes as individuals commiting to it, not as situations manifesting anyhow. It's not a murder just because someome died hit by a bullet you fired, but you have to have personally decided to kill that person leading to their death[1][2].
OpenAI's LLMs are not humans, and neither is the company. So by this logic, I think there's a chance that nobody committed a crime by hacking Huggingface, and also the chance that a lot of military and police organizational orders become illegal if OAI's doings would be illegal.
IANAL and all I have is a bucket of popcorns, though.
1: not a meaningful defense in a real trial, also gross negligence exists
2: this also explains insanity defense; if you were so out of your mind that you could not have held such a thought, it is considered out of scope for justice systems
Neither are guns. Which is why we punish the person shooting the gun and not the gun.
Industrial equipment, which is how i would classify LLMs, hurting people is nothing new. The relevant questions are:
- did someone intend it to happen?
- was someone negligent in taking reasonable steps to prevent something foreseeable?
The justice system doesn't punish people for legitimate accidents. e.g. if you are shooting at a shooting range, take all reasonable precautions, but someone was hiding behind the target, you are probably not guilty even if you shoot the guy.
As far as openAI goes, the logic is the same. The question is, was it intentional, was it unintentional but reasonable precautions weren't taken or was it truly an accident?
I mean, they are going to be at least culpable for gross negligence, but who made the decision might become an interesting point of discussions(mainly in deciding precisely how they should be punched in their face and less in whether they should be at all).
There is an even more fundamental reason why FHE cannot realistically be used for arbitrary computation: it is that some computations have much larger asymptomatic complexity on encrypted data compared to plaintext.
A critical example is database search: searching through a database on n elements is normally done in O(log n), but it becomes O(n) when the search key is encrypted. This means that fully homomorphic Google search is fundamentally impractical, although the same cannot be said of fully homomorphic DNN inference.
There has been a theoretical breakthrough that makes search a O(log n) problem, actually, (https://eprint.iacr.org/2022/1703) but it is pretty impractical (and not getting much faster).
Good point. Note however that PIR is a rather restricted form of search (e.g., with no privacy for the server), but even so, DEPIR has polylog(n) queries (not log n), and requires superlinear preprocessing and a polynomial blowup in the size of the database. I think recent concrete estimates are around a petabyte of storage for a database of 2^20 words. So as you say, pretty impractical.
While not mentioned by the author, there is an alternate reason why finite field DH can be seen as a special case of ECDH, kind of: namely, there exists special elliptic curves (actual, smooth projective curves) that do have an efficiently computable endomorphism to a suitable form of the multiplicative group, via pairings. This is in essence the MOV attack against the XTR cryptosystem. That doesn't fit neatly in OP's framework, though, because the map isn't a morphism of algebraic groups (it is efficient for other reasons), and it is cheating a little bit, because the inverse map isn't efficiently computable.
Another point that the author glosses over a bit is that higher dimensional abelian varieties offer other instances of DH that are genuinely different from ECDH, and that are occasionally useful (mostly the case of Jacobians of hyperelliptic curves of genus 2). There isn't really a trick to make an arbitrary hyperelliptic curve DH/abelian variety DH instance a special case of ECDH: if anything, the relationship would be in the reverse direction.
Elligator is only tangentially relevant to the hashing problem. If "doesn't have a problematic structure" is understood in a weak sense, then this was already solved by Shallue and van de Woestijne almost a decade prior to the Elligator paper. And if it is understood in the stronger sense of indifferentiability, then Elligator by itself doesn't actually fit the bill, and you need something like the Brier et al. approach or SwiftEC.
The steganography stuff is the only actually novel contribution of the Elligator paper.
Perhaps it's a bit more than tangentially relevant? Yes, SW[U] predates it for hashing, and Brier et al builds indifferentiability on that. But Elligator2 is simpler and faster, and also works with Brier et al, though it only supports even-order curves. As a result, Elligator2 is specified in RFC 9380 along with SW[U], and has fairly broad implementation.
Also yes, SwiftEC is faster than Elligator2 + Brier et al, at least if Jacobi symbols are fast with your parameters/hardware. But you can do something very similar to SwiftEC with Elligator2. This is simpler than SwiftEC and probably still faster, and was published earlier (https://eprint.iacr.org/2020/1513).
In that spirit, my pet "a monad is a monoid in the category of endofunctors, duh"-style one-line explanation of the Fourier transform is that it's just the decomposition in the common (Hilbert) eigenbasis for all translation operators. It makes it surprisingly clear (to some) why it is a both natural and important construction.
Same, but it's only natural after studying inner product vector spaces. Also being comfortable with some calculus is needed to be able to overlook the technicalities of this construction and focus on the actual idea.
A map of algebraic curves is not a special case of a map between two sets. There aren't really source and destination sets to speak of. The fact that it is given by polynomials really is a definition.
The moral "justification" of the definition is something like "algebraic geometry is precisely the study of such objects" or "we want definitions that are stable under ring base change, and this implies polynomials", etc., but we don't formally need to justify definitions.
[One could take a different route to defining those things, in which this becomes a theorem instead of a definition. For example one can define algebraic curves over a field k as contravariant functors from k-algebras to sets satisfying certain additional properties, and then maps of algebraic curves are natural transformations between those functors. The fact that they are given by polynomial equations is then a theorem. Just stating the "additional properties" for a curve is a rather daunting task, though, unfortunately.]
The hardness of discrete logs over fields doesn't have much to do with the hardness of elliptic curve discrete logs. At this stage, I don't think we have any evidence that curves over binary fields are less secure than over prime fields, especially for cryptographically relevant curve sizes.
(The situation is different for pairing-friendly elliptic curves, of course, but that's a different kettle of fish).
