   Time release files (store files to only be decrypted at a set date!)
  First- This is not meant to be very secure, just secure enough.To begin with, define your date as a number, (number of days since the year 1980).The date is: 8848So if you were encrypting a message to be decrypted today, you would have: figured out the date today (as a number), encrypted the file using the number).But how do we encrypt the date in a way that will not be repeated?First we compres it (because it may not be used for some time),And we generate a checksum (in CRC32 and MD5(or any other good hashes))Date^charpos % 255So for char 1, it would be,8848 % 256 or 144So you encrypt the data at byte 0 by xoring it with 144For char 2, it would be8858 ^ 2 % 256 = 0So you would xor the data at byte  1 by xoring it with 0And so on...You force the last modified date, the creation date and any of the system dates to be january 1, 1980.You then store the file into the archivers archive.If you have files in the archive, theneach day you do the following things,you first find the date as a number (8848) then,for each file in the archive,decrypt them using the current date as the key,if the CRC32 checksums match thenif the MD5 checksums match thencopy the decrypted file to the location it was before archiving andremove the file from the archiveend ifend ifnext fileFind this idea interesting, usefull, dead-on boaring?Post away,DENC   
  It has a few problems. First of all you seem to be needlessly mucking around with timestamps on files, which you should probably avoid unless it is absolutely necessary (it may trigger things like virus protection software or other utilities that rely on timestamps). Second, what happens if the computer is down for the day when the file is supposed to be unlocked? Now it's gone forever (supposedly).The real problem though is that it is utterly insecure. Using various mathematical techniques it would be possible to construct the original XOR code very quickly as it is so short. Anyone who really wanted to get into the file could do so in a matter of hours.I'm sure there could be a better method devised using more secure algorithms, but unfortunately I don't have time at the moment to dream one up.   ;  If you encrypt something using only a date, then it is super easy to crack, since there is a very small number of possible keys.Think about it. Over the next ten years there will be only 3653 keys. It would probably take less than a millisecond to try all 3653 keys.   ;  What if you used milliseconds since the epoch? It'll still be an easy one to crack (XORs are kid's play) but if used for making a more secure key...   ;Quote:Original post by coldacidWhat if you used milliseconds since the epoch? It'll still be an easy one to crack (XORs are kid's play) but if used for making a more secure key...Still not good enough. Over the next ten years, there would be 238 possible keys. A 38-bit key is still not very secure. Besides, the goal is to be able to decrypt the data only at a specific time, and decrypting it precisely at the chosen millisecond would be pretty difficult.   ;  Well, in case the machine was down for a day, i would do something like:Store the last time it was run, then if it was more then a day ago then run for that day and all the other days including today.And although stationary xors are childs play, more advanced varients (IIRC Rc4 uses xor) are not, and this calculates each bytes key based on k^c mod 255 not secure but not childs play to remove either. (will probably change this to a prime generator, that will take an unreasonable amount of time to complete like say 10 minues- 1 hour). Say your date 8849 today,you generate the prime closest to,2^(closestprime(date ^ (date / closestprime(date)))) - 1It should be 1. mercenene 2. very hard to generate and 3. only needs to be generated once per day. (that would make it ok for the server (only needed once per decryption of many files) but hard for someone else (all that time PER DAY, so if it was say a year ahead then it would take about 365.25 hours (assuming one hour per keygen, most likely longer), assuming you have got the right file, which you most likely won't...)The thing is is that it doesn't need to be bulletproof because1. the drive would be an encrypted drive on a server and2. all identifying marks have been removed, so you have no idea what each file is. (assuming each file is encrypted on transfer)Nifty idea,If you find a problem, please postPOST AWAY!!!DENC   ;  You do realise that if you have access to the encrypted files and know the method of encryption then you can decrypt them at any time right? Especially if you know the release date.If that's not the case i.e. this file is stored in esentially a black box that is not under your control then there is no need to even encrypt the file, except to hide the contents while being transferred. For that you would need asymmetric encryption though and your black-box would have to have a private key. The black box must also be impervious to tampering with it's internal date.I suppose what I'm trying to get at is that, to be effective this problem requires some form of hardware solution as much as a software one. Software alone will not provide a total solution.   ;  The thing is the black-box isn't bulletproof.Thats why i remove all identifying marks from the files,you have 5 files in an archive,All the sizes have been changed due to padding,There is no other characteristics that have been changed,So if you want to check the 5 files,Say if each file was 6 months in the future,and had a time resolution of 1/2 an hour,thats 5 * 48 * (365.256 / 2) = 5 * 12 * 365.256 = 60 * 365.256 = 21915.39 decryptions needed.Say each one took about 2 hours,It would take 1826.28 days (asuming 24 hour days),thats 5 years!In real life the file server would have hundreds of thousands of identical files, (they would be decrypted on a faster computer),Even though on average they would only be about a week ahead... it would take a long time,100000 * 7 * 2 = 1000000 * 14 = 14,000,000 = 14 million hoursthat = 583333.333 repeater daysthats = 1597.05 yearsThats a lot of time for a successfull decryption,Placing a passphrase and encrypting it with RC4 before after it was encrypted with the time-lock increases the time much more.Lets say that the key is 6 chars longLets use letters and numbers (35 numbers in total)6^35 = 1719070799748422591028658176Now to decrypt the same 100,000 files, it would take100000 * 7 * 2 * 1719070799748422591028658176 hours= 2.4066991196477916274401214464e+33 hours= 1.002791299853246511433383936e+32 days= 274544784987309314955369367238.32 yearsI don't think the NSA would wait 274544784987309314955369367238.32 years to find whatever it is that you want...I would say that it would take a long time because,1. the Key lock obscures acess to the RC4 Data, so you need to finish the decryption first...2. You would still need to crack the RC4 cypher (i would assume that RC4 is still pretty strong), and3. I would say that most people would use a passcode longer then 5 chars.DENC   ;  I thought at least Some people would be enthused about this idea,It could come in handy, to stop "Pre-release" versions from running (you would have something like this on the download (if you have an online shop). You could then decrypt it today, but not tomorrow, and if the setup self-destructed after each install... it could come in handy).   ;  so you're talking about your software doing the decrypting and checking the date on the file.You might as well have your own pgp key and not bother with the date being part of the key.   