this post was submitted on 30 Jun 2024
23 points (82.9% liked)

Open Source

31129 readers
297 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] zepplenzap@lemmy.one 16 points 4 months ago (3 children)

If I'm reading the code correctly, this uses the duration of your "time lock" as the duration for how long it will perform scrypt operations on the key derivation.

In other words, if you say you want to "lock" the secret for 5 days, the code will perform scrypt to generate the key for 5 days!!! Then it expects you to remember the iteration count to decrypt it.

I don't see any use case where that's a useful mechanism. Especially since it ignores other computers are likely faster at scrypt then yours is.

[–] jet@hackertalks.com 3 points 4 months ago (1 children)

I think it'll generate 5 days converted into seconds number of operations.

To decrypt however, you have to do all those operations, so I think it would take 5 days to decrypt. Even if you wait 10 days to start the operation

[–] Markaos@lemmy.one 4 points 4 months ago (1 children)
def generate_proof_of_work_key(initial_key, time_seconds):
    proof_key = initial_key
    end_time = time.time() + time_seconds
    iterations = 0
    while time.time() < end_time:
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
        iterations += 1
    print(f"Proof-of-work iterations (save this): {iterations}")
    return proof_key


def generate_proof_of_work_key_decrypt(initial_key, iterations):
    proof_key = initial_key
    for _ in range(iterations):
        proof_key = scrypt(proof_key, salt=b'', N=SCRYPT_N, r=SCRYPT_R, p=SCRYPT_P, key_len=SCRYPT_KEY_LEN)
    return proof_key

The first function is used during the encryption process, and the while loop clearly runs until the specified time duration has elapsed. So encryption would take 5 days no matter how fast your computer is, and to decrypt it, you'd have to do the same number of iterations your computer managed to do in that time. So if you do the decryption on the same computer, you should get a similar time, but if you use a different computer that is faster at doing these operations, it will decrypt it faster.

[–] Redjard@lemmy.dbzer0.com 2 points 4 months ago (1 children)

What is the threat szenario?
If you are smart about parallelization and have access to custom hardware, couldn't you turn 5 days into 1 hour or less?

[–] Markaos@lemmy.one 2 points 4 months ago

Yes, that's exactly the problem - there's nothing wrong with the encryption used, but it's IMHO incorrect to call it time-based when it's "work-based" and it just so happens that the specific computer doing the encryption works at a given speed.

I don't call my laptop's FDE time-based encryption just because I picked an encryption that takes it 10 seconds to decrypt the key.

[–] celia@lemmy.blahaj.zone 2 points 4 months ago

If it really works like this, the time lock would vary depending on the device. Encrypt for a long time on a potato, decrypt in seconds on a good computer.

[–] Super_gamer46861@lemmy.world 0 points 4 months ago

Yeah you have to wait x time to encrypt but gotta wait x time to decrypt as well