Storing a random password that is not able to be retrieved untill a later date

[norax]

So I usually use my friend Google but I'm stuck on this 1 basically I want to encrypt a file with a password (easy )

That password has to be unknown to myself and only able to be recalled at a given date. (Hard)

Other than passing the info to a server that is located out of my physical access and having The server only respond to a request for the password after a certain date (not practical) I'm out of ideas

[abberration]

Encrypt the password with your own key (memorize it) using _Crypt_EncryptData and print out the encrypted password string on paper then put it in a safe deposit box, put it under insulation in your attic, seal it up and bury it in the woods, etc. Get creative.

[orbs]

22 hours ago, norax said:

That password has to be unknown to myself and only able to be recalled at a given date. (Hard)

actually, the first step ("That password has to be unknown to myself") is easy, since the password is created randomly. for the second part, even if you remove the date constraint, you face the same issue - how are you going to store the password for later use? if your script can do it, than obviously so can you, which defeats the first condition. same goes for the server idea (which you claim to be impractical without explaining why) - if you program the server, then you have access to the stored password.

it seems to me you are going about a problem in the wrong way, since the script using the password cannot hide it from you as teh developer of that script - unless you delegate the storage of the password to someone else on whom you have no authority.

[genius257]

your program could send the password to a page that sends it back via mail or text message at a later time.

like for example: https://www.anonymoustext.co.nz/

you would need to use _IE to automate this process, as it does not seem any of them provide API endpoints to call.

[norax]

 

9 hours ago, orbs said:

actually, the first step ("That password has to be unknown to myself") is easy, since the password is created randomly. for the second part, even if you remove the date constraint, you face the same issue - how are you going to store the password for later use? if your script can do it, than obviously so can you, which defeats the first condition. same goes for the server idea (which you claim to be impractical without explaining why) - if you program the server, then you have access to the stored password.

it seems to me you are going about a problem in the wrong way, since the script using the password cannot hide it from you as teh developer of that script - unless you delegate the storage of the password to someone else on whom you have no authority.

You explained the impracticality of the server with the following sentence lol. And the point of the random password was that I nor anyone else should know it yet it must be retrieved that's what was difficult not generating a random password.. Really posting like you did is more of a deterrent for someone to ask for help again not helpful.... The desired effect is no human knowledge of the key to unencrypt the file until the date of request like a courrier service. Block chain technology solves the issue but is way outside the spectrum of this little project

9 hours ago, genius257 said:

your program could send the password to a page that sends it back via mail or text message at a later time.

like for example: https://www.anonymoustext.co.nz/

you would need to use _IE to automate this process, as it does not seem any of them provide API endpoints to call.

This is something I hadn't thought of might be a good solution I'll mess around with it thank you 

[jchd]

The problem is ill-posed.

Initially you have access to a secret (a file, some text, whatever) which you/your program obviously have access to in clear in the first place.  This is called the cleartext.
Hence you can't pretend to hide it from you in some near future and for some time (until the reveal-date occurs).
The parts "And the point of the random password was that I nor anyone else should know it" and "The desired effect is no human knowledge of the key to unencrypt the file" are impossible to satisfy, strictly speaking.  That you think of the encryption key or the cleartext itself is unimportant since you've had access to both the secret and the key in the first place.  Remember that you —as the program master builder— can't be trusted not to cheat with your own program.  Else, if you and others regard yourself as trusted, then you don't need anything: just release the cleartext at reveal-date.

Thus you need to remove yourself from the list of people being denied access to the cleartext.  These people have to trust you for the scheme to work.

Then you need a trusted third party (called a notary) to generate an encryption key on his side, receive both the cleartext and reveal-date from you, send you the encrypted secret (called the ciphertext) to you and possibly a number of people.  The notary job ends after the reveal-date, when he reveals the decryption key to you and the list of people allowed to access the cleartext.

BTW I don't understand your rant against @orbs post, since it describes the issue correctly and offers a limited solution equivalent to what @genius257 posted (which you consider useful).

[JLogan3o13]

If it must be something unknown to everyone (I am with @orbs on stating you need to re-think your requirements if it is). Look at something like CyberArk, where you store the password in a vault and then give another account the ability to reset the password in the background at a set interval. When you connect to a system with it, the credentials are encrypted and embedded in the background; you never see them. That is about as close as you're likely to get (and not something you're going to do in AutoIt).

[jchd]

At the risk of being heavy, "something unknown to everyone" is a fallacy unless " except you" is appended.

[norax]

Yeah so the concept I had doesn't seem doable which is why I asked. Orbs offered more criticism than help I didn't mean to rant on him or w/e just thought unhelpful. The idea was for a user to delete their current crypto wallet and store the backup paraphrase in a file which would be encrypted and forced away until a later date . Ment for people looking to save or invest in a crypto without having to have the will power not to sell under bearish conditions or a slight bull market

[jchd]

@orbs post wasn't offensive nor unhelpfull, maybe you feel so due to mixed linguistic difference on how to interpret terms.

Anyway, I better understand where you're going and why.  There is still a marginal possibility to achieve something close to what you want without relying on a notary or remote server, at the price of using security thru obscurity, which is always a bad thing.

Generate a random passphrase and call it RND.
Obtain the current UTC date and compute the UTC "reveal-date", DATE.
Encrypt the cleartext (the wallet file) with base64(DATE) & base64(RND).
Store base64(RND) somewhere and call that KEY.

The user is then left with a ciphertext (the encrypted wallet) for which he doesn't have the proper decryption key.

Write a program which is to run every day:
Get base64(current_UTC_date), append KEY; use that to try to decrypt the wallet.  If the output doesn't have the expected wallet file format, then the reveal date hasn't occured yet.

Don't use AutoIt for that since it can be reverse-engineered too easily.

Of course you can obfuscate this very simple scheme at every stage, but it will still boil down to security thru obscurity: if the recipe is understood, then the scheme will fail to deny early access.

Edited October 18, 2019 by jchd

[orbs]

@norax, first let me apologize for my apparently discouraging phrasing. my mere intention was to highlight the core issue with your design, which can be solved only by an external independent storage service ("NOTARY", as defined above).

with the method suggested above by @jchd (that incorporates the date as part of the password) there is yet another issue - the decryption cannot be performed neither before nor after the specific date. this is why he states "Write a program which is to run every day", which does address the issue, but only if this requirement is met reliably - can you trust your users with that?

another approach could be, instead of trying to hide the entire password from every person, hide pieces of the password from some persons. create a random password and encrypt the data, then split that password, attach a date to every half, let the user keep the date+half#1 string and send the date+half#2 string to you. when the date comes, the user is required to type the password, and needs you to deliver half#2 - which you refuse if the date is not yet reached.

this requires human trust, rather than a "technical" trust; this may or may not be applicable, depending on the relevant human relationship.

 

[jchd]

Yeah, I also insisted on using UTC dates everywhere to be sure offset hours don't mess with the scheme.

[rudi]

Hi,

as I think this is an interesting, exciting idea I did some more seaching and came across this web Service http://www.tellyoulater.com/

like the Service mentioned by @genius257 it's dependant on a Server, but not resending the message, but by offering key pairs for certain "Points-in-Time".

currently it's not operational, but the "About Project" is telling how it should work:

http://www.tellyoulater.com/about

 

Rudi.