How can I force slow decryption in the browser? I have a string that I will encrypt on the server. I then want to send the encrypted string along with a decryption method for it to be decrypted in the browser.
I want the decryption to take some time for the end user. Let's say ~10 minutes.
Let me be clear:

I want the decryption to happen.
It must happen on the browser (I understand that some might cheat but let's assume I don't care much about these cases even if they happen).
It must take some time (~10 minutes).

I understand that decryption time depends on many parameters. You can assume that at least the string of data to be encrypted can be as small or as big as we need it to be in order to achieve the above 3 things. And we can assume the processing power of an average computer/browser.
Is this possible and how?
I am a JavaScript developer so a JS solution would be preferable. Some pseudocode/steps would also help.
I know nothing about cryptography so I would appreciate it if you could please refrain from using too much jargon I will probably not understand.
As I indicated in the comments, I believe a non-cryptographic solution may be the best for this task, where instead of attempting to measure &quot;10 minutes&quot; by the average amount of time it takes to do some computational task, you simply measure it by the wall-clock time. Note that this solution still uses some cryptography, but not as a proxy to measure 10 minutes.
Concretely, when a user wants the document, you can generate a key (say an AES private key) $k$, create a payload = $k || D$ where $D$ is the current date/time formatted in some standard way, let $h= H(k || D)$ be a hash of the payload, and then store $[h, k, D]$ in some table, and send $h$ to your user, along with the document (encrypted under the key $k$).
The user can then query you later with some hash $h'$. Upon recieving such a query, check if $h$ is in your stored table as part of some entry $[h, k, D]$. If so, and if at least 10 minutes have passed since the date/time $D$, return the key $k$ to the user, who can now decrypt. You can also evict the table entry $[h, k, D]$ at this point.
The pros/cons of this versus a &quot;intentionally slow decryption&quot; solution are:

There is less wasted computational effort on the part of the user

The limit of 10 minutes is enforced regardless of the user's particular architecture (and their desire to &quot;cheat&quot;)

The operations on the server side of things are likely more efficient than the other RSA-based solution (for example, you have to use ~128 bits of randomness per user, instead of &gt;2k for RSA to be secure).


The cons are:

The user has to query your server a second time
You must store some intermediate state for each user (the $[h, k, D]$). This should be rather small (a few hundred bits) per user, but is greater than zero.

I think it is worth mentioning that I expect it would be difficult to get a uniform &quot;10 minute decryption time&quot; in the browser using time lock puzzles, even among honest users. I have not thought through this in detail, but I imagine that differences in hardware architectures (especially with respect to the presence of certain SIMD instructions, i.e. Intel SSE / AVX type instructions) may be able to get a constant factor speedup on your users architectures in the underlying BigInt multiplication for RSA, which would then result in users having architecture-dependent decryption times.
If you implement things correctly (and make sure that auto-vectorization does not occur), you may avoid this issue. But even differences in clock speed (say 2GHz vs 3.5GHz, or whatever numbers are reasonable for a few-year-old phone vs a enthusiast's desktop) would likely make a big enough difference that it would be difficult to enforce a 10min decryption time for all users (you could likely ensure that decryption for all users takes at least 10 minutes, but for some users it may take 20 minutes, or whatever).