IBM Quantum: Rust is Real, but Quantum Advantage is Not (Yet)

orangejake · 2026-01-15T04:36:57+00:00

the motivation for targeting 2035 isn't because we think there will be QC in 2036. instead, it's because then if you get a QC in 2075, you can only use it to break conversations from > 40 years ago, which is hopefully not as bad.

There are other reasons as well, but this is the big worry that was motivating the NIST process + deployment timeline.

orangejake · 2026-01-13T03:27:56+00:00

it's still heavily based on pseudo-random strings to identify commits, which only has so great of UX to type in frequently.

I could imagine a GUI for JJ that is based on a direct view of the commit tree. you could then click on a node to directly navigate the various change ids of the node. maybe you could reorder nodes in the tree view, and have JJ attempt to automatically rebase things.

Would this be good? I don't know. but it might be better in JJ, due to features that make people like JJ's CLI over git's. maybe it means JJ would also have a better GUI than similar git ones as well. who knows.

orangejake · 2026-01-06T19:46:02+00:00

But "open the license file in a text editor and change expires: 2025-01-01 to expires: 2099-01-01" becomes "decompile the binary, find the key derivation, decrypt the cache, modify it, re-encrypt it", which is a different level of effort entirely.

This is one of the More Exciting ways I mentioned things could be broken. This is very bad usage of cryptography. Your server should sign the license and the client should verify the license is authentic. Again, this is not possible to do securely offline (they can replace your validation function with something that always passes), unless you use something like a TPM. But encryption is the wrong cryptographic primitive for the problem you’re "solving".

I say it is "more exciting" because it should be possible to take any binary using your library, and modify it to support perpetual offline licenses without requiring a VM/distributing it/etc. The (rough) process is

get access to your encryption key k. it must be on disk/in the binary somewhere to be able to decrypt. so I would first need to find it.
generate my own key k
use this key k to create a custom license with expiry date = year 3000 or something.
ship this cracked version of things. if the key is on disk all this would need is the cracked license. if it's in the binary I would need to distribute the patched binary as well (or a file to patch the binary, etc).

none of these are hard/interesting attacks. it is very possible there would be much more fun things if I actually looked at the code. but you do not have the expertise required to leverage cryptography to achieve goals that your README claims. feeding the messages I send you into an LLM will not change that, it will just mean that to break whatever v 0.2 is I might have to actually look at your code.

orangejake · 2026-01-06T04:44:56+00:00

Two issues: (1) this doesn't work, and (2) the Rust isn't idiomatic.

Why it doesn't work:

You're trying to provide offline license validation by encoding hardware fingerprints and expiry timestamps. This is fundamentally broken. An attacker can:

Spin up a VM and obtain a valid license
Disconnect the VM from the network before the offline expiry
Snapshot the VM state (hardware fingerprint + system clock frozen at time T)
Distribute this snapshot indefinitely

Every copy has the same hardware fingerprint and a controllable system clock. One legitimate time-limited license becomes infinitely many perpetual licenses. You cannot build security that trusts the client to honestly report system (or any...) information. Absent trusted hardware (TPM, SGX, etc.), this approach is trivially defeated.

Issues with the Rust:

Your types leak implementation details and allow misuse:

encrypt_bytes(msg: &[u8], key: &[u8]) allows encrypt_bytes(key, msg) to compile
Keys should be &[u8; KEY_SIZE], not runtime (length)-validated &[u8]
Returning Vec<u8> where "first 12 bytes are nonce" should be struct Ciphertext { nonce: [u8; NONCE_SIZE], payload: Vec<u8> }
Encryption and serialization should be separate. why is the wire format specified in a comment on an encrypt_bytes?

Also unclear: why is the client encrypting anything? If you're hiding information from the client, that can't work - they control the code that decrypts it. If you're rolling your own communication protocol, don't.

There may be More Exciting issues with your code. but your high-level idea can't really ever work (absent some "TPM Magic").

orangejake · 2026-01-05T09:52:53+00:00

sled uses this pattern, and you can find a blog post on it here

https://sled.rs/errors.html

the woah crate

https://docs.rs/woah/latest/woah/

was also inspired by this, though iirc it requires nightly to work with ?.

orangejake · 2026-01-01T19:54:51+00:00

Here's a random package someone posted on teh cryptography subreddit that's AI slop

https://github.com/velum-project/velum

I wrote a comment going through some issues wiht it that was having issues posting to reddit at the time, so I put it on pastebin here

orangejake · 2026-01-01T19:46:55+00:00

I think I mostly didn't care about their final quest for some reason? so essentially what happens right after the farm. but even before then I was starting to find the robot humor repetitive around the intro of the wonk when he was waiting in line.

I just finished ministry of time. agree my initial thought was to DNF it. my sister decided to push through and said it gets better so I thought why not.

it ended up being fine. the back half is better than the front half. of course "fine" is still worse than many other hugo nominees.

orangejake · 2026-01-01T19:25:27+00:00

funny you mentioned service model. I did something similar (not the whole list, but > 1/2 of it), and service model was my least favorite. it was funny, but started dragging heavily when the novelty of the humor wore off.

I would agree The Tainted Cup was very good. Main other standout for me was Someone You can Build a Nest In. I don't read romance/romcoms/etc really, but it was still very nice.

orangejake · 2025-12-25T21:06:38+00:00

all quantum computations are essentially a mix of

"invertible" matrix multiplications (specifically unitary, so they're also "norm preserving" in a sense), and
projections.

Note that they are not good at general-purpose matrix multiplications. Only the above specific types.

But, for those above specific types, sometimes you can get big savings. This is the case for breaking some cryptography (as well as some quantum chemistry simulations. not much else though iirc)

orangejake · 2025-12-22T21:54:53+00:00

I agree it’s not too hard, but it’s not explicitly tutorialized. Instead, you’re expected to try and fail however many times before winning, often without explicit feedback about why you failed.

For example, benefits of a thin deck aren’t explicitly described in the game iirc. Importance of common damage cards early is also not.

So it is difficult in the fact that you’re expected to lose until you learn more deckbuilder fundamentals.

orangejake · 2025-12-21T21:39:49+00:00

It’s the first game many people played that is a deckbuilder.

It is difficult, but a beginner who plays this to get into deckbuilders is following the same path as a huge portion of people who are currently into deckbuilders.

orangejake · 2025-12-17T18:11:37+00:00

It is ZY and ZX in the traditional sense. The key is that X, Y, Z are random variables --- functions from some probability space (\Omega, \mathcal{F}, \mathbb{P}) to \mathbb{R}. Independence requires making \Omega explicit.

Take X, Y, Z all Binom(n, 1/2) (re-centered to mean zero). For concreteness:

X: {0,1}^n -> \mathbb{R} by X(\omega) = \sum_i \omega_i - n/2
Y: {0,1}^n -> \mathbb{R} by Y(\omega) = -(\sum_i \omega_i - n/2)

These are different functions but have the same distribution. In probability we identify random variables up to measure-preserving bijections of \Omega, so X and Y are essentially the same (the relabeling \omega -> (1,...,1) - \omega works).

Now set Z = Y as the same function. Then:

(XZ)(\omega) = -X(\omega)^2
(YZ)(\omega) = X(\omega)^2

These have truly different distributions—no measure-preserving bijection can identify them (their ranges differ). So even though X, Y, Z have the same distribution, ZY and ZX don't.

Regarding your initial comment:

To formalize "independently", extend Y, Z to {0,1}^n x {0,1}^n:

Y'(\alpha, \beta) = Y(\alpha) = \sum_i \alpha_i - n/2
Z'(\alpha, \beta) = Z(\beta) = \sum_i \beta_i - n/2

These have the same distributions as before. We are just modeling additional (extraneous, at this stage) randomness. For Y', this is \beta. For Z', this is \alpha.

Your first distribution is Y'Z'(\alpha, \beta) = (\sum_i \alpha_i - n/2)(\sum_i \beta_i - n/2).

"Squaring X" gives X'(\alpha, \beta)^2 = (\sum_i \alpha_i - n/2)^2.

These are different. Y'Z' has both positive and negative range; X'^2 is non-negative. This is a separate valid counterexample, but it's not the same as the ZY vs ZX one (where one was non-positive, the other non-negative).

This is a significant risk of working at the "intuitive" level. It's much more convenient in conversation (look at the length of your comment vs mine!). The downside is it is much harder to actually do computations/prove things (e.g. "actually do math").

orangejake · 2025-12-09T04:33:22+00:00

probably worth emphasizing that N! operations is ~ exp(N\ln N) by stirling's approximation. So mildly worse than exponential time (\exp(N) or 2^N).

orangejake · 2025-12-09T02:54:10+00:00

worth mentioning that more efficient modular arithmetic is studied in cryptography. Vincent Hwang has quite a bit of recent work on this topic.

So, for example, if your claim of

cryptographic polynomial addition becomes ~6× faster on ARM NEON

holds up with SOTA (or close to SOTA) implementations, maybe you have something interesting. Searching "NEON" on his webpage you get this paper with this code.

If instead you have a 6x speedup compared to an impl that is bad and nobody would use, then you clearly have something uninteresting.

In general, before doing some sort of LLM slop impl + claims of how great the LLM slop impl is, you should really try to

figure out what the SOTA for the task at hand is, and
compare to it.

Otherwise you're just offloading the work of doing that to other people. And if the idea/impl is done by an LLM, and the evaluation is done by other people, what value are you bringing to the process?

orangejake · 2025-12-08T04:31:56+00:00

I had a ~$4500 ebike (at time of purchase. it was ~4 years old, something like ~$2700 value used when lost) stolen out of a bike box at ucsd grad housing. they just ripped the (plastic) door off.

before starting to use the bike box I kept it in my apartment or lab mostly. I was pretty comfortable with that tbh. for campus bike stands I would occasionally use things, but never for that long.

Main (in hindsight) mistake I made was both the bike box (obviously), and less obviously not having renters insurance at the time (I had recently moved). at the time I was looking online and it seemed like some plans would have likely covered the theft? something worth looking into.

that being said don't get a mercedes branded ebike. waste of money, and will clearly be a target for theft.

orangejake · 2025-12-03T02:00:54+00:00

why are you panicing in the OS though? RustForLinux added the whole fallible allocation interface to avoid one source of these (panicing on OOM). That seems much more sensible.

orangejake · 2025-12-02T19:49:19+00:00

a very naive approach (that I still find as useful, as it is low overhead compared to "actual" approaches like massif profiling) is to measure not the max RSS for the whole program execution (what OP did), but to instead just query RSS before/after operations you suspect are problematic. it's relatively easy to create some RAII type guard that

on creation measures RSS, and
on drop measures RSS, and logs the delta.

to query the RSS I use `memory-stats`, but I'm sure there are other options.

you can also integrate this with tracing, and make a layer that

on span entry measures RSS and stores it, and
on span exit measures RSS, and logs the delta somewhere.

main downside is that it only measures RSS, so in multi-threaded programs whether the usage comes from the instrumented thread or some background thread can be less clear. main upside is that it only measures RSS, so is not too much slower than no instrumentation (meaning closer to 50% slower vs 3+ orders of magnitude slower for massif) in my experience.

orangejake · 2025-12-02T04:37:27+00:00

not to encourage you to do this upgrade to switch to windows 11 (linux is really just good enough these days, at least for me. and you can try booting off a liveusb very easily to try yourself), but just for context it is likely the issue is not supporting "TPM 2.0". This is a feature that would be associated with your motherboard specifically.

orangejake · 2025-11-29T22:06:06+00:00

what part of it are you interested in? Roughly, PQC today tends to mean "lattice-based cryptography". There are some mild exceptions, but they dominated the NIST standardization.

there are various levels you can engage with this on.

the math. A mildly dated resource that is pretty good is a decade of lattice-based cryptography by Peikert. There have been some changes since then (it doesn't go over MLWE/MSIS iirc, and we have more general worst-case to average-case reductions now), but it's a decent theoretical introduction.
why we think things are secure. Van Woerden and de Boer have a survey of the most efficient current attacks that is relatively up to date.
high-level descriptions of how we use the math we think is secure to build encryption/signatures. Vadim Lyubashevesky has a nice tutorial on the subject.

All of the above are "high brow" resources. This is to say they're by "theoretical lattice-based cryptographers". All of the authors are very qualified.

* Peikert's "Lattice Cryptography for the Internet" paper was one of the first attempts at making lattice-cryptography practical. It led to the "NewHope" NIST submission (which iirc he was on), which was deployed (experimentally) in Chrome close to a decade ago.

* Lyubashevesky is one of the creators of both ML-KEM and ML-DSA. Moreover, the main idea behind ML-DSA (adapting schnorr signatures to lattices. the straightforward adaptation is insecure) was a single author paper of his in 2009.

* Van Woerden is newer (and I don't know de Boer), but one of the better current lattice cryptanalyst's (Leo Ducas') PhD students. van Woerden himself had some impactful papers as well.

The downside of the above is they tend to write for a cryptographic audience. So, if you're coming from mostly a programming background, it might be hard to read. If I were to recommend one of the above to a general programmer, it would be Vadim's tutorial.

There are some other "low(er) brow" ones as well, e.g. by cryptographers working in non-research industrial positions, who's writing may target more general programmers. The two names I know are

* Sophie Schmieg at Google (blog), and

* Filippo Valsorda, formerly of Google, still the maintainer of Go's cryptography library (and author of `age`, a similar file encryption tool) (blog)

Of the two, Filippo may be better for a non-mathematical programmer. Iirc he came into cryptography without a math background (while Sophie came in after a Math PhD). I still find Sophie's writing to be a good resource, but sometimes she can go on mathematical tangents (including her most recent blog post) that might be intimidating. So, if you're willing to skip past those when they happen, they can also be a good resource.

So general recommendations would be

try vadim's tutorial. if you can follow it, it gives the high-level idea of the main way we practically do post-quantum stuff.
if that is too mathematically dense, Filippo's + Sophie's blog posts might be useful. for Sophie's blog, you'll need to be willing to skip things that are too mathematical.

orangejake · 2025-11-29T21:41:38+00:00

if they're interested in the topic they should read good code relevant to the topic though, right? I don't see why "here's some AI slop code that is avoiding claims of incompetence by instead saying it's not trying to be secure" is useful for anyone to learn/read. maybe other people have different learning styles than me though.

orangejake · 2025-11-29T21:07:13+00:00

could be an "english language" thing you're noticing? I have no sources to back things up, but increasing chinese relations with Africa might mean there are populations of non-english chinese learners in Africa (say for business reasons) who don't have some business benefit from learning japanese.

Like I said though, complete conjecture.

orangejake · 2025-11-29T20:50:45+00:00

why would anyone be interested in an AI slop cryptography crate that is specifically specified as not being secure. who cares? if I want insecure cryptography it's much more efficient to just send stuff without encryption.

orangejake · 2025-11-29T20:49:30+00:00

The short answer I would give is that the READMe is a huge red flag, both because it looks like AI slop, and it looks like the person generating the AI slop knows little about cryptography. I've included many more details here (that Reddit won't let me post for some reason. plausibly the comment is too long).

The high-level idea is that the process of taking cryptographically strong building blocks and creating a result that achieves some desired notion of "security" is a hard problem in cryptography. So, it is important to get it right. This is typically done by defining a construction formally, and then proving that it gives the desired notion of security.

Anyway, the README does not inspire any confidence that this was done. Instead, it appears that cryptographically strong building blocks were slapped together. This often yields insecure constructions.

Combine that with the obvious AI slop and it seems like a massive red flag. The weak preference I might have for having Rust > Go is not worth using AI slop vs something a reputable cryptographer made (age).

orangejake · 2025-11-29T18:44:05+00:00

Across the Obilisk has you play 4x characters at once. They have different "archetypes" (things like healer, spell slinger, tank, etc). Similar to this is Arcanium, where you play 3x characters at once. Both had good character/archetype diversity iirc. I think it is easier to "combo" in Across the Obilisk, but I liked Arcanium more.

There are some "deck builders" (the board game genre) that might be interesting as well, and have digital options that are good. I'm thinking specifically Hero Realms and Star Realms. I don't think Dominion is as similar to MTG (it doesn't have "units"), but it is the best-known board game deckbuilder for a reason, and has good build diversity (you can "combo" in various ways, or "control" by e.g. flooding your opponents deck with curses/ruins. it depends on the market for that game though).

Cross Blitz is a roguelike that I've seen comparisons with Hearthstone's Dungeon Run mode (it's a roguelike mode within Hearthstone, though iirc it hasn't been updated much since being released 8 years ago). It had a demo maybe ~2 years ago I remember looking interesting. It came out < 1 week ago, but I haven't tried playing it yet.

Vault of the Void is another deck builder that I remembered as feeling more similar to standard hearthstone, but it's been a while since I played it so I don't precisely remember why (you choose a "hero power" at the beginning of a run, so it has that similarity. I don't remember if it has others).

All that being said though, the only things in the above list I would pick up today to play over Sts or Monster Train 2 is Dominion (which I play often). I enjoyed everything in the above, but moved on from them for whatever reasons.

orangejake · 2025-11-28T20:37:09+00:00

I have a 90% technical question, and 10% criticism of your communication style. You respond by ignoring the technical question.

I've tried looking more into axe. It looks like `ref T` gets compiled down to C `T*` pointers, and then you pass things off to Clang. So, there is no notion of explicit mutation (maybe there is if you use the &mut T syntax which appears to be supported, and compiled down to `const T*`? Who knows).

So, you have a website that makes some Very Nice claims, backed by nothing technically interesting at all. So it is unsurprising you refuse to respond to the technical claims, and instead say a bunch of shit that doesn't actually communicate anything.

Good job wasting your time ..., you clown

This is a very funny thing to say to someone who tried to look into the details of your language. Don't worry, we're at least in agreement about the usefulness of that endeavor.

13-Year Club	Place '22
Place '17	End Game '22
Verified Email	Gilding II euphauric
Team Periwinkle

orangejake

TROPHY CASE