Is there a way to encrypt something so that it could not be decrypted until a certain time?
Like I encrypt a file with a particular password but that password fails until 30 days from now.
lol bruh you dont know how encryption works
is encryption not enough for you?
Encrypt something with a borderline unbreakable key.
When technology progresses they'll be able to break it.
Very rough though
>>54591916
Maybe expiring gpg keys?
>>54591916
Sure. Encrypt something then publish the key N days from then.
Well kinda. You could pick the key that become available information at a point. Eg you could make the key the lotto results for a future week if you somehow obtained them. Or you could pick an algorithm that'd be unplausable to break until breakthroughs occur. Then they'd be decodable once breakthroughs occur. Eg if we work out how to find prime factors in polynomial time
>travel forward in time 30 days
>get lottery numbers
>travel back to present
>use lottery numbers as the password
>>54592032
>>54592033
hivemind
>>54592033
Lel good minds think alike>>54592033
>>54592033
Nope because you change time lines when you travel in time. It's a paradox
>>54591951
>>54591959
I have a surface-level understanding. I don't see why it couldn't be done, but prove me wrong. The only issue is that a computer's time can be tampered with. So you just need a clock you can trust. You can encrypt the file normally and then encrypt the encrypted file in a container with software that verifies the time only using your trusted clock and won't decrypt the container until the desired time has passed.
>>54592117
you could argue anything when you allow arbitrary "trusted" things
>>54592046
something to do with the bitcoin blockchain should work
>>54591916
Would be nice to create something that checks if the user is dead, via fitness band maybe? Or perhaps a body mod, since someone else could just use the fitness band.
then decrypts whatever you set up.
no because it would be based on a time source which would be likely be controllable by attackers (system time is changeable). what time source would you tie the encryption to?
>>54592221
>what time source would you tie the encryption to?
My own clock.
>>54591916
v1
1. encrypt data
2. escrow passphrase
v2
1. encrypt data
2. hash passphrase
3. determine hashrate
4. remove first n bits of the passphrase where n is the difficulty, adjust for hashrate
5. mine away
>>54592117
>>It's can be done if you use a particular software
So one can easily break the decryption anytime only by not using the verifier?
Good thinking anon
>have a piece of software ask your server for a key
>on day x you put the key on your server (but encrypt it with whatever password you wanna have)
>put in password to decrypt
there
Write your own software?
Dead hand switch.
Write a program that needs a signal once every 24hrs from the password owner; an email, an SMS etc. If the application doesn't get it within 60 minutes of the expected time, it goes into "release mode". If a further 48 hours pass, the payload is released to people's of your choosing - via email etc.
You niggers do realize that all encryption is currently useless against modern computing technology, right? Supercomputers may not be able to break your RSA-2048 in less than 10 billion years or however long it is, but computing has changed. We're no longer using bits and logical operations. We're using qubits and unitary operations.
A quantum computer can factor the primes in RSA-2048 encryption in about 100 seconds. Nothing is secure right now.
>>54592729
That has to have been written already.
>>54592741
RSA 2048 is base 2. If we use quantum computers to encrypt would it be secure then?
>>54592741
RSA isnt really used for encryption itself, mostly just signing shit and encrypting AES keys. AES is not nearly as vulnerable to quantum attacks.
>encrypt with computationally secure algorithm
>if daysElapsed == n:
> decrypt
> encrypt with weak crypto
I believe this can be validated against OPs requirements
>>54592066
>not even sure if time travel is possible
>but some idiot on an Indonesian watersports enthusiast image-board knows it's mechanics
>>54592741
that only applies to certain elliptic curve algorithms and not RSA
>>54591916
I don't get your question, is it:
>How to make it with an algorithm such as, with current processing power, it can only bruteforced after 30 days
>How to completely lock the data in way that, even with the key, it can only be opened after 30 days
?
>>54592854
Second
>>54592293
time is a measurement of rate of change. how is your clock secure enough that someone can't hack it? if they don't have access to your clock then sure, they can't hack it, but how does your encryption algorithm have access to your clock?
>>54592948
Good point. When decryption is tried it can sure check time right?
>>54592876
I see, I have no idea
But it should be possible, make it so you need two keys, maybe create a script that keeps a key encrypted until it reads a certain date from a server on the internet...
I have no idea of how to do it tho
>>54592999
Would be interesting
>>54592117
That actually not a bad idea. Someone could set up a server that signs a timecode once that time has passed with a private key.
I can't quite figure out how to then translate that into only making the file decryptable once that time has been reached and signed, but this might be an useful resssource to set up anyway.
>>54592700
pajeets, interns, college students do it cheaper
>>54592999
Then I think you would need three keys, two for the data and one for the script to encrypt one of the first two keys
I don't know how you would hide the key used for the script... I should be readable to the script, so you couldn't just throw it away
>>54591916
M of N decryption with N designated parties who have made deposits that are forfeit upon any of them providing a proof of the plaintext before a given date (obviously with the provider of the proof getting a partial payout instead).
Boom, economically guaranteed time based decryption.
Now go learn how to smart contracts ya scrub.
Not as such. Secure time is a huge problem which needs a Trent and has enormous pitfalls.
You can approximate something like it wih a partial Hamming search proof-of-work:
Alice encrypts using a strong AEAD (eg ChaCha20-Poly1305), with a key k. Consider the bitstring k as an integer, and transmit the ciphertext and (if possible via some forward-secret means) an interval, [k'low,k'high] such that k is included at a random place within that interval.
The size of the interval corresponds on average to twice the proof-of-work Bob needs to find k with repeated trials: authenticate, then if successful, decrypt. (If Bob has a quantum computer double the interval size to account for Grover's algorithm.)
This is stochastic: we can only guarantee a proof-of-work, not a time delay, but if we know Bob's resources we can set an average time-to-decrypt.
This is used in the so-called Nitmar technique, inspired by Andrew Nitmar's Curious Yellow/Blue paper, in which a botnet carries encrypted subroutines and a C&C uses this technique to essentially gamble that the distributed computing power of the botnet exceeds that of an attacker attempting to analyse/reverse-engineer what the commands are ahead of mass execution.
>>54592150
Very close. Bitcoin's proof-of-work is based on Hashcash combined with the interval (rather than bit prefix) idea of the Nitmar technique which allows for high-resolution work factors as the workfactor increases. (Hashcash was targeted at a fairly low cost as an anti-spam measure originally.) The distribution idea broadly comes from Nitmar, via (pseudonymous) work on I2P.
Bitcoin is a combination of existing techniques.
>>54593297
have a link to that nitmar paper?
>>54591916
There might be a way using a TPM.
>>54593494
Not offhand, but you'll find a link to the inspiration paper by searching "Curious Yellow". Very ahead of its time in predicting malware/AV trends.
