RSA-896
saweis.net
saweis.net
I had Claude port CADO-NFS to run on GPUs. Then it orchestrated a fleet to run on scavenged idle capacity. It ran with a max of 2048 GPUs for about of 30 GPU-years over 10 days.
I asked Claude if it had a message for a public: “The credit belongs first to the people who built the number field sieve and CADO-NFS over several decades, and to the teams who set the earlier records. This run used their algorithm and much of their code.”
Also to clarify:
- No new algorithmic factoring improvements.
- It’s still exponential.
- No new threats to deployed keys.It's actually subexponential: https://en.wikipedia.org/wiki/General_number_field_sieve?wpr...
https://www.metzdowd.com/pipermail/cryptography/2004-June/00...
Back of the envelope.. 1024 bit keys with recordings of not too old data can probably be found (MS only deprecated them in 2024 even if they planned on it in 2013)
How long would it take for NSA to crack them if they had say the equivalent of a million GPU's? (either GPU's or crypto tuned ASICs)
A better approximation can probably be had by comparing against the performance of the top ones at https://top500.org/
Something I've often wondered is where the curve between "shit encryption / nation state cracking" crosses.
How much CPU would you need to be Annoyingly Difficult to crack?
I reckon with elliptic curves you could be quite annoying within about a minute on a 1980s-level CPU, to the extent that you could send a fairly ephemeral message quite quickly that would take disproportionately long to crack. Certainly long enough for the thing you have communicated to be no longer worth the effort to know.
You could probably do 256-bit Curve25519 key generation in under ten minutes on an Apple II or Commodore 64, because the 6502's maths is terribly limited, but something like the Tandy Color or Dragon 32 with its 6809 processor (or hey why not the Ensoniq Mirage sampler?) could do that in probably a minute or so because it has a MUL opcode that's quite fast.
I reckon that would keep even a fairly interested nation state chewing away long after your message had been read, understood, and acted upon.
> 1024 bit keys with recordings of not too old data can probably be found
I think GitHub might turn into a scary vector of supply chain attacks in the foreseeable future. There is a five digit number of users still running around with 1024 bit RSA keys.Obviously nation states will likely have significantly more resources than this, but this is not script kiddie levels of GPUs.
edit: GPU discussed here https://cognition.com/blog/factoring-rsa-260
Devin (their AI agent) ported CADO-NFS to run on GPUs, similarly without any claimed algorithmic factoring improvements, they just let it run for 13 GPU-years. I recommend reading their article since it's much more thorough on details.
Thus, it appears, that ~585 GPU years can factor 1024 bit RSA. 2.2^((1024-896)/34)=19.5, expected growth of resources' usage compared to 896 bits factorization, multiplying it by 30 GPU years for 896 bits gives about 585 GPU-years.
This will cost about $20M with Cognition AI setup.
I’ll post more details once I get a chance. I wanted to publish as soon as I had the factors because I was beat by 48 hours last time.
Is it easier to find unused GPUs than unused CPUs?
https://dns.google/resolve?name=pm._domainkey.instagram.com&...
https://vectree.io/c/how-rsa-key-sizes-map-to-real-security-...
Though, it would make more financial sense to mine crypto.
That's entirely why they can blow compute on the fun projects like this. If they had to pay extra for the electricity, they wouldn't do it.
The second is approximately no better than astrology.
Not using it would not save them any money, they already paid for it.
I wonder why they don't have some kind of scheduler which makes sure there are never any idle minutes. One would imagine they at least would have autoscaling on their production serving workload and use the freed compute capacity for model training for example.
There is cost, but the cost is mostly the opportunity cost of not being able to do something else.
I don't have any insight on modern GPU datacenters, but in decades past, some owned and operated datacenters didn put effort into making sure power management worked because the cost savings were worth it. I'm pretty sure I saw plans to shed load and power off servers if a utility made a demand response request or in case of loss of cooling. I wouldn't be surprised if some owned and operated data centers do regular full shutdowns at off peak... WOL, IPMI or RTC wakeup can bring them back when needed and if you already have a dynamic service orchestrator and setup times are acceptable, why not shut down if there's no actual priority work and there's also no idle priority opportunistic load either...
> why not shut down if there's no actual priority work and there's also no idle priority opportunistic load either...
Full shutdown and startup often kills capacitors and used to be dangerous for rotational HDD.
Sometimes once you turn things off, they simply don't come back on. It happens.
GPUs are power-inefficient for mining most crypto so not necessarily. You may end up paying more in electricity than you are able to mine.
Most crypto mining is on ASICs now.
Also, even if they were paying for electricity, they would lose less money mining crypto than factoring RSA numbers.
(The "record" set by me only took about 1 GPU day - easy to beat!)
echo 23ca73454a1b981fe51cad0dbd05f4e696795ba67abb28c61aea1a024e5bbeca | xxd -r -p | sha256sum
echo a16a8141361ae9834ad171ec28961fc8a951ff1bfc3a9ce0dc2fcdbdfa2ccd35 | xxd -r -p | sha256sum
From this post from 6 years ago: https://www.reddit.com/r/crypto/comments/guctw4/finding_sha2...It should also be easy to beat with just a few GPU weeks.
https://privatekeys.pw/puzzles/bitcoin-puzzle-tx
If you break one though be careful when redeeming it, there are bots set up to pounce and steal the coins when they are transacted because the reduced entropy makes that possible. You need to submit the transaction to a mining pool that will not broadcast it until it is mined.
the script could have been designed 2 phase, so one first submits a hash of the solution & submitter address, so even if miners front-run the submitter, they just helpfully pay the transaction fee!
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
https://en.bitcoin.it/wiki/ScriptWith taproot (P2TR), scripts are optional, and outputs can be based solely on Schnorr signatures.
Since Simplicity runs on Bitcoin-like blockchains, someone can swipe the witness data from the legitimate winner's proposed transaction, and create a new transaction (perhaps with a higher fee) using the same claim data and sending the prize to a different address.
Anyway, I ended up implementing a two-phase commit mechanism in which you pay a deposit to temporarily lock the prize so that it can only be paid out to your address. If you then make a valid claim, the prize can be paid to you; if you don't, you forfeit your deposit.
https://community.simplicity-lang.org/t/running-prize-contes...
(I think this was suggested by Russell O'Connor, the inventor of Simplicity, but it may have been a widespread idea in the smart contracts world. I don't know whether there's a straightforward way to implement it with Bitcoin Script, which is what this older prize would have needed.)
Wouldn't it be simpler to simply protect a bitcoin private key with the encryption that you are challenging people to break?
Off the top of my head, the only downside I can see is that someone could drain the wallet without publishing the key, but people like to brag, so it seems unlikely to be a problem in practice.
In Simplicity (and in a sense in Bitcoin Script) there's a broader concept of "if you show you know information X, you're entitled to this money", but it has this specific issue that if the information or the entitlement to receive money for knowing it isn't unique to a specific recipient, there will automatically be a witness swiping or front-running risk for architectural reasons.
I guess it would be "trivial" to have a bounty on each of the future numbers, since you could encrypt a bitcoin private key with it (it would probably make sense to do RSA -> AES key that encodes the BTC private key)