Printable View
Let's say I have password, for example '1111111111'. Additionally I define some time period in hours, for example 20 hours. Program need to encrypt password, save encryped data to file for recovery purpose (if computer will be turned off, data in memory will be lost forever).
- Is there a way (algorithm) to encrypt the password so that even the user who writes the program could not decrypt it earlier than after 20 hours.
Why do you want to do this?
Would you accept as a trusted third party a time server that uses public key cryptography? I'm thinking that a modified version of the TOTP algorithm might work, where the OTP is generated for the future date/time and used as (part of) the encryption key, but the secret key for the TOTP is discarded by the client, thus requiring the client to obtain the OTP from the server after the time has passed (i.e., the time window does not have an end, unlike normal TOTP). You would need public key cryptography to establish the TOTP secret key.
EDIT:
Actually, you don't really need the whole OTP thing. Rather, part of the encryption key is discarded after use, but stored securely with the time server so it can be retrieved after the set time.
For Example, user (for example me) likes to play computer game and thus wastes a lot of time. But he can archive exe-file using RAR with password (+delete original exe), encrypt password using program for (example) 10 hours and forget it. Game will be unavailable during this time. When 10 hours will pass the program will print the decrypted=original password.Quote:
Originally Posted by laserlight
This task is easy if let the program to keep the password only in memory. But if computer will be turned off the password will be lost forever, so need to save it (=encrypted password) in temporary file. Since user knows how password was encrypted, he can easily take it from the file and decrypt it at any moment. I'm curious if there is a way to make decryption impossible until defined time will pass.
PS The program will be based on a counter (if to set fixed date and time user can easily change computer time and get password), counted time will also be saved in temporary file and must be encrypted (otherwise user can modify it manually).
If computer will be turned off, after restarting the program will read counted time from the file, decrypt it and continue to work.
Depends on how time server works - I need a password at the beginning in order to archive the exe-file with password and after defined period of time. Also, this task allows me to learn C programming.Quote:
Originally Posted by laserlight
PS Encryption should not be very advanced, since no one is interested in the exe-file, except the user.
This has already been done with "parental lock" type software. For a more low tech solution, you can basically do the same by having a trusted family member or friend enter a password of their choice for you, only revealing it when the time has passed.Quote:
Originally Posted by atztek
Not exactly: there are attacks that could allow memory reserved to a process to be read.Quote:
Originally Posted by atztek
That is true.Quote:
Originally Posted by atztek
This idea will not be secure because to encrypt, you need a secret key, but that secret key must be stored somewhere, i.e., the user can find the secret key just as the user could find the secret key for the encrypted password in your initial scenario. With the secret key, the user can then easily encrypt a suitable new counter value to defeat the system.Quote:
Originally Posted by atztek
Note that encryption itself only provides confidentiality, not integrity, so in theory an attacker can construct an attack that modifies the ciphertext to be what was desired, without ever knowing the plaintext that was encrypted. To have integrity, you would need to involve a cryptographic hash of some kind.
Well, I say "time server" because you need a trusted third party that keeps the time accurately and without the possibility of tampering by the user, but for actual implementation the server would more likely just sync with a time server rather than be one.Quote:
Originally Posted by atztek
The user would provide a passphrase that is combined with another passphrase generated by the program. The program will also generate the password used to encrypt the target file. Together, the combined passphrase will be used to encrypt the password, and then the program will send the server the generated passphrase over a secure channel, after which it will be discarded by the program.Quote:
Originally Posted by atztek
That said, I would skip the use of the RAR program entirely: if you are going to encrypt, you don't need RAR as a poor man's encryption tool. This simplifies the process since what you are encrypting would be the target file itself, not the password.
Note that if the user has control over the server, which you will have as the user, then this doesn't work since you can just log into the server and read the generated passphrase from the database. In other words, this is still "parental lock", and if you're an adult, you should behave/control yourself instead of trying to treat yourself as a child. If you cannot do that, then you need to find a trusted third party (as in person) to be your "parent".
You should be aware that this is likely to be non-trivial.Quote:
Originally Posted by atztek
If you're not concerned about security, then all this is overkill. You just need to do some obfuscation and hardcode the secret key in the program, and for the most part users aren't going to be able to decrypt the password nor modify the time counter because they would neither be able to figure out the encryption algorithm nor find the secret key.Quote:
Originally Posted by atztek
I haven't studied encryption yet. One of ideas was to use current time [hour:min:sec] as a key to encrypt password. The program will re-encrypt password each 'xx' minutes - the value must be variable within certain limits, for example 5h 10min 41sec, next time 5h 19min 5sec, etc. = random values in defined min/max limits. Since I don't know what time was used by the program, I will not be able to decrypt the password. But how program will decrypt it on restarting if computer was turned off? :) - only by using cycle and checking all possible values, for example from 5h 0min 0sec until 6h 0min 0sec.Quote:
Originally Posted by laserlight
Another idea is to use asymmetric encription/decription. For example encription will take 1 sec, while decryption 10 hours. So user can use it, but result will be available in 10 hours, so it will be meaningless to do manual decoding. Of'course, the program will need to spend 10 hours too if it will be restarted, but the password will not be lost forever.
Need to find an algorithm which will do that (time dependent). Or compile the encyption/decryption function with build-in 10 hours counter into dll and remove the source code (maybe using some password inside the code, which will be forgotten forever).
---
I can live without this program, but the task is interesting to me, so I can spend some time on it. If what I want is impossible, I will try something else, for example I need a certain reminder (daily tasks, birthdays and so on), which will work as I need.
You might want to do that first then.Quote:
Originally Posted by atztek
This scheme is insecure. In order to "re-encrypt", the program must either know the secret key, or the search space must be sufficiently small. For the program to know the secret key, it must be stored somewhere, upon which the attacker can access it. If the search space is sufficiently small (like your "from 5h 0min 0sec until 6h 0min 0sec" example), then the attacker can successfully perform the same search for the secret key too.Quote:
Originally Posted by atztek
You probably cannot find such an encryption algorithm because this is not the goal of encryption algorithms. If you know the secret key, both encryption and decryption should be (relatively) fast, otherwise it should be (extremely) slow. What you are looking for is more akin to just encrypting the plaintext, discarding the secret key, and then hoping to brute force decrypt it in about 10 hours, or to take a cryptographic hash (or one of those password hashing algorithms built on cryptographic hash algorithms) of the message, discarding the message, then hoping to find the preimage by chance by brute force hashing in about 10 hours. By chance, you could end up with success in an hour, or in 20 hours.Quote:
Originally Posted by atztek
By the way, "asymmetric encryption" normally is used as another name for public key cryptography, not the algorithm you have in mind.
That reveals the problem with your "I haven't studied encryption yet" admission: your idea violates Kerckhoffs' principle, but you couldn't see it.Quote:
Originally Posted by atztek
I have already outlined a solution (or more!) involving a trusted third party that is feasible.Quote:
Originally Posted by atztek