Time-lock encryption

[hakavlad]

May be added without breaking backward compatibility, but it requires a fast Argon2 implementation.

Time-lock encryption (TLE) can be used to prevent an adversary from quickly accessing plaintexts in the event of an IKM compromise (in case of user coercion, for example). In our implementation, it is actually a PoW-based time-lock key derivation. The "Time cost" input option specifies the number of Argon2 passes. If you specify a sufficiently high number of passes, it will take a significant amount of time to perform them. However, an attacker will require the same amount of time when using similar hardware. The execution of Argon2 cannot be accelerated through parallelization, so it is expected that the time spent by an attacker will be approximately the same as that spent by the defender.

This TLE implementation works offline, unlike tlock.

Plausible TLE: The adversary does not know the actual value of the time cost, so you can plausibly misrepresent the number of passes. The adversary cannot refute your claim until they attempt to decrypt the data using the specified time cost value.

See also: https://github.com/hakavlad/tird#time-lock-encryption

Easy to implement: just allow users to set custom number of passes.

[hakavlad]

May be added without breaking backward compatibility

If Argon2 is only launched once per session, rather than for each file.

[samuel-lucas6]

This is an interesting idea; however, I don't think it works in practice.

If you told the attacker a high amount (e.g., days of computation), it's almost certainly a lie, and they can just keep hitting you with a wrench. If you tell the attacker a low amount, it's not much better than a regular delay in terms of slowing them down. And in both cases, if you keep telling them inaccurate information, that only increases the likelihood of punishment. It's pretty similar to pretending to forget your password.

There are also some optimisations for Argon2, so a sophisticated attacker could get some level of speedup.

Finally, from a usability perspective, there's a risk that this encourages a paranoid configuration, and it becomes an extra thing to memorise or write down.

[hakavlad]

TLE is primarily a way to physically prevent rapid decryption, even if you want to cooperate with the adversary.

I am confident that it really works. For example, I rarely reboot my computer. Leaving a process running in the background for a week is not a problem.

Deriving keys over several days or even weeks does not seem unrealistic to me when it comes to protecting important data intended for long-term storage that does not need to be accessed frequently (such as a cold wallet, for example).

from a usability perspective, there's a risk that this encourages a paranoid configuration, and it becomes an extra thing to memorise or write down

You just need to explain to users that increasing the time cost increases the attack time linearly, while increasing the password length increases the attack time exponentially.

sophisticated attacker could get some level of speedup

Only a sophisticated attacker can achieve this level of speedup. Not every attacker is sophisticated.

There are definitely cases where using TLE makes sense.

it's almost certainly a lie, and they can just keep hitting you with a wrench

Okay, this may not work in many cases, but it will work in at least some. After all, the tool is designed to protect data, not the user.

[samuel-lucas6]

TLE is primarily a way to physically prevent rapid decryption

I guess the main use case is if the attacker is forced to release you because of a lack of evidence in a certain timeframe.

I am confident that it really works. For example, I rarely reboot my computer. Leaving a process running in the background for a week is not a problem.

I expect most people don't do that, and that also renders whatever that data is inaccessible for a week when you need it.

There are definitely cases where using TLE makes sense.

I think date bound sounds more interesting in terms of releasing something after you die, for example.

An alternative to this would be randomly generating a password and not memorising/writing it down. Then you can't disclose the secret.