nneonneo

From TFA:

  Government subsidies in China — while 5 to 10 percent of Chinese automakers’ capital spending, estimated O’Donovan, compared to about 1.5 percent in Europe — are no longer the Chinese auto sector’s primary advantage. Chinese carmakers now enjoy deeper structural advantages from their enormous scale, dense supply chains, high factory utilization and automated production.

Several companies in China now tout their “dark factories” where they make or assemble many parts of their cars with no human labour at all. It’s likely that the larger Chinese companies are capable of undercutting European makers even without government subsidies or wage parity.

SO turned into a place that heavily favoured their experienced answerers over new answerers and askers. Admittedly, I fell into the former camp: someone with some excess time on his hands and an itch to answer interesting questions - and like most of the experienced answerers, I ended up being very disinterested in answering homework questions, “lazy” questions, and the like. “Downvote and move on” was the motto.

In hindsight, one thing we could’be done - as a community - was leave easy questions to be answered by new answerers. There’s still a lot of careful design to consider here - how do you avoid “broken windows” for newbies (and search engines), how do you moderate posts that the experienced users don’t/won’t interact with, etc. On the other hand, it would get those questions answered, give new answerers a chance to gain experience (and points) without getting beaten to the punch by some 100k’er, and generally reduce that air of unfriendliness and elitism that eventually permeated the site.

In any case, for better or for worse, I guess we have LLMs now. The real loss is the deep expertise embodied by all the answerers on SO. While 90+% of questions can probably be answered now by an LLM, it was nice to have a place where those remaining few questions could get a real, deep answer.

p=84491346121303840713246978535231635954643146756451201037561748571580203988423

q=82392744353585332429460820191121154258120959554076291572887591391377445536703

n=6961473881062880999817189307002435362675293718841800458853975151946795609411283948376850761685158526939121778595276868395992041449207352173613540433589369

e=1305276352699290187465722995062956630501617572282837586035120340990024176764584449553695476096002966088824142338449519554315283866861919281309484272012046

d=4

assert n == p * q

assert pow(pow(123456789, e, n), d, n) == 123456789

(This doesn't work for all messages `m`, so I agree with what you've said - d=4 is not a good choice. But it can work.)

“d=4” is a perfectly legal RSA private key. The corresponding public key would probably have a weird e (not 65537, the usual choice), but would otherwise be legal, and could have an arbitrarily large modulus n (thus appearing “secure”).

Note that p,q (the primes you’re thinking of) are not actually required for decryption. They enable you to calculate d, the decryption exponent, and also enable decryption-time optimizations (exponentiation with d_p and d_q followed by CRT recombination), but that’s optional. In fact, p,q can be computed from n, e and d.

1. Were these the only prompts tested, or are these selected comparisons? I note that prior work used other triggers, like Tibet, which are omitted here - were they not tested, or did they simply fail to show similar results?

2. This is an old model that isn’t very good at writing secure code in the first place; I’m not sure it’s an improvement to use a “westernized” model that still writes insecure code 50+% of the time. If this is a genuine issue, it should be demonstrable with later models and with models that are more secure-by-default.

> After Wayne's report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed - rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the 'first' 256 P384 keys.

Yeah that’s just oof. Not hard to imagine the kind of code error that could cause this, but hard to imagine that any serious vendor of cryptography hardware or software could make a mistake like this.

You’ve asserted several times in this thread that this is “LLM slop”. Having read a decent amount of math content on the internet, I’m not sure I quite agree, so I’d like to hear why you think it’s LLM slop?

For one, this article has (charmingly?) terrible math rendering, rather reminiscent of someone copy-pasting random pictures of equations from the Internet and supplementing them with Word’s Equation Editor or something. An LLM would have just dumped a pile of LaTeX and called it a day. For another, I don’t sense any of the usual writing tics that are suggestive of LLM writing. I don’t claim either of those are remotely definitive, but my personal feeling is that this was largely hand-written and aimed at a very introductory level (i.e. not the sort of level that will benefit from knowing about Riemann surfaces).

This article misses one of the most useful and deep representations for complex numbers: polar coordinates. There’s some bits in there about adding angles and such when multiplying, but it turns out these are “obvious” in polar notation.

A complex number can be expressed in Cartesian coordinates as (x,y) or x+yi. It can be expressed as polar coordinates as (r,theta). What’s the corresponding complex notation? Surprisingly, it’s r*e^(i theta), where the angle is taken in radians. It might seem really weird to see an exponential there, but it turns out that the exponential behaves like a trig function when given an imaginary exponent - to be precise, e^(i theta) = cos theta + i sin theta.

Now multiplication becomes easy: multiplying two polar-notation complex numbers (r1,t1) x (r2,t2) gives r1r2 e^(i (t1+t2)) following the usual rules of exponential arithmetic, i.e. (r1r1, t1+t2).

The complex exponential looks like a very strange notation at first because we’re all used to grade school exponents, but you can think of it as a function that takes an angle and produces a point on the unit circle. Feed it a continuous input, and it traces out an arc or a circle. sin and cos are merely the one-dimensional projections of this function.

Frequency becomes simply e^(i ft) where f is the frequency in radians and t is time - representing a point racing around a circle at a set speed. Multiplying two signals with different (complex) frequencies produces a new signal with the sum of their frequencies. With this notation, complex signals are the simple ones to understand - real signals are the “more complex” ones, as every real signal consists of a complex signal added to its conjugate.

The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers.

In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.

Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.

Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.

That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer.

It is, however, an incredibly cool demo of what the format is capable of. I'm not completely sure if an image format should be that flexible, but I'm impressed nonetheless.

It seems like the right thing they should do is discontinue new registrations but continue to honour existing ones (+ continuing to reserve any 2LD that has a 3LD registered on top). It’s a bit insane that they can decide to just terminate all existing 3LD registrations. One would hope that they’d at least continue to reserve the 2LDs for some period to avoid domain squatting, but this isn’t mentioned in the proposal and I doubt Verisign would graciously do so.