The wonderful thing though is that you can just run the model multiple times (even in parallel). Some instances might get stuck but as long as some find the bug and you have a good way to filter outputs (e.g. with another llm that tries to create concrete exploits) even a very small success rate on stage 1 can lead to reliable exploits
I think there’s something very interesting here and would be interested in hearing more about the date discrepancies- it’s a shame the article is mostly just the raw output of gemini instead of more commentary
Ah, fair enough. Anthropic caches at a block level (basically a single message) so for non-trivial messages this is really less of a concern, although I definitely understand why they still scope cache to a single tenant
Right, you can’t actually guess a letter (byte) at a time but you can guess a token at a time (I believe the vocabulary is 200000 possible tokens in gpt 5)
So you could send each of the 200000 possible tokens, see which is cached, and then send 200000 more tokens to find the next cached token
Certainly less efficient but well within the realm of a feasible attack
A remote code execution bug in ios is valuable - it may take a long time to detect exploitation (potentially years if used carefully), and even after being discovered there is a long tail of devices that take time to update (although less so than on android, or linux run on embedded devices that can’t be updated)
That’s why it’s worth millions on the black market and apple will pay you $2 million dollars for it
An XSS is much harder to exploit quietly (the server can log everything), and can be closed immediately 100% with no long tail. At the push of an update the vulnerability is now worth zero. Someone paying to purchase an XSS is probably intending to use it once (with a large blast radius) and get as much as they can from it in the time until it is closed (hours? maybe days?)
They have crazy growth. They reached $100M/ARR in 18 months, and 3.5 times that in less than 24 months more, so around 85% growth YoY. This is a purchase for future potential, not current earnings
It seems you are thinking of the crypto exchange as selling crypto to customers and then "holding on" to their money. That's not the right model.
Party A deposits 1 BTC into the exchange. Party B deposits $1000 into the exchange. Party A wants to sell a BTC for $1000 and party B wants to buy a BTC. They trade through the exchange, pay some fee to the exchange, and an entry in a database is changed such that the $1000 in the exchange now belongs to A and the 1BTC in the exchange's wallet now belongs to B.
Since actually holding cryptocurrency is inconvenient for users, many will just choose to keep the BTC on the exchange until they want to use it/sell it for cash or a different cryptocoin. Many crypto users are speculators who view it the same as holding stocks in brokerage accounts and not as just an exchange.
This money is held in the exchange platform but belongs to the users. They should in theory be able to withdraw it whenever they want.
Instead the crypto exchange decides to make use of these idle customer funds and invest in speculative funds/embezzle all the money and all of a sudden there is not enough funds in the exchange for all users to withdraw.
MD5 is not broken in the way you think it is. Even without salting if you give a hash H there is basically no way to recover a string that hashes to it other than randomly trying strings 2^128 times.
What you can do trivially is find 2 strings X1 and X2 such that md5(X1) == md5(X2). In this case seeding the way you described won't help because md5(X1+S) will equal md5(X2+S) due to the way MD5 works
A bunch of nodes generate random numbers and publish their hashes.
After all hashes have been published all nodes reveal their random number, verify that their number actually corresponds to their hash.
Xor all the numbers together and as long as at least one node was honest and generated a random number the result will be a random number.
I don't recall if this is exactly what proof of work does but I think it's pretty solid.
Ah, I don't think that's exactly what this thread was about. Ignoring how authorization works, the question was whether there is an advantage to encrypting your commands again (via say ssh) vs. just sending them in plaintext under wireguard (via say rsh)
But that's the thing - even with double encryption tailscale and your SSO can run commands on your machines
1) Run tailscale --ssh on your server
2) A malicious SSO or tailscale add a new machine to your network and update your ACL such that the new machine can connect to your server
3) ssh from the new machine to run code on your server
The fact that the connection between the malicious machine and your server is double encrypted doesn't affect the attack here at all