eternauta3k wrote:I bet there's some funky way to do this involving a betting pool. Make your secret the XOR of a million bit sequences. Choose a million people and let them bet on the time that the secret is revealed, but first place your bet on the time you want the message out. If each participant is perfectly greedy and perfectly rational, they'll join their sequences at the time you chose (???).

If everyone knows when to join, and everyone does so - thus all winning - where are sufficient losses to be worth their time going to come from?

yeah i tend to agree with the above discussion, in that some kind of seeding->hashing is PROBABLY the best way to go.

again, some effort needs to be made to ensure your logic is impeccable however, since there's always someone smarter than you out there they may find some unexpected means to hasten the process which means you can no longer rely on the robustness you expected.

so another possibility might just be to try to hide the system, so then if you have someone pursuing you they have an incredibly broad needle in a haystack scenario, instead of a mathematical/logical one.

ultimately since some very good options have already been discussed the main point i should like to suggest is that if the required period of time is sufficiently large then i'd certainly want some redundancies. that way you could even align your system to be rather safe, and even if doing so increases the risk of failure you can spread that across a few components. of course adding redundancies does increase the risk of intervention.

1) Should the message be impervious to attempts to stop it from transmitting? (All things mechanical can be just stolen and put in a secure location, and after given time the message won't see the light of day).

2) In event of tampering, should the message rather risk exposing prematurely or self-destruct and not be transmitted at all?

If 1) is not important, then a mechanical time-locked box will be a decent idea - a quartz-clock based locking mechanism in a huge box of solid metal with a small column that will be unlocked for removal after given time (with a SD card placed on it's end. Knowing some parameters of drilling/burning into solid metal one could calculate what size it would have to be to resist for given time.

Now, mechanical box won't be ever tamper-proof - if there is an unlock switch inside, it can be accessed and triggered, for example by drilling very small hole. Obscuring the design can help, but we cannot rule out sheer luck of drilling right into the locking part (and drilling v. small hole will be quite fast even in case of very, very hard alloy and a very, very large box.

That said, one can fathom a self-destruct mechanism that could detect tampering attempts - still not perfect, and we don't know whether self-destructs is allowed.

Now, I think that in worst-case scenario for requirements is: it MUST be transmitted to the receipient, it CANNOT be intercepted prematurely.

To fulfill it (or come as close as possible) I think one would have to fight interception or interference by dispersal and obscurity. I'm thinking a computer program, or a number of them, placed in random hostings around the world. Only the creator would know where he created accounts. We could make a large number of them, each with a part of the key (+some redundancy in case of failure). Each would use a random subset of time-checking rules (self-system time, time-providing websites, timestamps in random websites etc.), and after making reasonably sure it's time it would call a 2nd application (possibly also spreaded into multiple servers, but fewer), and give it's part of the key. After receiving enough of the parts, the "Host" would decode the cryptotext with message (some ridiculous encryption strength, why not) and then do what's required with it.

An enemy who would want to intercept it before the "release" time would have to know where most of the servers are located, gain access to them (and them being in various jurisdictions might hamper those attempts, or at least stall it long enough), find Host, also access it and decrypt. Unlikely.

Possible problems:-Enemy turns off the internet. While difficult, precision strikes into all known ocean-floor cables could separate parts of the world from the network and thus make the "release" impossible.-...I can't see more. Global time switch would be difficult, unless one would know exactly all the places the Keyholders will check, but it would require for him to know where all the Keyholders actually are, and to know that he would have to spy on the message creator in the process of setting it up. If so, he could just spy on the pre-encryption plaintext. We must - for the very question to be possible to answer - assume that enemy WON'T try to do anything before the message is set up - then typical precautions should suffice (creating accounts from different networks, different computers, different payment options etc.

I think that if you build a satellite with a clock and a transmitter, enclose it in a faraday cage that can be opened from the inside, and launch the satellite into a highly eccentric orbit timed to have its first closest approach to Earth on the date that you want, you have almost no chance of interception or destruction.

Start a family if you don't have one yet. Manipulate them throughout your life so that most of them are estranged from each other, while at the same time amassing a fortune. Make your will some kind of elaborate puzzle that will require the cooperation of everyone in your family. Hide the message with the goal of the puzzle. Die.

Your estranged family will come together again for the reading of your will and cooperate to get their inheritance. Over the course of solving the puzzle, they will reconcile and make amends in a series of heartwarming vignettes. At the end, when they finally discover where you've hidden your fortune, they'll realize that they have each other and that's worth more than money.

Also, the message will be discovered at the appropriate time.

Unless stated otherwise, I do not care whether a statement, by itself, constitutes a persuasive political argument. I care whether it's true.---If this post has math that doesn't work for you, use TeX the World for Firefox or Chrome

So I've been thinking about this problem for a while, and here's my preliminary best try:

If you encrypt the message with a weak key, it should be vulnerable to a brute force attack. You can do this in a way such that the expected value of the time taken will occur at whatever time it needs to be read, and it should be able to be read eventually anyway.

However, there's great variability here, since brute force could reach the correct key over a wide interval of times. So, to reduce the variance, have multiple encryption layers. Adjust number of layers and expected time for whatever confidence interval you desire.

Then a final layer of encryption who only the receiver has the key to, of course.

Your only problem here is if whoever's receiving it has access to a faster computer than you think. Oh, and if you just have really, really bad luck.

If anyone else can find a problem with this (or ways to improve upon it), that'd be useful.

For when the timeframe is longer than just tomorrow morning, the best option I can think of is to make use of banks/lawyers. Find a community (unrelated to said banks/lawyers) which you're fairly certain will still exist in some form at message-reading time. Open an account or trust in a name that you can use as a key, with some kind of term deposit or fund that pays out to the community on your chosen date, hoping that the banks/lawyers respect your wishes for the donation to be a surprise. Then, distribute your encrypted message to members of said community, along with enough information for them to recognise the key when they see it.

If all goes to plan, the banks/lawyers will have no idea they hold the key to anything. The members of the community will have no idea where the key is going to come from.

MoonBeans wrote:Essentially what this boils down to this: You either need to know something about the future that no one else can, or you need a process that MUST take a certain amount of time.

This depends. For the sufficiently near future, all you "need to know" is current technology (unless you insist on keeping it out of the NSA's hands for a certain time). There are certain limitations of theoretical computation, but I'm pretty sure any such calculation requires an problem that can't be run in parallel (otherwise you could keep throwing computation power at it). Brute-force decryption is embarrassingly parallel.

To make a function that required a highly accurate prediction on the amount of work needed isn't terribly difficult. The catch is knowing the time it will take to do that amount of work.

How to make a cryptosystem that will fall in n cycles:Encrypt x keys. The ciphertext should include a checksum to indicate that x was decrypted successfully. Since brute force takes a uniformly random amount of time, including the checksum makes it multiple independent random events and makes a normal random distribution, and gets more and more narrow as x increases.(Optional) Create several parity keys, Encrypt them like you did with the x keys. This removes the longer ends of the tail on one side of the random distribution. It is likely much more efficient than simply increases x to a very large number.(Optional) Modify your encryption algorithm such that brute force will be almost always more efficient than cryptanalysis. This sounds harder than it is since this is the definition of an unbroken code. In our case, since security isn't a concern we can artificially limit the size of the keys. I'd also assume that efficiency isn't a goal (you can just adjust the size of x+y for the time you want, and I'd assume this isn't going to be run all that often). My suggestion would be to limit keyspace to somewhat more than 64 bits and use a modification of AES. Use 16 rounds (a vast overkill for ~64 bit keys, but there are weaknesses in the standard sizes) and generate the subkeys by hashing the ~64 bit key with SHA512 (hash the ~64 bit key, and take the top 128 bits for the first subkey, then hash the whole thing for each subkey (taking the top 128 bits for each one)).IMPORTANT: each "x" must be completely random: use lots of physical randomness plus hashing, and take only a small portion of your results, repeat as desired (certainly the last stage should gather up all the small portions into the size of your hash). I'm almost certainly sure Reed Solomon will work (but don't use ldpc or any other less than perfectly efficient scheme) since there just isn't a way to encode n+1 bits of information into n bits, but you want to use a "secret sharing" encryption method.

PROBLEM: You now have to somehow encrypt your message with all your "x" keys. The obvious method is to use some cryptosystem that is harder to break than simply brute forcing the x keys as desired, but that is an open problem. You could try some sort of error-correction scheme where you have equal amounts of message and parity bits, and use the parity bits as the "x" keys, but finding a system that doesn't give *any* information with less than x keys will be difficult. Combining the two may be a good idea.

But for any budding Harry Seldons (beyond the issues that complexity and non-linearity shoot down the whole idea of psychohistory), you would have to assume that Moore's law is dead (it's hardly dead, and certainly not even close to for what Moore actually said) and that you would have to create exactly the hardware needed to break the code above (and nobody would build even extra parts for it) to hit a specific time.

Iterate the PRNG for a very long time, over many cycles. Make a note of how many cycles you use.

Use the generated random string to One-Time-Pad your message.

Erase the generated string

Publish the cypher-text, along with a note of what PRNG you used, your seed and the number of iterations you used.

The weakness is that someone with more dakka (i.e. access to more computing power) can possibly finish the iterations faster than you did. Essentially you have made it so that is costs a certain amount of BitCoin to unlock your message.

eternauta3k wrote:I bet there's some funky way to do this involving a betting pool. Make your secret the XOR of a million bit sequences. Choose a million people and let them bet on the time that the secret is revealed, but first place your bet on the time you want the message out. If each participant is perfectly greedy and perfectly rational, they'll join their sequences at the time you chose (???).

If everyone knows when to join, and everyone does so - thus all winning - where are sufficient losses to be worth their time going to come from?

From you. You place a large bet that it will come out when you want it to, expecting to take the loss.

This does require a reasonably trustworthy brokerage to moderate the bet (and if you have access to trustworthy people who'll still be around when you want the message released, you can probably just pay them to hold it), and it fails if some third party is willing to lose more than you just for the sake of seeing the message early, OR if one of the secret-keepers is bribed to release the message late.

MichaelKarnerfors wrote:[copy of method deleted.]The weakness is that someone with more dakka (i.e. access to more computing power) can possibly finish the iterations faster than you did. Essentially you have made it so that is costs a certain amount of BitCoin to unlock your message.

The problem with this method is that assuming equal "dakka", you can only set the time for unlocking equal to the time for locking.T0: time you start generating random numbers.T1: time completeT2: time publishing your locked messageT3: time your message is unlocked.T3-T2 will equal T1-T0 with equal "dakka". Actual time will be T2+(T1-T0)(D0/D1) where D0 is your "dakka" and D1 is your message opener's "dakka".

It is very unlikely that your message opener will have less "dakka" than you (unless you happen to be the NSA, google, or one of the larger bot herders). Expect this to only work for very short times (which means openers are unlikely to build custom ASICS, thus allowing you to expect desktop CPUs to have the fastest way to generate highly serial CPRNGs faster than any expected hardware). Having an extra CPU core generate this for several years may or may not mean an equal time needed to break the message.

"ammount of bitcoin"??? Only if you decide against using a highly serialized algorithm. If you use an algorithm that can be run in parallel, then "dakka" increases no less than linearly, and can be cranked up further by more exotic means (like bitcoin dakka already has). If you use a serial algorithm (like bcrypt or other slow hash) you can easily control how much "dakka" a message opener can throw at the problem (and thus have a good idea of the earliest the message will be read). For pretty much all of these algorithms, the price of bitcoins mined is going to be less than the cost of electricity used (except for botherders stealing cycles and electricity).

Get two appropriately tough and reliable laptops/mobile computers complete with satellite phones and batteries for the delay required.

One has the encrypted message and the other has a key.

Place each of them in one of the most uninhabited places on the planet. Amazon jungle, borreal tundra, Namib desert, Australian outback et cetera, appropriate time then they connect to the Internet and send an email.

BattleMoose wrote:Get two appropriately tough and reliable laptops/mobile computers complete with satellite phones and batteries for the delay required.

One has the encrypted message and the other has a key.

Place each of them in one of the most uninhabited places on the planet. Amazon jungle, borreal tundra, Namib desert, Australian outback et cetera, appropriate time then they connect to the Internet and send an email.

Two? Get sixty of them and have them all connect to the Internet at the same time. Use Shamir Secret Sharing to encode the key, so that any 55 of the computers together carry enough information to decrypt the message - so up to 5 of them can be damaged or destroyed, and the message will still get through. (Adjust these numbers based on your requirements and capabilities.)

Although I'm not sure how you'll get Internet access in the Namib desert. Satellites?

If you expect to be alive at the chosen time then it is simple. Just encrypt with a passphrase, and provide the passphrase at that time. Yes, someone could bludgeon you till you give the passphrase. But then they could bludgeon you until you gave the original message too!

If you do not expect to be alive then it is harder. Parapsychologist Robert Thouless used the phassphrase method to test whether it was possible to to communicate with the dead. He encoded a message with a passphrase which he never told anyone while alive, then published the encrypted message and promised mediums that he would do his level best after death to let them know the passphrase. I think I remember reading that there was a prize for the medium that decoded the message. Needless to say, no medium managed to claim the prize even though many showed interest in the scheme. Eventually the passphrase was cracked by a compsci using a brute force attack.

wumpus wrote:If I try to channel my inner Randal and answer this "what if" style, I would tell you to forget about "encoding":

Send that sucker on a planetary journey (especially around the outer planets) that isn't coming home till "a certain time".

http://xkcd.com/1337/ Like so.For bonus points, use a spacecraft that has a nuclear backed ion propulsion system. Once it gets going, it gets extremely difficult to catch up.

How many SF stories have the last colonization group leaving the solar system arriving ahead of the first because of improved propulsion?

How many encryption schemes have been broken? How many become obsolete?Any orbit that goes a long distance and comes back will be highly elliptical. It will spend nearly all its time as far away as possible. While it may be possible to get a rocket that puts out more thrust over time than current ion engines, it should still take a significant time to get there. You also get the benefit that in the standard case (people just wait for it to come back), the message is played at precisely the right time (encryption methods heavily depend on the speed of the decrypting computer[s]).

I think the problem with the solutions in this thread so far is that they rely too much on the human factor. I think one could design a system that doesn't rely on people at all.

Here's a very rough (but fully mathematical/computational) idea I had on how to do that:

The Bitcoin blockchain is built so that new blocks are generated at a near-constant rate of 6 blocks/hour.

The amount of computer hours that goes into the creation of each block is so huge that there is no feasible way to create a fake chain.

The algorithmic steps needed to verify that a blockchain is valid are simple.

So, if you examine the blockchain, make a note of the last block's contents, and some time later I tell you about 12 new blocks and their contents and you verify they're valid, you know that at least two hours have passed since you last looked. So basically it's an easily accessible way for a computer to verify that the time is in fact X without needing to trust the source.

This means that a computer can (approximately, +- 10% error) verify that the date/time now is no-earlier-than-X given access to the blockchain up until block X (technically the block headers would be enough).

So, one could create a program that would know about a "checkpoint" in the blockchain and would take a sequence of new blocks as its input, verify that they're valid, and using these two bits of data calculate the time, and if it's past a certain point it would release the private key used to encrypt the message.

The problem with such a system is that it's transparent and reverse-engineer-able. So a good way to make it more secure/opaque is to black-box the whole thing using some kind of homomorphic encryption.

I'm not surprised a few others have mentioned bitcoin in this thread. It's one example of cumulative encryption being used to mark the time.

People don't seem to like the elliptical orbit idea, even though it seems to work pretty well.

What about something similar, but here on Earth...just use the ocean. Drop a hardened transmitter box attached to weights somewhere in the Pacific Ocean, programmed to release the weights and rise to the surface to broadcast its signal after a preset amount of time has passed.

The chances of finding a single box on the ocean floor are pretty much nil.

George2 wrote:I think the problem with the solutions in this thread so far is that they rely too much on the human factor. I think one could design a system that doesn't rely on people at all.

Here's a very rough (but fully mathematical/computational) idea I had on how to do that:

The Bitcoin blockchain is built so that new blocks are generated at a near-constant rate of 6 blocks/hour.

The amount of computer hours that goes into the creation of each block is so huge that there is no feasible way to create a fake chain.

The algorithmic steps needed to verify that a blockchain is valid are simple.

So, if you examine the blockchain, make a note of the last block's contents, and some time later I tell you about 12 new blocks and their contents and you verify they're valid, you know that at least two hours have passed since you last looked. So basically it's an easily accessible way for a computer to verify that the time is in fact X without needing to trust the source.

This means that a computer can (approximately, +- 10% error) verify that the date/time now is no-earlier-than-X given access to the blockchain up until block X (technically the block headers would be enough).

That's an awfully convoluted system just to implement a timer that can't be messed with externally. Wouldn't it be much easier to just put a (reasonably accurate) clock in it. You've pretty much already lost as soon as someone has physical access to the system in either case, why make it depended on an external source?

peregrine_crow wrote:That's an awfully convoluted system just to implement a timer that can't be messed with externally. Wouldn't it be much easier to just put a (reasonably accurate) clock in it. You've pretty much already lost as soon as someone has physical access to the system in either case, why make it depended on an external source?

Unless I completely misunderstood you're suggestion, of course.

It's not meant to be practical. Just a (theoretical) idea for how to do it with just bits on a regular computer that relies on an unfakeable outside source to verify the time.

You have to rely on some source for the time. If you make it so that it checks the computer time then a hacker can just change that, if you use a system that relies on how fast the computer is then you get a lot of variation depending on the processing power.

How would I lose if someone has physical access to it? I already assumed that any person who wants to execute it can look at the bytes that make up the program.

TBH I am reconsidering this idea too. I wonder if there is an encryption algorithm that would be limited by another limiting factor altogether in the decryption part that is constant across platforms (i.e. not processor speed or the number of computers or the space available)

You could always just use weak encryption (that is expected to take T/N seconds to break) and encrypt it N times.If you make T/N short enough then there will be no advantage to parallelizing the sequential decryptions (*) and the only sensible way to decrypt would be brute force on one really fast core. Then it is just a case of choosing N based on the speed of the fastest core known to man.

(*)I'm not sure about this myself, since there may be parallelization techniques which will be worthwhile no matter how short T/N is. But it is an idea!

I believe there may be a solution in Quantum coherence. In NMR there is an effect called spin echo. A signal is imprinted on the nuclear spins of a substance using a magnetic pulse ("90° pulse"), and then the system is left to decohere for time τ. After this time a second pulse ("180° pulse") is applied to the system. After another time τ the signal magically reappears, and it is f.a.p.p. impossible to know whether a spin echo will appear before it does. You could prepare some systems in advance where only you know if a 90° pulse has been applied, and when it should reappear, and use them to send a message into the future.

The drawbacks:1) Spin-Spin relaxation causes the echo to weaken, so the method can only work for a few seconds at most.2) If you controll the magnetic field you could speed up the refocussing3) It is completely impractical

Something else may work with coherent optics, where you would split a laser signal into two optical fibers of different length. They are coherent when the signal is send, but because the fibers have a length ratio such that the signal must round trip the fibers for time t before the constructively interfere again, we don't know if a signal has been prepared or not. Using light prevents the magnetic speedup, but it might be possible to change the fiber length to produce a speedup. Otherwise similar drawbacks apply. Dispersion and absorption will probably prevent the method from ever beeing practical.

Theoretically, I'm inclined to favour the repeated hashing solutions. Of course, they do require the intended recipient to spend an ungodly amount of resources legitimately decrypting your message...

Using several independent trusted parties to pass One Time Pads sounds a lot more reasonable, so in practice I'd prefer that.

Passing things into orbit is... an interesting idea, and certainly what-if style. It also implies you have enough resources to use many more conventional means, up to and including bribing entire governments to help keep your secret. So, for anyone outside the 1% (or 0.01%...), the way to go is crypto. And on that subject...

You do not roll your own crypto. This is an important lesson imparted to all security students at my university. Even if you're a qualified security expert and know a lot about crypto, you do NOT roll your own crypto (and if your ARE a qualified security expert, you know why). The chance of there being a hole in your algorithm is too high, and NSA loves that kind of stuff, since they employ people who are better than you, and they WILL crack your algorithm. YOU DO NOT ROLL YOUR OWN CRYPTO, because cracking an algorithm is often easier than cracking the key, unless the algorithm has proven its resilience by being thoroughly inspected by a lot of really smart people and remaining uncracked. So, it's not wrong to think of new crypto schemes, but it is wrong to use them and think they'll be effective. Rather, if you really think they are good and valuable, you should publish them as a crypto proposal, get the crypto community to look at it, and if they can't shoot a hole in it, you can probably rely on it to be somewhat safe.

And now, one last time in case anyone is thinking of actually using any new scheme proposed here: YOU DO NOT ROLL YOUR OWN CRYPTO.

Sorry, I felt it needed to be said. Use well-known and verified crypto libraries (I hear NaCl (pronounced "salt") is quite good). In this case, if you're going with the repeated hash solution, use a known strong hash which is specifically known to have the properties you want (e.g. you can't compute the n'th hash any more efficiently than recursively hashing n times). Alternatively, look up "proof of work" schemes, and select one that works by making the one doing the work find some secret number, with that number being your key.

Finally, of course, if you're just trying to hide something from your family, most people's families aren't very good at cryptanalysis, and rolling your own crypto would not result in a real security problem. It would, however, be a lot more work and still be less secure than just using good prefab crypto, and leaving a one time pad with a lawyer should work just fine as well. Trusted parties are an essential part of practical security, although of course you need to know how far you can trust them (Maxim 30: A little trust goes a long way. The less you use, the further you'll go). But lawyers tend to be pretty safe, and if one isn't, he soon won't be a lawyer any more. Banks also tend to be good, and more resistant to simple theft of your secrets.

Ps. Also, please take care, when using known-to-be-good crypto schemes, to use them correctly: keep your key secret and safe, don't recycle your nonces, and try to get some really good randomness for operations that require it. Using an existing good scheme is easier than designing one yourself, but I'd still recommend you do some background research on security first, and then research the specific scheme you want to use for known ways it can be misapplied. Some schemes are fine in principle, but are broken if you use it in a specific way which isn't wrong for most schemes, but opens a hole in that specific scheme. Easiest example: most schemes are fine if you use the same key multiple times. OTP is a great scheme, but if you recycle your key, it becomes trivially vulnerable to a known plaintext attack.

This reminds me of a quote from my cryptography professor:"When you consider any security system, the question is never 'is it secure?', but 'is it secure enough?'"You simply have to minimize the incentive for any potential adversaries to attack it in the first place.

1. Make sure nobody knows you are transmitting the delayed message.2. Create a connection between the message trigger and some inconspicuous event.3. Tell a reliable person (or create a system) to trigger the event at a particular time.4. Optionally, create a red herring that is hidden in a more traditional way to throw off any adversaries.

For example:Modify your toilet to fill up with water really slowly. Put your message inside the toilet. Come up with a system to use the physical trigger (that stops the toilet from filling up) to trigger your message being sent. For the typical person, it would just seem like your toilet is leaky.

If you're extra paranoid:Go to your computer and make a file containing a very long string of random bits. Set up your computer to send the file to the same recipient as the message. A hacker would overthink it and try to crack your "cipher".Better yet, actually encrypt a message instead of using a random string. Have the message direct the hacker on a wild goose chase cracking various ciphers.

This is a block of text that can be added to posts you make. There is a 300 character limit.

Even if you were to create a system that could not be hacked, there is still the security of the creator of that system to worry about. There was a comic that addressed this but I don't remember what number it was.

Regarding not rolling my own crypto: I was thinking of starting Dan Boneh's crypto class again (I dropped out the first time but greatly enjoyed it). However, it feels like a bad idea that'll only make me confident enough to be dangerous. Thoughts?

I have two ideas that may work, but their are 3 down sides. 1: You have to be smart. By smart I mean able to do plan out the Voyager missions by your self levels of smart. 2: You have to be rich enough to launch a payload into interplanetary space. The use of a company to send the payload for you is allowed as long as they do not see you put the message in the safe.3: The time from sending message to receiving message must be at least 3 years, if the planets are in alignment (metaphorically and literally). That is just a rough estimate, but you get my point.

Build a satellite with the following in it:1)Solvent (a fluid)2)Solute (a solid)3)An accurate accelerometer4)An external thermometer5)Plenty of fuel6)Autonomous computer7)An accurate clock8)Strong 'hollow' safe9)Really small piece of an explosive10)Whatever something that measures magnetic fields is called

Physically write or encode your message on the solute (https://xkcd.com/1353/). Put it in the safe. The walls of the safe have 5 layers. From the outside going in, they are; protective material, glass, solvent, glass, lead. The glass is a hollow taurus (donut) filled with the solvent.The glass in under tension like a Prince Rupert's Drop. This means it is strong, and more importantly, a break in any part of it causes the whole thing to shatter violently. The lead is very thin foil, just enough to stop radiation. If the glass shatters, it should be able to rip through the lead with very little resistance. As an alternative, you could make the glass with lead in it. This system ensures that anyone attempting to force through a wall of the safe will break the glass, causing the released solvent to dissolve the solute. With the solute no longer in a physical form, the message has been lost. It is recommended that you pick a solute-solvent combination react quickly and that a small sample of the saturated solvent can hold a lot of solute. Write a message explaining all of this on the outside of the safe, ensuring anyone who values your message will not force their way through the safe. To put it simply, the receiver must open the safe using the lock, as you intended. Also, the solute should react violently with radiation.* I will explain why later.

Now for the time factor. Build the satellite I described above and put the safe in it. Launch the satellite so that it reaches the outer planets. It may require gravitational assists (GA) from the inner planets. This is the most dangerous part because while it is in the inner planets, an eavesdropper (Eve) can launch a satellite to intercept it. I will explain later how to fix this problem. While near the outer planets, two general paths can be taken.

1) Send the satellite on a course that will give it a GA from Jupiter toward Saturn. Saturn uses a GA to send it to Jupiter or Uranus. The satellite will be passed back and in this way between the outer gas giants. This will ensure that intersecting it with another satellite will be incredible hard. It would make Rosetta look like child's play. After t time has passed, the satellite is sent back to Earth. It then lands on the Moon, or it enters orbit around the either the Earth, the Moon, the Sun, or a Lagrange point. The point is that it is now easily accessible (relatively speaking) to the people on Earth.

2) The second method is that you put the satellite in an orbit around the Sun and as far out as the Gas Giants. The satellite orbits from far way for a while. When the atomic clock hits a certain number, it begins its trip back.

No matter what we do, there is always a chance that Eve could send a satellite that intercepts your's. This is very easy to prove. If our satellite got there, then Eve's satellite can get there too. That is what the sensory equipment is for. If another satellite manages to intercept our own and started moving toward earth, then the accelerometer will detect the change in acceleration. If the other satellite is accelerating so slowly that our accelerometer cannot detect it (such as an ion engine), then the emissions from the engine will be detected by the thermometer or the magnetic detector thingy-a-bobber. If the satellite has a mechanical arm and that opens the mechanical lock, the solute will be exposed to radiation and is altered enough that the message is lost. If a space station, with people on it, intercept the satellite and try to open it in the station, (where there is little radiation) then the thermometer will detect the sudden rise in temperature. When any of the equipment detects a change, it will send the data to the computer. The computer will then check the clock and its records to see if this data is expected. Then the computer will detonate the explosive. Just to be clear, the explosive is inside the safe and is a shape charge designed to break the glass taurus. Even under ~0g some of the solvent will float toward and touch the solute, destroying the message. If this is not enough, you could always set the lock mechanism such that when it is opened it tells the computer.

The best way to test how secure your system is by measuring how much resources Eve would have to use to get it. The unit on this measurement would be Dollar-Time.

-jewish_scientist

*I have to give credit for this to The da Vincei Code. I read the book, so I do not know if this is in the movie. There is basically a safe that works like a bicycle lock with some interesting mechanisms in it. It contains a glass bottle of vinegar that has a 'paper' wrapped around it. The 'paper' is made out of something that dissolves in vinegar. As, you can guess, the message is written on the 'paper'. If the rings on the safe are lined up to spell the password, the safe can be pulled apart and the message is yours. However, if you try to pull apart the safe with the wrong password, pistons in the safe will move inward until they smash the bottle. The vinegar is released, dissolving the 'paper' and destroying the message.

It's still limited by computing power, so a faster computer can decode the message first. The clever bit is that encoding the message can be parallelized, so you can do it on a supercomputer or a GPU cluster. Decoding takes just as many CPU-years, but can't be parallelized, so it can't be done on a supercomputer and it should take much longer because of that.

It's still limited by computing power, so a faster computer can decode the message first. The clever bit is that encoding the message can be parallelized, so you can do it on a supercomputer or a GPU cluster. Decoding takes just as many CPU-years, but can't be parallelized, so it can't be done on a supercomputer and it should take much longer because of that.

Isn't this Alzibub's idea?:

Alzibub wrote:Here's a solution inspired by the blockchain idea:

You could always just use weak encryption (that is expected to take T/N seconds to break) and encrypt it N times.If you make T/N short enough then there will be no advantage to parallelizing the sequential decryptions (*) and the only sensible way to decrypt would be brute force on one really fast core. Then it is just a case of choosing N based on the speed of the fastest core known to man.

(*)I'm not sure about this myself, since there may be parallelization techniques which will be worthwhile no matter how short T/N is. But it is an idea!

Probably the most feasible idea, because "single, really fast core" is already hitting the limits of what's physically possible (in a single clock cycle at 3 GHz, light only travels 10 cm, which is in the same order of magnitude as the size of the chip). Downside is that you can't just have the message sit around - it will constantly drain resources, or you won't get it decrypted in time.Another good option might be to put it on an elliptical orbit around the sun that will intersect earth's at the defined time. Catching up with it and getting it back significantly quicker than it would by itself is going to use a lot of fuel until we invent a reactionless drive. And since your engine will have to burn most of the time, you will be easily detectable by any earthbound telescopes watching the thing.Too bad that divergence in vacuum is a thing - otherwise you might be able to slingshot the message around a few black holes or other very massive objects, if your aim is good and you're willing to wait for a few million years

Autolykos wrote:Probably the most feasible idea, because "single, really fast core" is already hitting the limits of what's physically possible (in a single clock cycle at 3 GHz, light only travels 10 cm, which is in the same order of magnitude as the size of the chip).

Assuming your algorithm isn't susceptible to quantum computing that is. It not being parallelisable is a good start, but there might conceivably be a probabilistic solution.