Have you attempted to kidnap the DA during a prisoner transfer on Lower Wacker, only to be thwarted by a vigilante? If not, I question your Chicago bona fides.
RSA is asymmetric crypto. This article is about symmetric cryptography. I expect LLMs will advance state of the art in factoring algorithms, considerably.
Perhaps, but it’s still trivially easy to increase the difficulty of factorization problems on classical computers, We need a machine that can run Shor’s algorithm before integer factorization is practical and we’re still a long way out f M that.
A symmetric cipher is: ciphertext = data XOR key. XOR is reversible: plaintext = ciphertext XOR key.
If the key is a set of truly random numbers the same size as the ciphertext, then this is a one-time pad, and it is truly secure in the information theory sense. Nothing other than knowing the original randomly selected key values can decode the ciphertext.
But of course, it's hard to come up with terabytes of random numbers at the drop of a hat, and to share them securely with the other party. So symmetric ciphers use pseudo-random generation techniques, to iterate through many pseudo-random keys based on one original key. With PRNGs the "randomness" may have patterns and that is the opening for a break in the crypto.
Very, very briefly, most symmetric algorithms are block ciphers, meaning that their input are blocks of a fixed length in bits (plus a key), and their output is another block of the same length. Ideally, a block cipher with its key produces a random permutation of the input space into the output space, thus diluting the information and dramatically increasing (ideally maximizing) the entropy; what that means is that whether the input is just zeroes and ones in ASCII or fully random, after encryption it should be indistinguishable.
It pretty much is, except it's reversible. At the block level it meets the cascading requirement, and you can set it up to expand the output arbitrarily by padding the input with zeroes (thus also turning it into a PRNG).
There is already a mathematically secure algorithm for securing a message: One Time Pad. The problem is that OTP requires that the length of the key and the length of message must be the same, which is inconvenient for large amounts of data.
So the solution is to find algos that let you use a smaller key, but the side effect is that by pigeonhole principle, your keyspace is smaller than the message space, so it MUST be insecure. The trick is to make it so that it's only insecure enough that it's infeasible to break.
It's inconvenient for any amount of data, because it essentially begs the question; if you can securely transmit N bytes of key pad to a counterparty, just use that mechanism to transmit N bytes of plaintext instead.
It has the advantage that the key can be sent before the message is known. Think military battlefield. Your commander goes out to war with a CD, and then he can transmit messages like "we encountered the enemy". It would do no good to transmit "we encountered the enemy" before the war started.
There are only three programs where memory safety matters: HTTP server, browsers, and operating systems. In practice, really just browsers and operating systems. Memory safety schemes that don't work for those systems are primarily cosplaying if their goal is safety.
In fact codecs in particular should be written in something much stricter but more special purpose than Rust, WUFFS (Wrangling Untrusted File Formats Safely)
WUFFS gives up generality - you can't write "Hello World" in WUFFS because it lacks both strings (for the "Hello, world" text) and I/O (for the printing it out). But you can write a codec, going from a block of bytes representing the encoded file to a block of bytes representing pixels, or PCM audio, or indeed uncompressed data [or vice versa] is easy.
But unlike Rust, all of the safety in WUFFS was checked during compilation. For example Rust emits bounds checks, arr[n] might panic at runtime if n is outside the bounds of arr, but WUFFS doesn't do that, it'll have proved mathematically that n is always in-bounds, if it can't prove that it rejects your code, make sure n is in bounds and try again.
Sometimes the end result is similar, you write code to check n at runtime, if it's a miss you report an error, WUFFS can see you met the criterion - basically the same as Rust. But often in a codec design you can just prove it's in bounds, if you implemented it correctly.
*nod* As someone who came from Python for easier maintainership (strong compile-time checks, an ecosystem that tries to follow the toolchain's "fearless upgrades" philosophy, almost Go-like ease of deployment, etc.) I'd LOVE if someone made a Rust implementation of WUFFS so I didn't have to choose between stronger compile-time checks and less painful build automation and cross-compilation.
In these applications we want what's called "Functional safety" where what we care about is that the humans are kept safe. A Memory Safe language can be useful to help achieve this, which is why https://ferrocene.dev/ exists but it's also important to have business processes to assure that what the software is supposed to do will keep the humans safe, memory safety doesn't distinguish between "Ensure the human operator is in the containment zone when a cloud of toxic vapour is released" and "Ensure the human operator is NOT in the containment zone when it is released". But for that operator this difference is crucial.
I kinda wish we didn't push with the term "memory safe", and instead had a push with "correct". If your software isn't memory safe, it does not work correctly. We should aim to have software that works correctly.
The word "correct" already had a meaning. Memory safety is a subset of correctness in the same way that Rust can't statically prevent race conditions but it can prevent a subset of them called data races.
While the result is impressive, this blog post is extremely disappointing.
- It does not show an example of the new best solution, nor explain why they couldn't show an example (e.g. if the proof was not constructive)
- It does not even explain the previous best solution. The diagram of the rescaled unit grid doesn't indicate what the "points" are beyond the normal non-scaled unit grid. I have no idea what to take away from it.
- It's description of the new proof just cites some terms of art with no effort made to actually explain the result.
If this post were not on the OpenAI blog, I would assume it was slop. I understand advanced pure mathematics is complicated, but it is entirely possible to explain complicated topics to non-experts.
apparently the proof is not constructive in the sense of not giving an easy to compute recipe for generating a set of points that you can plot on a 2d plane
Indeed, it's a pity. While many advanced math problems are highly abstract or convoluted to explain to a layman audience, this one in particular is about points in a 2D plane and distances. A drawing would have been nice.
The Internet in 1999 was not good at all. Browsers barely worked, computers crashed constantly, the ability to actually search for useful things was limited, and many things we take for granted as being online (news, people, documentation) were not.
The mid-to-late 2000s are perhaps closer to what the author is looking for.
They worked pretty well actually, AFAICR. Internationalation was a bit sketchy in some cases though.
> computers crashed constantly
You did need to be careful with Windows 98, for sure, but it wasn't that bad. Also, if you put in some elbow grease you could install Linux, which didn't crash (but had limited support for peripherals and for the latest graphics cards, and almost no games).
> the ability to actually search for useful things was limited
It is arguably more limited now than it was then, since commercial search engines did not manipulate the results as much.
reply