text:
If a program terminates and there is no one to see it, does it halt?
It's time to face the truth: We will not be here forever, but at least we can write a program that will outlive the human race even if it struggles till the end of time.
Your task is to write a program that has a expected running time greater than the remaining time till the end of the universe.
You may assume that:

The universe will die from entropy in 101000 years.
Your computer:

Will outlive the universe, because it is made of Unobtainium.
Has infinite memory/stack/recursion limit.
Its processor has limited speed.

You must show that your program terminates (sorry, no infinite loops) and calculate its expected running time.
The standard loopholes apply.
This is a code golf challenge, so the shortest code satisfying the criteria wins.
EDIT:
Unfortunately, it was found (30min later) that the improbability field of Unobtainium interferes with the internal clock of the computer, rendering it useless. So time based programs halt immediately. (Who would leave a program that just waits as its living legacy, anyway?).
The computer processor is similar to the Intel i7-4578U, so one way to measure the running time is to run your program in a similar computer with a smaller input (I hope) and extrapolate its running time.

Podium

#
Chars
Language
Upvotes
Author

1
5
CJam
20
Dennis

2
5
J
5
algorithmshark

3
7
GolfScript
30
Peter Taylor

4
9
Python
39
xnor

5
10
Matlab
5
SchighSchagh

* Upvotes on 31/08

I was tempted to create a [slowest-code] tag for this question. :P

A Bogosort wouldn't work because while it's infinitely improbable that it would never finish, it may require an infinite amount of time to finish.  There are, however many awful NFA-based regular expressions that could satisfy the "will finish, but not before the universe is dead" criteria.

Is this actually different from a challenge to make large numbers?

Your title should be a tshirt

Nice question, but shouldn't it be popularity contest ?

just out of curiosity, how long would it take to generate a duplicate GUID ?

@IazertyuiopI, no.

Been done :-)  by John Cage and his ASAP organ piece http://en.wikipedia.org/wiki/As_Slow_as_Possible

The in-character edit is what took this over the top for me, giving t it a +1.

I think Isaac Asimov wrote a story about this.

@IazertyuiopI Why? [tag:code-golf] seems like the obvious scoring metric for this.

@Calvin'sHobbies I was afraid it would encourage people to submit similar short answers (only counting to/evaluating a large number) at the expense of creativity , but since the long answers get upvoted, I guess there is nothing to worry about =P

Infinite memory isn't necessary. The processor can access only a finite amount of memory in the finite amount of time. 10^5030 bits sounds like a reasonable upper bound.

@Doorknob: The tag you were looking for is [tag:busy-beaver].  I added it.

This challenge reminded me of the minecraft 'Universe Death Clock' https://www.youtube.com/watch?v=F1CddzgVW14

Am I the only one who thought of the Ackermann function instantly when I read the description?

After the death of the universe no one can see you halt.

@PsHegger me too!

I improved my answer to 8 chars, I'm in 4th place now. :)

You should post a question with the same title on Philosophy.SE, and maybe on one of the 50 programming sites.

I am voting to close this as too broad because we require objective validity criteria for all challenges. As it stands, there is no clear way to determine the validity of a submission. Additionally, there is no specification of the behavior of a valid submission.

Will have a play with this a go on Turing Machine code. Meanwhile, gold badge vote.

CJam, 5 bytes
0{)}h

How it works
 0   " Push 0.                                 ";
 {   "                                         ";
   ) " Increment the Big Integer on the stack. ";
 }h  " Repeat if the value is non-zero.        ";

This program will halt when the heap cannot store the Big Integer anymore, which won't happen anytime soon on a modern desktop computer.
The default heap size is 4,179,623,936 bytes on my computer (Java 8 on Fedora). It can be increased to an arbitrary value with -Xmx, so the only real limit is the available main memory.
Time of Death
Assuming that the interpreter needs x bits of memory to store a non-negative Big Integer less than 2x, we have to count up to 28 × 4,179,623,936 = 233,436,991,488. With one increment per clock cycle and my Core i7-3770 (3.9 GHz with turbo), this will take 233,436,991,488 ÷ 3,400,000,000 > 1010,065,537,393 seconds, which is over 1010,065,537,385 years.

I don't think you can rely on finite resources, as the question states "Your computer has infinite memory/stack/recursion limit".

Infinite memory != infinite data types. If I have a terabyte of RAM, an unsigned 8-bit integer still only goes up to 255.

@GregHewgill: With unlimited resources, you can increase the maximum Java heap size to any arbitrary value, but it will always be finite.

@Dennis, but then just add a line every time thru the loop to double the heap size.  It's a funny thing about infinities :-)

@CarlWitthoft: You can't do that from inside the program.

JavaScript, 39
(function f(x){for(;x!=++x;)f(x+1)})(0)

Explanation
Since JavaScript does not precisely represent large integers, the loop for(;x!=++x;) terminates once x hits 9007199254740992.
The body of the for loop will be executed Fib(9007199254740992) - 1 times, where Fib(n) is the nth fibonacci number.
From testing, I know my computer will do less than 150,000 iterations per second. In reality, it would run much slower because the stack would grow very large.
Thus, the program will take at least (Fib(9007199254740992) - 1) / 150000 seconds to run. I have not been able to calculate Fib(9007199254740992) because it is so large, but I know that it is much larger than 101000 * 150,000.
EDIT: As noted in the comments, Fib(9007199254740992) is approximately 4.4092*101882393317509686, which is indeed large enough.

Since fib(n) can be approximated by phi^n, we can use log((sqrt(5) + 1)/2)*9007199254740992 to calculate how many digits fib(9007199254740992) turns out it's about 1.8823933*10^15.

@overactor, According to Wolfram Alpha, Fib(9007199254740992) (using continuous form with phi) is approximately 4.4092... * 10^1882393317509686. Calculation

growing stack does not reduce CPU speed... unless you take the limited memory address line width / unlimited address width into account (in which case the slowdown is still linear in address length assuming reasonable encoding) or even the physical limitations in memory storage and the speed of light (in which case the slowdown is cbrtic in address value assuming spatial storage; even DNA levels of data density eventually start adding up, even if you manage space-efficient random access)

Due to the way stack is implemented, you cannot have both infinite stack and infinite heap. Even if your RAM is infinite (unless having the "top of the stack" starting at @infinite -- and assuming infinite RAM is from 0 to infinite, not from -infinite to +infinite). At some point both will collide. Unless JavaScript allocates its stack frames on the heap and does not use stack at all on recursion?

Why the for loop? wouldn't it be the same as function f(x){if(x!=++x)f(x)}(0) ?

@JamesKhoury No, the function you just wrote is equivalent to for(x=0;x!=++x;) and only iterates 9007199254740992 times.

@SylvainLeroux an architecture with infinite amounts of RAM would probably just interleave the heap and stack and have them both grow upwards.

~x++ is shorter and enough time, smaller than original though

Python (9)
9**9**1e9

This has more than 10**10000000 bits, so computing it should take us far past heat death.
I checked that this takes more and more time for larger but still reasonable values, so it's not just being optimized out by the interpreter.
Edit: Golfed two chars by removing parens thanks to @user2357112. TIL that Python treats successive exponents as a power tower.

OverflowError: (34, 'Result too large')

@apple16 Maybe on your computer, but mine has an "infinite memory/stack/recursion limit".

Even if you had infinite memory, the i7 only supports, at best, 48 bits of address space. :)

It's OK, guys. I ran it last universe and got ...82528057365719799011536835265979955007740933949599830498796942400000000009 (2.6*10^954242509 digits omitted to avoid black hole collapse). You should really upgrade to Unobtanium.

Exponentiation is right-associative, so you can drop the parentheses.

Erm, actually the computation is optimized out during compilation. The fact is: the compiler is trying to compute the value to put in the bytecode constant. The loading of the result is not optimized out, however the computation of the constant is. In other words the running time of your program is only the time taken to create the int object from the binary representation, not the time taken to compute it using powers. (try to check the disassembly using the dis module). In any case the running time would be big enough.

@Bakuriu This is true for CPython, but it's not part of the specification of Python, so I think the calculation should count towards the running time. (Not that it matters, really.)

It's worth noting that 9**9**9e9 is just as short and takes slightly more universe-lengths to compute, as well as looking a little nicer.

@abarnert "Slightly" is a slight understatement...

Even 9**9e9 should be enough, shouldn't it?

Which version do you use, that 9**9e9 is an integer rather than a float?

Marbelous 68 66 bytes
}0
--@2
@2/\=0MB
}0@1\/
&0/\>0!!
--
@1
00@0
--/\=0
\\@0&0

Marbelous is an 8 bit language with values only represented by marbles in a Rube Goldberg-like machine, so this wasn't very easy.
This approach is roughly equivalent to the following pseudo-code:
function recursiveFunction(int i)
{
    for(int j = i*512; j > 0; j--)
    {
        recursiveFunction(i - 1);
    }
}

since the maximum value is 256, (represented by 0 in the Marbleous program, which is handled differently in different places) recursiveFunction(1) will get called a total of 256!*512^256 which equals about 10^1200, easily enough to outlive the universe.
Marbelous doesn't have a very fast interpreter, it seems like it can run about 10^11 calls of this function per year, which means we're looking at a runtime of 10^1189 years.
Further explanation of the Marbelous board
00@0
--/\=0
\\@0&0

00 is a language literal (or a marble), represented in hexadecimal (so 0). This marble falls down onto the --, which decrements any marble by 1 (00 wraps around and turns into FF or 255 in decimal). The Marble with now the value FF falls down onto the \\ which shoves it one column to the right, onto the lower @0. This is a portal and teleports the marble to the other @0 device. There, the marble lands on the /\ device, which is a duplicator, it puts one copy of the marble on the -- to its left (this marble will keep looping between the portals and get decremented on every loop) and one on the =0 to its right. =0 compares the marble to the value zero and lets teh marble fall trough if it's equal and pushes it to the right if not. If the marble has teh value 0, it lands on &0, a synchonizer, which I will explain further, later.
All in all, this just starts with a 0 value marble in a loop and decrements it until it reaches 0 again, it then puts this 0 value marble in a synchronizer and keeps looping at the same time.
}0@1
&0/\>0!!
--
@1

}0 is an input device, initially the nth (base 0) command line input when calling the program gets placed in every }n device. So if you call this program with command line input 2, a 02 value marble will replace this }0. This marble then falls down into the &0 device, another synchronizer, &n synchronizers hold marbles until all other corresponding &n's are filed as well. The marble then gets decremented, teleported and duplicated much like in the previously explained loop. The right copy then get checked for inequality with zero (>0) if it's not 0, it falls through. If it is 0, it gets pushed to the right and lands on !!, which terminates the board.
Okay, so far we have a loop that continuously counts down from 255 to 0 and lets another, similar loop (fed by the command line input) run once every time it hits 0. When this second loop has run n times (maximum being 256) the program terminates. So that's a maximum of 65536 runs of the loop. Not nearly enough to outlive the universe.
}0
--@2
@2/\=0MB

This should start looking familiar, the input gets decremented once, then this value loops around and get copied (note that the marble only gets decremented once, not on every run of the loop). It then gets checked for equality to 0 and if it's not zero lands on MB. This is a function in Marbelous, every file can contain several boards and each board is a function, every function has to be named by preceding the grid by :[name]. Every function except for the first function in the file, which has a standard name: MB. So this loop continuously calls the main board again with a value of n - 1 where n is teh value with which this instance of teh function was called.
So why n*512?
Well, the first loop runs in 4 ticks (and 256 times) and the second loop runs n times before the board terminates. This means the board runs for about n*4*256 ticks. The last loop (which does the recursive function calling) is compacter and runs in 2 ticks, which means it manages to call the function n*4*256/2 = n*512 times.
What are the symbols you didn't mention?
\/ is a trash bin, which removes marbles from the board, this makes sure discarted marbles don't interfere with other marbles that are looping a round and prevent the program from terminating.
Bonus
Since marbles that fall off the bottom of a marbelous board get output to STDOUT, this program prints a plethora of ASCII characters while it runs.

Great explanation, thanks!

Wow, this is a brilliant idea! The Marbelous language is so fun!

+1 Just what I wanted to see. A crazier language than BrainFuck :) Is there a website with tutorial and more info about it? (The title link seem to have less doc than your answer)

@Sylwester, I'm glad you like it, Marbelous is currently still in development but we expect to have it in a more stable condition in the near future, at which point tutorials, more extensive documentation, standard libraries and hopefully an online interpreter will follow.

GolfScript (12 7 chars)
9,{\?}*

This computes and prints 8^7^6^5^4^3^2 ~= 10^10^10^10^183230. To print it (never mind the computation) in 10^1000 years ~= 10^1007.5 seconds, it needs to print about 10^(10^10^10^183230 - 10^3) digits per second.

But it will halt long before that with a "printer out of paper" message...

@Floris who the hell uses physical media in these days?

@JanDvorak, I just assumed that Floris and the 7 people who upvoted him are from my grandad's generation, when all output was to continuous feed paper.

@PeterTaylor - maybe not quite that old, but I am old enough to recall submitting "batch jobs" to "the computer" (in the days when there was no doubt, in a student population of 20k, which computer you meant), and collecting the printout the following day. You (and 7 others) correctly surmised this was an attempt at humor, not a serious critique of your excellent and ridiculously short script.

Perl, 66 58 characters
sub A{($m,$n)=@_;$m?A($m-1,$n?A($m,$n-1):1):$n+1;}A(9,9);

The above is an implementation of the Ackermann–Péter function. I have no idea how large A(9,9) is but I am fairly certain it will take an astoundingly long time to evaluate.

+1 ... I was trying to find a language with a built-in Ackermann function, but failed to do so before my patience ran out. :D

You should try using Graham's Numbers

$n?A($m-1,A($m,$n-1)):A($m-1,1) admits an easy 8-char saving by pushing in the ternary operator.

I am pretty sure the number of digits in A(9,9) is larger than the volume of the observable universe measured in cubic Planck lengths.

@kasperd That's a pretty massive understatement. The volume of the observable universe is only on the order of 10^184 planck volumes. By comparison, there are something like 10^19700 digits in the number describing the number of digits in A(4,4), which in turn is incomprehensibly tiny compared to A(9,9).

@user19057 It sounds like calling Kasperd's claim a "massive understatement" is a massive understatement. :P

MATLAB, 58 52 characters
We need at least one finite-precision arithmetic solution, hence:
y=ones(1,999);while y*y',y=mod(y+1,primes(7910));end

x=ones(1,999);y=x;while any(y),y=mod(y+x,primes(7910));end
(with thanks to @DennisJaheruddin for knocking off 6 chars)
The number of cycles needed to complete is given by the product of the first 999 primes. Since the vast majority of these are well over 10, the time needed to realize convergence would be hundreds or thousands of orders of magnitude greater than the minimum time limit.

+1 Took a while for me to see what you are doing there. Nice!

Nice, I think some chars can be saved like so:
y=ones(1,999);while y*y',y=mod(y+1,primes(7910));end

@DennisJaheruddin: Brilliant shortening. I'll update.

Though it is not the same solution anymore, this should still be similar enough, and again a bit shorter:
p=1:9e9;y=p;while+y*y',y=mod(y+1,p),end

Mathematica, 25 19 bytes
This solution was posted before time functions were disqualified.
While[TimeUsed[]<10^10^5]

TimeUsed[] returns the seconds since the session started, and Mathematica uses arbitrary-precision types. There are some 107 seconds in a year, so waiting 1010000 seconds should be enough.
Shorter/simpler(/valid) alternative:
For[i=0,++i<9^9^9,]

Let's just count instead. We'll have to count a bit further, because we can do a quite a lot of increments in a second, but the higher limit doesn't actually cost characters.
Technically, in both solutions, I could use a much lower limit because the problem doesn't specify a minimum processor speed.

Love it! This answer made me actually laugh out loud with a big smile on my face.

Sorry, for creativity sake, I had to cut out time based solutions (like your first one). Please don't hate me. :)

@kbsou Well, I've beaten it with my other one, so I don't really care. But otherwise disqualifying answers retrospectively for rule changes isn't cool though. ;)

Is Mathematica really so slow, that computing 9^9^9 takes more than 10^1000 years? I estimate that computing 9^9^9 on my 1.3GHz U7300 using bc would take less than 6 months. (Based on extrapolating the time to compute 9^200000 and 9^400000.)

Just tested: Mathematica needs 4 milliseconds to determine that the value of 9^9^9 is Overflow[].

kk, I'm ditching that one then ;)

@MartinBüttner The idea is not totally bad though. I think 9^9^9^9 would qualify.

@kasperd Hm, good point. In fact, that's probably the one I actually meant, as it's much closer to xnor's 9^9^1e9.

@MartinBüttner 1e9 is a little bit larger than 9^9, but still use the same number of digits. If the language supports the scientific notation, one could use 9^9^9e9 which would be even larger and thus take more time to compute.

@kasperd It does, but only in the form 9*^9 so that's another character. But I think 9^9^9^9 should be enough.

Just another note: JavaScript takes (apparently) 0 milliseconds to determine 9^9^9 as Infinity

@ArtOfCode Mathematica uses arbitrary-precision types so it will actually try to determine the correct value.

Python 3 - 49
This does something useful: calculates Pi to unprecedented accuracy using the Gregory-Leibniz infinite series.
Just in case you were wondering, this program loops 10**10**10**2.004302604952323 times.
sum([4/(i*2+1)*-1**i for i in range(1e99**1e99)])

Arbitrary precision: 78
from decimal import*
sum([Decimal(4/(i*2+1)*-1**i)for i in range(1e99**1e99)])

Image source
The Terminal Breath
Due to the huge calculations taking place, 1e99**1e99 iterations takes just under 1e99**1e99 years. Now, (1e99**1e99)-1e1000 makes barely any difference. That means that this program will run on far longer than the death of our universe.
Rebirth
Now, scientists propose that in 10**10**56 years, the universe will be reborn due to quantum fluctuations or tunnelling. So if each universe is exactly the same, how many universe will my program live through?
(1e99**1e99)/(1e10+1e1000+10**10**56)=1e9701

Assuming that the universe will always live 1e10+1e1000 years and then take 10**10**56 years to 'reboot', my program will live through 1e9701 universes. This is assuming, of course, that unobtainium can live through the Big Bang.

But does it terminate?

it terminates once it reaches the end of the range @Philipp. yes it terminates, eventually.

@Philipp it's a for loop, how wouldn't it terminate?

1000**1000 is 1e3000, not 1e2000.

Does that simple algorithm actually calculate pi to arbitrary precision?

@Cornstalks Thanks, I didn't have a calculator good enough to find that so I made a guess based on the fact that 100**100=1E200.

@BetaDecay: I might suggest Wolfram|Alpha as an online calculator. If you haven't ever used it, it's pretty awesome!

@anyoneinterested Or 1000^1000 = (10^3)^1000 = (101010)(101010)...(1010*10) [1000 times] = 10^3000

Python 59 (works most of the time)
I couldn't resist
from random import*
while sum(random()for i in range(99)):0

While its true that this could theoritically terminate in under a millisecond, the average runtime is well over 10^400 times the specified lifespan of the universe. Thanks to @BetaDecay, @undergroundmonorail, and @DaboRoss for getting it down a 17 characters or so.

To get it down to 71 you can replace continue with pass

@BetaDecay Nice catch

I'm not sure where your character count is coming from. I'm getting 66. You can (probably, I haven't tested it) get that down to 64 by removing the square brackets.

@undergroundmonorail Oh I forgot to change that from an older version and I did test removing the brackets and it worked (I also changed xrange to range for a total score of 63).

Thought of another improvement: random is a long enough module name that you save overall by doing from random import* and taking away the random. from random.random().

I think since the question asks for the expected running time, it's not a problem that this might terminate early. The larger issue is that it can't be proven to terminate at all.

@user19057 Well assuming that Python's random is truly random, each possible outcome having an equal chance of occurring and being completely mutually exclusive from previous outcomes (which admittedly it might not be), I don't think you could say that it would NEVER terminate. As the runtime approaches infinity, the probability of termination approaches one.

@user19057 Assuming what KSab said, the expected running time is finite and the program terminates with 100% probability. Of course the random module actually uses a PRNG, which is cyclic, so most likely this will never terminate.

I think you can cut off 3 characters by replacing 'pass' with '0'.

J - 5 chars, I think
Note that all of the following is in arbitrary precision arithmetic, because the number 9 always has a little x beside it.
In seven characters, we have !^:!!9x, which is kinda like running
n = 9!
for i in range(n!):
    n = n!

in arbitrary precision arithmetic. This is definitely over the limit because Synthetica said so, so we have an upper bound.
In six chars, we can also write ^/i.9x, which calculates every intermediate result of 0 ^ 1 ^ 2 ^ 3 ^ 4 ^ 5 ^ 6 ^ 7 ^ 8. Wolfram|Alpha says 2^3^4^5^6^7^8 is approximately 10 ^ 10 ^ 10 ^ 10 ^ 10 ^ 10 ^ 6.65185, which probably also clears inspection.
We also have the five char !!!9x, which is just ((9!)!)!. W|A says it's 10 ^ 10 ^ 10 ^ 6.2695, which should still be big enough... That's like 1.6097e1859933-ish digits, which is decidedly larger than 3.154e1016, the number of nanoseconds in the universe, but I'm gonna admit I have no idea how one might figure out the real runtimes of these things.
The printing alone should take long enough to last longer than the universe, though, so it should be fine.

C, 63 56 chars
f(x,y){return x?f(x-1,y?f(x,y-1):1):y+1;}main(){f(9,9);}

 This is based on an idea by a guy named Wilhelm. My only contribution is condensing the code down to this short (and unreadable) piece.

Proving that it terminates is done by induction.

If x is 0, it terminates immediately.
If it terminates for x-1 and any y, it also terminates for x, this itself can be shown by induction.

Proving the induction step by induction:

If y is 0 there is only one recursive call with x-1, which terminates by induction assumption.
If f(x, y-1) terminates then f(x, y) also terminates because the innermost call of f is exactly f(x, y-1) and the outermost call terminates according to the induction hypthesis.

 The expected running time is A(9,9) / 11837 seconds. This number has more digits than the number of quarks in the observable universe.

(Ab)use the preprocessor and define m=main, r=return, and z=99999, then rewrite your program as, f(x,y){r x?f(x-1,y?f(x,y-1):1):y+1;}m(){f(z,z);} which will take an amazingly long time :-)

@ChuckCottrill If the rules allowed programs, which require specific preprocessor macros, and those did not count towards program length, then any task can be solved in one character.

Matlab (10 8 chars)
1:9e1016

IMHO, most entries are trying too hard by computing large, complicated things. This code will simply initialize an array of 9x101016 doubles counting up from 1, which takes 7.2x10^1017 bytes. On a modern CPU with a maximum memory bandwidth of 21 GB/s or 6.63x10^17 bytes/year, it will take at least 1.09x101000 years to even initialize the array, let alone try to print it since I didn't bother suppressing the output with a trailing semicolon. (;

old solution(s)
nan(3e508)

Alternatively
inf(3e508)

This code will simply create a square matrix of NaNs/infinities of size 3e508x3e508 = 9e1016 8-byte doubles or 7.2e1017 bytes.

What's that? 1016? That must be 9999! (Or did I misunderstand something?)

@MegaMan The problem prompt asks for runtime lower bound of 10^1000 years. This being golf, I didn't want to be wasteful and compute too much longer than that, so I tried to get it to stop as soon after reaching the threshold as possible. :)

ah, ok, didn't know this rule

Perl, 16 chars
/$_^/for'.*'x1e9

This builds a string repeating ".*" a billion times, then uses it as both the needle and the haystack in a regex match. This, in turn, causes the regex engine to attempt every possible partition of a string two billion characters long. According to this formula from Wikipedia, there are about 1035218 such partitions.
The above solution is 16 characters long, but only requires about 2Gb of memory, which means it can be run on a real computer. If we assume infinite memory and finite register size (which probably doesn’t make sense), it can be shortened to 15 characters while dramatically increasing the runtime:
/$_^/for'.*'x~0

(I haven’t tested it, but I think it could work with a 32-bit Perl built on a 64-bit machine with at least 6Gb of RAM.)
Notes:

x is the string repeat operator.
the for isn’t an actual loop; it is only used to save one character (compared to $_=".*"x1e9;/$_^/).
the final ^ in the regex ensures that only the empty string can match; since regex quantifiers are greedy by default, this is the last thing the engine will try.
benchmarks on my computer for values (1..13) suggest that the running time is actually O(exp(n)), which is even more than the O(exp(sqrt(n))) in the Wikipedia formula.

J (12)
(!^:(!!9))9x

What this comes down to in Python (assuming ! works):
a = 9
for i in range((9!)!):
    a = a!

EDIT:
Well, the program can take, at most, 2 × 10^-1858926 seconds per cycle, to complete within the required time. Tip: this won't even work for the first cycle, never mind the last one ;).
Also: this program might need more memory than there is entropy in the universe...

"might need more memory than there is entropy in the universe" - You can cut down on that with xrange() ;)

Also, ! doesn't work in Python. You need import math and math.factorial().

First attempt at code golf but here goes.
VBA - 57 45
x=0
do
if rnd()*rnd()<>0 then x=0
x=x+1
while 1=1

So X will go up by one if a 1 in 2^128 event occurs and reset if it does not occur.  The code ends when this event happens 2^64+1 times in a row.  I don't know how to begin calculating the time but I'm guessing it is huge.
EDIT: I worked out the math and the probability of this happening in each loop is 1 in 2^128^(1+2^64) which is about 20000 digits long.  Assuming 1000000 loops/sec (ballpark out of thin air number) and 30000000 s/yr that's 3*10^13 cycles per year time 10^1000 years left is 3*10^1013 cycles, so this would likely last around 20 times the remaining time left in the universe.  I'm glad my math backs up my intuition.

I think that the last line should be While x=1, right? (otherwise its an infinite loop). Also, you can shave off 12 chars if you substitute Dim x As Double with x=0 (VBA doesn't require to declare variables unless you specify Option Explicit)

I don't look at it as an infinite loop as it breaks when x overflows which is eventually.

It definitely doesn't work with while x=1 as this would generally prevent the loop from running.

If breaking the in this way loop doesn't meet the "no infinite loops" criteria the WHILE 1=1 could change to WHILE ISNUMERIC(X).

C# 217
I'm not much of a golfer, but I couldn't resist Ackerman's function. I also don't really know how to calculate the runtime, but it will definitely halt, and it will definitely run longer than this version.
class P{
static void Main(){for(int i=0;i<100;i++){for(int j=0;j<100;j++){Console.WriteLine(ack(i,j));}}}
static int ack(int m,int n){if (m==0) return n+1;if (n ==0) return ack(m-1,1);return ack(m-1,ack(m,n-1));}
}

You can save 10 bytes by renaming the ack function to a single-character name like a.

C, 30 characters
main(i){++i&&main(i)+main(i);}

Assuming two's compliment signed overflow and 32-bit ints, this will run for about 2232 function calls, which should be plenty of time for the universe to end.

You'll run out of stack long before then, though.

@Sparr One of the rules is to assume infinite stack and heap size.

R, 45 bytes
(f=function(x)if(x)f(x-1)+f(x-1)else 0)(9999)

It's an old thread but I see no R answer, and we can't be having that!
The runtime for me was about 1s when x was 20, suggesting a runtime of 2^9979 seconds.
If you replace the zero with a one, then the output would be 2^x, but as it stands the output is zero whatever x was (avoids overflow problems).

Equivalent 38 byte version.

I'm not sure yours is equivalent — it doesn't fork the calls in the same way, and indeed your TIO example runs for argument 9999 in under a second (I think a pair of brackets would fix that, though).

My bad, I included an extra !. This is equivalent (and 37 bytes). You can also shave off another byte with 1e4 instead of 9999.

GolfScript, 13 chars
0{).`,9.?<}do

This program just counts up from 0 to 1099−1 = 10387420488.  Assuming, optimistically, that the computer runs at 100 GHz and can execute each iteration of the program in a single cycle, the program will run for 1099−12 seconds, or about 3 × 1099−20 = 3 × 10387420469 years.
To test the program, you can replace the 9 with a 2, which will make it stop at 1022−1 = 103 = 1000.  (Using a 3 instead of a 2 will make it stop at 1033−1 = 1026, which, even with the optimistic assumptions above, it will not reach for at least a few million years.)

Autohotkey  37
loop {
if (x+=1)>10^100000000
break
}

~ATH, 56
In the fictional language ~ATH:
import universe U;
~ATH(U) {
} EXECUTE(NULL);
THIS.DIE()

~ATH is an insufferable language to work with. Its logic is composed
of nothing but infinite loops, or at best, loops of effectively
interminable construction.
What many ~ATH coders do is import finite constructs and bind the
loops to their lifespan. For instance the main loop here will
terminate on the death of the universe, labeled U. That way you only
have to wait billions of years for it to end instead of forever.

I apologize for the borderline loophole violations; I thought it was too relevant to pass up.
If anyone was actually amused by this, more details: (1), (2), (3), (4)

Haskell, 23
main=interact$take$2^30

This program terminates after reading 1073741824 characters from stdin.  If it's run without piping any data to stdin, you will have to type this number of characters on your keyboard.  Assuming your keyboard has 105 keys, each rated for 100k mechanical cycles and programmed to generate non-dead keystrokes, autorepeat is off, and your keyboard socket allows 100 connection cycles, this gives the maximum number of keystrokes per computer uptime of 1050000000, which is not enough for the program to terminate.
Therefore, the program will only terminate when better hardware becomes available in terms of number of cycles, which is effectively never in this running universe.  Maybe next time, when quality has higher priority than quantity.  Until then, this program terminates in principle but not in practice.

What if you hot-swap keyboards as you go?

That's covered by the 100 connection cycles of the keyboard socket.

But the point of the problem is that the program does terminate, somewhere after the heat death of the universe. This program can't possibly ever terminate; once entropy gets high enough, you will never have another keyboard to plug in.

I am still not convinced. If you run the program remotely (or in a VM), then you aren't limited by the hardware capabilities of a single computer, and 1 billion strokes really isn't that much. Besides, the problem says the computer is made of unobtainium, and so the keyboard should also be, hence, it can handle 2^30 keystrokes...

APL, 10
I don't think this is a valid answer (as it is non-deterministic), but anyway......
{?⍨1e9}⍣≡1

This program calculates a random permutation of 1e9 numbers (?⍨1e9) and repeats until two consecutive outputs are equal (⍣≡)
So, every time a permutation is calculated, it has a 1 in 1000000000! chance of terminating. And 1000000000! is at least 10108.
The time it takes to calculate a permutation is rendered irrelevant by the massiveness of 1000000000!. But some testing show this is O(n) and extrapolating gives about 30 seconds.
However, my interpreter refuses to take inputs to the random function larger than 231-1 (so I used 1e9), and generating permutations of 1000000000 numbers gave a workspace full error. However, conceptually it can be done with a ideal APL interpreter with infinite memory.
This leads us to the possibility of using 263-1 in place of 1e9 to bump the running time up to at least 101020, assuming a 64-bit architecture.
But wait, is architecture relevant in an ideal interpreter? Hell no so there is actually no upper bound on running time!!

Ruby(34)
The line ([0]*9).permutation.each{print} takes about 2.47 seconds for 9! prints on my machine, while the line ([0]*10).permutation.each{print} takes about 24.7 seconds for 10! prints, so I guess I can extrapolate here and calculate (24.7/10!)*470! seconds in years which is 6.87 * 10^1040, which should be the run time of:
([0]*470).permutation.each{print}

JavaScript 68 62 chars
(function a(m,n){return m==0?n+1:a(m-1,n==0?1:a(m,n-1))})(5,1)

This uses the Ackermann-function which can be written as
function ackermann(a, b) {
  if (a == 0) return b + 1;
  if (b == 0) return ackermann(a-1, 1);
  else return ackermann(a-1, ackermann(a, b-1));
}

Its runtime time increases over exponentially and takes therefore very long to calculate. Even though it is not english here you can get an overview of its return values. According to the table ackermann(5,1) equals 2↑↑(65533)-3 which is, you know, very big.

This can benefit from some of the same optimisations as the earlier Perl Ackermann function implementation.

I must have overlooked the perl solution. Thanks for pointing that out.

instead of n==0?X:Y, you can always do n?Y:X

Befunge '93 - 40 bytes
(20x2 program)
v<<<<<<<<<<<<<<<<<<<
>??????????????????@

This program relies on random numbers to give it delay. Since Befunge interpreters are quite slow, this program should fit the bill. And if it doesn't, we can always expand it horizontally.
Im not exactly sure how to go about calculating the expected running time of this program, but I know that each ? has a 50/50 chance of either starting over or changing its horizontal position by 1. There are 18 ?'s. I think it should be something along the lines of (18^2)!, which google calculator says is "Infinity"
EDIT: Whoops I did not notice the other Befunge answer, this is my first post here. Sorry.

Hey, don't worry about the other befubnge answer, or, or in general, using the same language as someone else. I mean, nobody is going to beat the mathlab one, so all other submissions are about fun. Mine was.

Python 3, 191 Bytes
from random import*
r=randint
f=lambda n:2if n<2else f(n-1)
x=9E999
s=x**x
for i in range(f(x)**f(s)):
 while exec(("r(0,f(x**i))+"*int(f(x)))+"r(0,f(x**i))")!=0:
  s=f(x**s)
  print(s)

First, f is a recursive factorial function and ultra slow.
Then, there is 9*10⁹⁹⁹ powed with itself, which generates an OverflowError, but this doesn't happen on this Unobtanium computer. The For-Loop iterates 9E999! ^ (9E999^9E999)! times and it only goes to the next iteration, if 9E999!+1 random ints between 0 and 9E99*^i! are all 0 and in every iteration of the while-loop s gets set to (9E999^s)!. Uh, I forgot that the printing of s takes muuuuccchhhh time...
I know it's not the shortest soloution, but I think it's really effective. Can someone help me calculating the running time?

Javascript, 120 bytes
a=[0];while(a.length<1e4)(function(){var b=0;while(b<a.length){a[b]=(a[b]+1)%9;if(a[b])return;b++}a.push(1)})();alert(a)

Can be done with minimal memory (probably less than half a megabyte) but takes (probably) about 108,750 years to halt.
Repeatedly increments a little-endian base-9 BigInteger until it reaches 9104-1.

Turing Machine But Way Worse, 167 bytes
0 0 1 1 2 0 0
1 0 1 0 4 0 0
0 1 1 1 2 0 0
1 1 1 1 5 0 0
0 2 1 0 3 0 0
1 2 0 1 1 0 0
0 3 1 1 4 0 0
1 3 0 0 2 0 0
0 4 1 0 0 0 0
1 4 0 1 3 0 0
0 5 1 0 6 0 1
1 5 1 1 2 0 0

Try it online!
Should run the 6-state 2-symbol Busy Beaver from the Wikipedia page.
As said in the Wikipedia page, it runs in \$7.412 \times 10^{36534}\$ steps. This is way more than the heat death, assuming it executes each command in more than or equal to a nanosecond.

8086 .COM, 10(11?) bytes
0100 31DB          XOR     BX,BX
0102 4B            DEC     BX
0103 FE0F          DEC     BYTE PTR [BX]
0105 74FB          JZ      0102
0107 E9F6FF        JMP     0100

Run for \$256^{65270}\$ steps (assuming all left space are zero) then change JMP 0100 into JMP 0000, aka. INT 20H. If the left space is possibly full of 01, then an extra 00 can be followed after JMP, having at least \$255 \times 256^{65269}\$ steps.

Runic Enchantments, ~1823 bytes
\DB͍R"000000000000000000000000000000000000001"$
.{ww;'''''''''''''''''''''''''''''''''''''''
.10{BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
a+'0000000000000000000000000000000000000000
kk0~111111111111111111111111111111111111111
$:{~+++++++++++++++++++++++++++++++++++++++
1'~}567890123456789012345678901234567890123
J://XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
.=? 000001111111112222222222333333333344444
/\/v\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Try it online!
Or rather, some arbitrarily large variation thereof. Taken from this answer where an explanation on how it works can be found. Additionally, running this "in perpetuity" would require a version of the interpreter which does not self-halt after 1,000,000 execution steps, but I will assume this as true as the unobtaining machine the code is running on as it only requires an adjustment to one line of code.
According to TIO this can print numbers out to 100 in about 0.141s (the flux here is almost irrelevant in terms of the final result: +/- ~10 bytes for being 10 times faster or slower for needing an extra digit of precision). So reaching 99999999999999999999999999999 should take about 4,471,080,669,710,806,697
(1018) years...and ten of its most significant decimals would still be 0, which bumps things to 1028 years. Depicted code only has 39 digits worth of precision in base-10 and we can go bigger.
Only one byte different takes it to an effective base 78 (with a maximum value around 6x1073). Tweaking the "0" down to the lowest allowable character ("#") brings that to base 92 (with a maximum value around 4x1076).
That brings us to needing a 515 digit base 92 number, which is also doable using the ´ command to need only n+1 cells to represent a base 10 number with n digits (for the purposes of write location offsets), e.g. this program changes the 4X3+ to 4´3, and as long as an empty row of cells is supplied between the column value (~1 byte per digit for all the spaces in order to allow for 3 digit numbers) and the 10B command any value can be expressed and needing approximately 5722 bytes.
However, we can still raise the integer base a bit more. ˿ is the last non-combining Unicode value accessible without performing any additional logic checks, allowing for a base 733 number which means that we only need 353 digits of precision, reducing the program size of about 3940 bytes.
But we can still go smaller still.
35-767 is not the largest unicode block usable without needing additional logic. If we instead use Unicode values 880 to 6831 (inclusive) we have an effective base of 5953, requiring only 268 digits of precision. Accounting for the two bytes needed to represent the initial characters, that gives a program size of approximately 3275 bytes.
Adding in the additional logic would allow for a maximum base of 64654, requiring only 211 digits of precision and costing only another 79 bytes or so based on this answer.
But we can still golf a few bytes. Remember the ´ command? We don't really need it. Now that we're down to only a 211 digit number, all the values needed (up to 216) can be represented with only 2-3 bytes (instead of 5): char values implicitly convert to integers when required in any command that expects integers and nearly all the chars needed (from 5 to 216) can be utilized in this manner.  Only 10, 60, 62, 94 and 118 are problematic. And all of them can still be expressed in 4 bytes or less:
10  -> a
60  -> 6X
62  -> 6X2+
94  -> 9x4+
118 -> bX8+

For 62, 94, and 118 it ends up being easier to just not use those columns. Increases program size by 8 bytes each (24 bytes) in order to not need the spaces to align the commands out to 118 (236 bytes).
Final score: 1823 bytes.
211 digit number      -  1 byte per digit of initial value
Programmatic overhead -  56 bytes (roughly, the left 4 columns and right 3 columns)
Digit processing      -  7 bytes * digits (1477 bytes)
Bad Character logic   -  ~79 bytes (some additional control flow is likely required)

(Intermediate values were approximated at 10 bytes (original program height) per digit of initial value +57 +unicode penalty where appropriate: eg. 1 byte per digit of initial value +1 or +2 for representation in programmatic overhead).
Final thoughts:
It may be possible to turn this answer into a self-repeating execution instead of a quine, but I have so far not had success getting it to Eval properly. I suspect that it attempts to Eval the string and the parser throws an error for some reason. If that were fixed, a shorter solution to the "take forever" problem would be possible: push the quine, duplicate, Eval, compare with original (lossless). If not the same: loop, else terminate. The number of Eval attempts (i.e. the original period count) is already near the number of years required by this challenge, so increasing the number of loops by a factor of ~32 billion (iteration -> years) seems relatively doable in less than 1300 bytes. Increasing the program length from 387 "digits" to 485 "digits" looks like it would be enough.

Pyt, 4 bytes
9ṖṖṖ

Try it online!
Inspired by xnor's Python answer, this calculates:
x=9^9
y=x^x
z=y^y
and then returns z. according to WolframAlpha, this is around 10^(10^9.52208) bits, which is more bits than his program has, and therefore will require more time.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Lockers vs. Crackers: The Five-Element Sequence
The Challenge
A simple "spy versus spy" challenge.
Write a program with the following specifications:

The program may be written in any language but must not exceed 512 characters (as represented in a code block on this site).
The program must accept 5 signed 32-bit integers as inputs. It can take the form of a function that accepts 5 arguments, a function that accepts a single 5-element array, or a complete program that reads 5 integers from any standard input.
The program must output one signed 32-bit integer.
The program must return 1 if and only if the five inputs, interpreted as a sequence, match a specific arithmetic sequence of the programmer's choosing, called the "key". The function must return 0 for all other inputs.

An arithmetic sequence has the property that each successive element of the sequence is equal to its predecessor plus some fixed constant a.
For example, 25 30 35 40 45 is an arithmetic sequence since each element of the sequence is equal to its predecessor plus 5.
Likewise, 17 10 3 -4 -11 is an arithmetic sequence since each element is equal to its precessor plus -7.
The sequences 1 2 4 8 16 and 3 9 15 6 12 are not arithmetic sequences.
A key may be any arithmetic sequence of your choosing, with the sole restriction that sequences involving integer overflow are not permitted. That is, the sequence must be strictly increasing, strictly decreasing, or have all elements equal.
As an example, suppose you choose the key 98021 93880 89739 85598 81457. Your program must return 1 if the inputs (in sequence) match these five numbers, and 0 otherwise.
Please note that the means of protecting the key should be of your own novel design. Also, probabilistic solutions that may return false positives with any nonzero probability are not permitted. In particular, please do not use any standard cryptographic hashes, including library functions for standard cryptographic hashes.
The Scoring
The shortest non-cracked submission(s) per character count will be declared the winner(s).
If there's any confusion, please feel free to ask or comment.
The Counter-Challenge
All readers, including those who have submitted their own programs, are encouraged to "crack" submissions. A submission is cracked when its key is posted in the associated comments section. If a submission persists for 72 hours without being modified or cracked, it is considered "safe" and any subsequent success in cracking it will be ignored for sake of the contest.
See "Disclaimer" below for details on the updated cracking score policy.
Cracked submissions are eliminated from contention (provided they are not "safe"). They should not be edited. If a reader wishes to submit a new program, (s)he should do so in a separate answer.
The cracker(s) with the highest score(s) will be declared the winners along with the developers of the winning programs.
Please do not crack your own submission.
Best of luck. :)
Leaderboard
Penultimate standings (pending safety of Dennis' CJam 49 submission).
Secure Lockers

CJam 49, Dennis
CJam 62, Dennis safe
CJam 91, Dennis safe
Python 156, Maarten Baert safe
Perl 256, chilemagic safe
Java 468, Geobits safe

Unstoppable Crackers

Peter Taylor [Ruby 130, Java 342, Mathematica 146*, Mathematica 72*, CJam 37]
Dennis [Pyth 13, Python 86*, Lua 105*, GolfScript 116, C 239*]
Martin Büttner [Javascript 125, Python 128*, Ruby 175*, Ruby 249*]
Tyilo [C 459, Javascript 958*]
freddieknets [Mathematica 67*]
Ilmari Karonen [Python27 182*]
nitrous [C 212*]

*non-compliant submission
Disclaimer (Updated 11:15 PM EST, Aug 26)
With the scoring problems finally reaching critical mass (given two thirds of the cracked submissions are thus far non-compliant), I've ranked the top crackers in terms of number of submissions cracked (primary) and total number of characters in compliant cracked submissions (secondary).
As before, the exact submissions cracked, the length of the submissions, and their compliant/non-compliant status are all marked so that readers may infer their own rankings if they believe the new official rankings are unfair.
My apologies for amending the rules this late in the game.

How are you going to verify that programs meet point 4? Do you expect people to edit their safe answers to add a proof? Are probabilistic submissions permitted on the basis of assuming that hash functions are ideal and the chance of a collision with another element of the 48-bit (according to your estimate above) space is negligible?

If a language does not have fine-grained control over its return value, if it OK, to exit with an error if the key is given, and not otherwise?

Is Mathematica permitted? not everyone will be able to test it so it will have a big advantage over other languages.

I really think built-in cryptographic functions should be ruled out, as the only feasible solution is bruteforce, which is practically impossible. You will end up with several solutions in the form return (hash(inputs) == myHashedKey), which are all 'unbreakable' as far as the scope of this competition runs.

@isaacg: I'm going to have to say "no" to allowing errors as output. The program/function should always terminate normally. However if a particular language doesn't have the ability to output integer 1 and 0 specifically, the program may output any two distinct values so long as they're documented along with the submission.

@stokastic: You're right. Ryan thought of the idea first, hence his entry can stay. I'll add the "no standard crypto hashes" rule to the OP.

@coto I don't mind my entry being disallowed. It will make the challenge more interesting i.e. i'm voluntarily withdrawing my submission.

@PeterTaylor: A proof would be nice, but we'll take it on good faith that each submission identifies one and only one input sequence. Probabilistic solutions that may return false positives with any nonzero probability are not permitted.

"Probabilistic solutions that may return false positives with any nonzero probability are not permitted" makes the problem a lot more interesting, since it effectively rules out both cryptographic hashes and the cheat I was going to do, srand(input).

If you don't accept probabilistic methods, you don't have to rule out hashes.

Are we allowed to use built-in random, provided the seed is available to the cracker?

@stokastic: I would very much like to say "yes", but it opens up too many possibilities for abuse. For example, using the PRNG in $30K-a-license Exclusive Software X to hide constants where no one will ever find them. Hence the answer is "No". Using a PRNG to hide constants a clever idea, though, and you officially get credit for it.

The scoring system seems to encourage crackers to ignore the shortest locks because they score better by cracking two long locks than two small ones.

@PeterTaylor: It was my thinking that (generally speaking) the longer a lock is, the more intractable the the problem of cracking it. I wanted the scoring system to reflect this in some way. I realize there are exceptions to the rule, and that there are other drawbacks. At this point it would be improper to amend the scoring rules.

@COTO I think the problem is that you can only get 2 cracking scores, and only the shortest. So why not wait and hope and longer one shows up? For example, Martin now has no incentive to crack my (longer) lock, since he's already cracked two shorter ones. Anyone who cracks mine will now beat him without even having to do a second one.

When should we post the answer if no-one has cracked it? After 72 hours after submission? Another deadline?

@Geobits: Actually, one of the reasons I put the rule in was to discourage a single reader from cracking all the entries, which I figured would discourage anyone else from attempting. When I post the day 1 leaderboard later this evening, Martin will get a special mention regardless of where he ranks according to official score. He's really going to town on people's entries.

@Tyilo: If you're still around after 72 hours, absolutely. The crackers will want to know how you stumped them.

I think a better scoring system might be sum of total times between question and crack. That way, cracking a bunch of easy ones can be beaten, and the real reward comes from cracking the really hard ones.

Neither the 128 byte nor the 175 byte submission I cracked were valid, so you shouldn't include them in the score, I think.

I'm new to golfing, so maybe it's a stupid question, sorry for that. Why is the code length measured in characters and not in bytes? The latter is literally the memory space that a program occupies, so for me it seems more logical. Eg. the CJam answer is the shortest in characters, but when looking at its size (326 because of unicode) it isn't even in the top 5. So I wonder, is it common convention in golfing to count chars instead of bytes?

@freddieknets: Honestly I don't know what the usual convention for bytes v. chars is. I'll stick with chars in this challenge, but if the convention is to count bytes, I'll use that in future.

@MartinBüttner: Will do. I'll update the leaderboard now.

@freddieknets, the default is bytes, as specified in the code-golf tag wiki, but some people prefer to count in characters.

I think this contest would have been better without requiring a unique key. It's impossible to verify, probabilistic arguments require a long "hash" which takes up most of the characters, and additional keys only favor the cracker.

my version 1 is not valid as I know at least to keys for it, so @freddieknets should have a *. I can't disclose the key right now as it's the solution to my v2 script.

@xnor: Probabilistic arguments are forbidden. That's what makes the challenge interesting (for me), as you cannot use a hash at all.

@Dennis Thanks, I hadn't seen that ruling; that sadly disqualifies my solution. A bunch of answers fail uniqueness then, including some on the leaderboard.

@xnor: Yeah, that rule was a little buried. I've edited the question to make it more prominent.

@COTO I feel like discrete logarithm and the RSA problem, which a lot of the answers use, should be disallowed for being "standard cryptographic hashes".

@xnor: RSA is asymmetric encryption, not hashing. As shown here, it can be used for message authentication codes, but it makes a terrible hash; anyone knowing the factorization of the modulus can easily reverse it.

@COTO Then please change the wording "Please note that the means of protecting the key should be of your own novel design." Unless some of our golfers would like to reveal to be Professor Rivest, Professor Shamir, or Professor Adleman.

@Dennis That may be true for RSA, but discrete log is not known to have a trapdoor. What is then the distinction between one-way functions and hashes?

@xnor: There are different definitions of hash function. In crytography, one usually requires that you can't compute H(M*X) gives H(M) and X. With the discrete logarithm approach, that's perfectly possible, since G**(M+X)=G**M * G**X and G**(M*X)=(G**M)**X.

@xnor: Truth be known, I added the "no cryptographic hashes" rule believing that RSA was an example of a cryptographic hash ("cryptographic hash" being a catch-all for "algorithm for generating a digital signature" in my ignorance). The goal was to rule out submissions relying on long-established algorithms that are (barring some world-changing advance in number theory) guaranteed to be unbreakable by anything other than brute force. The intent was to promote novelty. I unfortunately don't have the background to determine whether any given algorithm is a significant departure...

from an existing bulwark in the field of encryption, and thus "novel".

CJam, 62 characters
"ḡꬼ쏉壥떨ሤ뭦㪐ꍡ㡩折量ⶌ팭뭲䯬ꀫ郯⛅彨ꄇ벍起ឣ莨ຉᆞ涁呢鲒찜⋙韪鰴ꟓ䘦쥆疭ⶊ凃揭"2G#b129b:c~

Stack Exchange is prone to mauling unprintable characters, but copying the code from this paste and pasting it in the CJam interpreter works fine for me.
How it works
After replacing the Unicode string with an ASCII string, the following code gets executed:
" Push 85, read the integers from STDIN and collect everything in an array.               ";

85l~]

" Convert the array of base 4**17 digits into and array of base 2 digits.                 ";

4H#b2b

" Split into chunks of length 93 and 84.                                                  ";

93/~

" Do the following 611 times:

    * Rotate array A (93 elements) and B one element to the left.
    * B[83] ^= B[14]
    * T = B[83]
    * B[83] ^= B[0] & B[1] ^ A[23]
    * A[92] ^= A[26]
    * Rotate T ^ A[92] below the arrays.
    * A[92] ^= A[0] & A[1] ^ B[5].                                                        ";

{(X$E=^:T1$2<:&^2$24=^+\(1$26=^_T^@@1$2<:&^3$5=^+@}611*

" Discard the arrays and collects the last 177 generated bits into an array.              ";

;;]434>

" Convert the into an integer and check if the result is 922 ... 593.                     ";

2b9229084211442676863661078230267436345695618217593=

This approach uses Bivium-B (see Algebraic analysis of Trivium-like ciphers), a weakened version of the stream cipher Trivium.
The program uses the sequence of integers as initial state, updates the state 434 times (354 rounds achieve full diffusion) and generates 177 bit of output, which it compares to those of the correct sequence.
Since the state's size is precisely 177 bits, this should suffice to uniquely identify the initial state.
Example run
$ echo $LANG
en_US.UTF-8
$ base64 -d > block.cjam <<< IgThuKHqrLzsj4nlo6XrlqjhiKTrrabjqpDqjaHjoanmipjvpb7itozuoIDtjK3rrbLul7bkr6zqgKvvjafpg6/im4XlvajqhIfrso3uprrotbfvmL/hnqPojqjguonhhp7mtoHujLPuipzlkaLpspLssJzii5npn6rpsLTqn5PkmKbspYbnlq3itorlh4Pmj60iMkcjYjEyOWI6Y34=
$ wc -m block.cjam
62 block.cjam
$ cjam block.cjam < block.secret; echo
1
$ cjam block.cjam <<< "1 2 3 4 5"; echo
0

CJam, 91 characters
q~]KK#bD#"᫖࿼듋ޔ唱୦廽⻎킋뎢凌Ḏ끮冕옷뿹毳슟夫΢眘藸躦䪕齃噳卤"65533:Bb%"萗縤ᤞ雑燠Ꮖ㈢ꭙ㈶タ敫䙿娲훔쓭벓脿翠❶셭剮쬭玓ୂ쁬䈆﹌⫌稟"Bb=

Stack Exchange is prone to mauling unprintable characters, but copying the code from this paste and pasting it in the CJam interpreter works fine for me.
How it works
After replacing the Unicode string with integers (by considering the characters digits of base 65533 numbers), the following code gets executed:
" Read the integers from STDIN and collect them in an array.                               ";

q~]

" Convert it into an integer by considering its elements digits of a base 20**20 number.   ";

KK#b

" Elevate it to the 13th power modulus 252 ... 701.                                        ";

D#
25211471039348320335042771975511542429923787152099395215402073753353303876955720415705947365696970054141596580623913538507854517012317194585728620266050701%

" Check if the result is 202 ... 866.                                                      ";

20296578126505831855363602947513398780162083699878357763732452715119575942704948999334568239084302792717120612636331880722869443591786121631020625810496866=

Since 13 is coprime to the totient of the modulus (the totient is secret, so you'll just have to trust me), different bases will generate different results, i.e., the solution is unique.
Unless someone can exploit the small exponent (13), the most efficient way of breaking this lock is to factorize the modulus (see RSA problem). I chose a 512-bit integer for the modulus, which should withstand 72 hours of factorization attempts.
Example run
$ echo $LANG
en_US.UTF-8
$ base64 -d > lock.cjam <<< cX5dS0sjYkQjIgHuiJHhq5bgv7zrk4velOWUse6zjuCtpuW7veK7ju2Ci+uOouWHjOG4ju+Rh+uBruWGleyYt+u/ueavs+6boOyKn+Wkq86i55yY6Je46Lqm5KqV6b2D5Zmz75Wp5Y2kIjY1NTMzOkJiJSIB6JCX57ik4aSe74aS6ZuR54eg4Y+G44ii6q2Z44i244K/5pWr5Jm/5aiy7ZuU7JOt67KT7rO26IS/57+g4p2275+K7IWt5Ymu7Kyt546T4K2C7IGs5IiG77mM4quM56ifIkJiPQ==
$ wc -m lock.cjam
91 lock.cjam
$ cjam lock.cjam < lock.secret; echo
1
$ cjam lock.cjam <<< "1 2 3 4 5"; echo
0

I have posted a new version since I forgot to remove an unnecessary character from the first one. The secret sequence is still the same, so you can try to crack either one.

FYI, I'm aborting my factoring attempt. msieve set itself a time limit of 276 hours, but that was just for building the factor base. In that time it found 1740001 rational and 1739328 algebraic entries; it's since had almost 100 hours to process them, and reports sieving in progress b = 46583, 0 complete / 0 batched relations (need 44970493).

@PeterTaylor: Looks like 512 bits were overkill. Were you trying to factor the integer in my other answer or in this one?

Oh, oops. Yes, other one.

Python - 128
Let's try this one:
i=input()
k=1050809377681880902769L
print'01'[all((i>1,i[0]<i[4],k%i[0]<1,k%i[4]<1,i[4]-i[3]==i[3]-i[2]==i[2]-i[1]==i[1]-i[0]))]

(Expects the user to input 5 comma-separated numbers, e.g. 1,2,3,4,5.)

32416190039,32416190047,32416190055,32416190063,32416190071

Wow, that was fast! You're right! And I'm out.

Btw, this isn't actually valid, because your five integers don't fit in a 32-bit integer.

Java : 468
Input is given as k(int[5]). Bails early if not evenly spaced. Otherwise, it takes a bit figuring out if all ten hashes are correct. For large numbers, "a bit" can mean ten seconds or more, so it might dissuade crackers.
//golfed
int k(int[]q){int b=q[1]-q[0],i,x,y,j,h[]=new int[]{280256579,123883276,1771253254,1977914749,449635393,998860524,888446062,1833324980,1391496617,2075731831};for(i=0;i<4;)if(q[i+1]-q[i++]!=b||b<1)return 0;for(i=1;i<6;b=m(b,b/(i++*100),(1<<31)-1));for(i=0;i<5;i++){for(j=1,x=b,y=b/2;j<6;x=m(x,q[i]%100000000,(1<<31)-1),y=m(y,q[i]/(j++*1000),(1<<31)-1));if(x!=h[i*2]||y!=h[i*2+1])return 0;}return 1;}int m(int a,int b,int c){long d=1;for(;b-->0;d=(d*a)%c);return (int)d;}

// line breaks
int k(int[]q){
    int b=q[1]-q[0],i,x,y,j,
    h[]=new int[]{280256579,123883276,1771253254,1977914749,449635393,
                  998860524,888446062,1833324980,1391496617,2075731831};
    for(i=0;i<4;)
        if(q[i+1]-q[i++]!=b||b<1)
            return 0;
    for(i=1;i<6;b=m(b,b/(i++*100),(1<<31)-1));
    for(i=0;i<5;i++){
        for(j=1,x=b,y=b/2;j<6;x=m(x,q[i]%100000000,(1<<31)-1),y=m(y,q[i]/(j++*1000),(1<<31)-1));
        if(x!=h[i*2]||y!=h[i*2+1])
            return 0;
    }
    return 1;
}
int m(int a,int b,int c){
    long d=1;for(;b-->0;d=(d*a)%c);
    return (int)d;
}

Your code hangs if input arithmetic sequence is descending.  Or at least, takes a really long time.  Which makes me think the secret code is ascending...

@KeithRandall Oops. Let's add four bytes to make descending sequences take an unusually short amount of time, further reinforcing your belief.

Python, 147
Edit: shorter version based on Dennis' comment. I updated the sequence too to avoid leaking any information.
def a(b):
    c=1
    for d in b:
        c=(c<<32)+d
    return pow(7,c,0xf494eca63dcab7b47ac21158799ffcabca8f2c6b3)==0xa3742a4abcb812e0c3664551dd3d6d2207aecb9be

Based on the discrete logarithm problem which is believed to be uncrackable, however the prime I'm using is probably too small to be secure (and it may have other issues, I don't know). And you can brute-force it of course, since the only unknowns are two 32-bit integers.

Discrete logarithms are a lot harder that I thought. My cracker has been at this for 26 hours. I give up.

You could solve the sign problem by initializing c=1, computing c=(c<<32)+d and changing the constant accordingly.

assert a([-1154709934+316804249*k for k in range(5)]) works for me :)

Java : 342
int l(int[]a){String s=""+(a[1]-a[0]);for(int b:a)s+=b;char[]c=new char[11];for(char x:s.toCharArray())c[x<48?10:x-48]++;for(int i=0;i<11;c[i]+=48,c[i]=c[i]>57?57:c[i],i++,s="");for(int b:a)s+=new Long(new String(c))/(double)b;return s.equals("-3083.7767567702776-8563.34366442527211022.4345579010483353.1736981951231977.3560837512646")?1:0;}

Here's a string-based locker that depends on both the input character count and the specific input. The sequence might be based on obscure pop culture references. Have fun!
A bit ungolfed:
int lock(int[]a){
    String s=""+(a[1]-a[0]);
    for(int b:a)
        s+=b;
    char[]c=new char[11];
    for(char x:s.toCharArray())
        c[x<48?10:x-48]++;
    for(int i=0;i<11;c[i]+=48,
                     c[i]=c[i]>57?57:c[i],
                     i++,
                     s="");
    for(int b:a)
        s+=new Long(new String(c))/(double)b;
    return s.equals("-3083.7767567702776-8563.34366442527211022.4345579010483353.1736981951231977.3560837512646")?1:0;
}

8675309? 90210?

@Malachi Two outstanding references, no doubt, but I can neither confirm nor deny their applicability to this exercise.

lol, I haven't completely figured out how this challenge works completely yet,  I may give it a shot later when I am at home.

Initial term is -8675309, delta is 5551212.

@PeterTaylor Nicely done :)

Javascript 125
This one should be cracked pretty quickly. I'll follow up with something stronger.
function unlock(a, b, c, d, e)
{
    return (e << a == 15652) && (c >> a == 7826) && (e - b == d) && (d - c - a == b) ? 1 : 0;
}

0, 3913, 7826, 11739, 15652

yep you got it :)

Ruby, 175
a=gets.scan(/\d+/).map(&:to_i)
a.each_cons(2).map{|x,y|x-y}.uniq[1]&&p(0)&&exit
p a[2]*(a[1]^a[2]+3)**7==0x213a81f4518a907c85e9f1b39258723bc70f07388eec6f3274293fa03e4091e1?1:0

Unlike using a cryptographic hash or srand, this is provably unique (which is a slight clue). Takes five numbers via STDIN, delimited by any non-digit, non-newline character or characters. Outputs to STDOUT.

Yep, forgot they were signed.

622238809,1397646693,2173054577,2948462461,3723870345 (my previous guess had a mistake, but this one is tested). I don't think this is valid though, because the last number doesn't fit in a signed 32-bit integer.

Mathematica 80 67
f=Boole[(p=NextPrime/@#)-#=={18,31,6,9,2}&&BitXor@@#~Join~p==1000]&

Running:
f[{1,2,3,4,5}] (* => 0 *)

Probably pretty easy to crack, might also have multiple solutions.
Update: Improved golfing by doing what Martin Büttner suggested. Functionality of the function and the key hasn't changed.

@MartinBüttner Improving answers to get higher score when you crack them. Smart ;P

Huh, turns out I skipped the paragraph about scoring for the counter challenge. I thought that was just for the fun of it without any score at all. Although I don't think it would make sense for me shorten solutions I want to crack because that would reduce my score.

{58871,5592,-47687,-100966,-154245}

@freddieknets Not the solution I used when creating it. Didn't know that NextPrime could return negative values. How did you find it?

Then your key is not unique :p. I just ran a few tests - there really aren't that many numbers where NextPrime[#]-# evaluates to 31, so that's an easy way to crack it.

And using the fact that the BitXor should equal 1000, you know # has to have an odd amount of odd numbers. On top of that, the function NextPrime[#]-#==n seems only to return numbers of reversed 'evenness', ie, if n=18, only odd numbers. So the list should be {odd, even, odd, even, odd}. Thus the increment should be odd. Also by the fact that the BitXor==1000, one knows that either the numbers are not that big (order of a few ten/hunderd thousands), or the increment is not that big. All this together helps to make educated guesses and less computation.

This is the code:
start = Table[If[NextPrime[x] - x == 31, Print[x]; x,Unevaluated@Sequence[]], {x, 0, 10000}];
start2 = Table[If[NextPrime[# - a] - # + a == 18 && NextPrime[# + a] - # - a == 6 && NextPrime[# + 2 a] - # - 2 a == 9 && NextPrime[# + 3 a] - # - 3 a == 2, Table[# + (i - 1) a, {i, 0, 4}], Unevaluated@Sequence[]], {a, -99999, 99999, 2}] & /@ start;
test = Flatten[(If[BitXor @@ #~Join~(NextPrime /@ #) == 1000, #,Unevaluated@Sequence[]] & /@ #) & /@ start2]

@freddieknets You have definitely won this. Could you still solve it if NextPrime was replaced by Abs@NextPrime?

To force me finding the key you created it with? Probably yes, although it will take more calculation time (the range needs to be widened).

@freddieknets I don't think you can find my original key (at least not with your current method), but I'm just curious if you could find another.

@MartinBüttner moved

GolfScript (116 chars)
Takes input as space-separated integers.
~]{2.5??:^(&}%^base 2733?5121107535380437850547394675965451197140470531483%5207278525522834743713290685466222557399=

-51469355 -37912886 -24356417 -10799948 2756521

Nice work. Did you exploit the small exponent?

No, I factorized the modulus. Took only 13 seconds using primo's Multiple Polynomial Quadratic Sieve and PyPy.

In that case I might as well abandon my current golfing it down by using a compactly expressed modulus. If the result has to be something like 1024 bits to be safe from factoring then even using a base-256 representation it's going to be too long.

I hope not. My answer uses the same idea as yours, but with a 512 bit modulus and an even smaller exponent (13). Given the 72 hour time limit, that might be enough...

C 459 bytes
SOLVED BY Tyilo -- READ EDIT BELOW
int c (int* a){
int d[4] = {a[1] - a[0], a[2] - a[1], a[3] - a[2], a[4] - a[3]};
if (d[0] != d[1] || d[0] != d[2] || d[0] != d[3]) return 0;
int b[5] = {a[0], a[1], a[2], a[3], a[4]};
int i, j, k;
for (i = 0; i < 5; i++) {
for (j = 0, k = 2 * i; j < 5; j++, k++) {
k %= i + 1;
b[j] += a[k];
}
}
if (b[0] == 0xC0942 - b[1] &&
b[1] == 0x9785A - b[2] &&
b[2] == 0x6E772 - b[3] &&
b[3] == 0xC0942 - b[4] &&
b[4] == 0xB6508 - b[0]) return 1;
else return 0;
}

We need someone to write a C solution, don't we? I'm not impressing anybody with length, I'm no golfer. I hope it's an interesting challenge, though!
I don't think there's an obvious way to crack this one, and I eagerly await all attempts! I know this solution to be unique. Very minimal obfuscation, mostly to meet length requirements. This can be tested simply:
int main(){
    a[5] = {0, 0, 0, 0, 0} /* your guess */
    printf("%d\n", c(a));
    return 0;
}

P.S. There's a significance to a[0] as a number in its own right, and I'd like to see somebody point it out in the comments!
EDIT:
Solution: 6174, 48216, 90258, 132300, 174342
A note about cracking:
While this is not the method used (see the comments), I did happen to crack my own cipher with a very easy bruteforce. I understand now it is vitally important to make the numbers large. The following code can crack any cipher where upper_bound is a known upper bound for a[0] + a[1] + a[2] + a[3] + a[4]. The upper bound in the above cipher is 457464, which can be derived from the system of equations of b[] and some working-through of the algorithm. It can be shown that b[4] = a[0] + a[1] + a[2] + a[3] + a[4].
int a[5];
for (a[0] = 0; a[0] <= upper_bound / 5; a[0]++) {
    for (a[1] = a[0] + 1; 10 * (a[1] - a[0]) + a[0] <= upper_bound; a[1]++) {
        a[2] = a[1] + (a[1] - a[0]);
        a[3] = a[2] + (a[1] - a[0]);
        a[4] = a[3] + (a[1] - a[0]);
        if (c(a)) {
            printf("PASSED FOR {%d, %d, %d, %d, %d}\n", a[0], a[1], a[2], a[3], a[4]);
        }
    }
    printf("a[0] = %d Checked\n", a[0]);
}

With a[0] = 6174, this loop broke my work in a little under a minute.

Solution: 6174, 48216, 90258, 132300, 174342.

Wow that was fast. Nice one. Bruteforced, or did you find something clever I missed?

I used Mathematica's symbolic evaluation like so: https://ghostbin.com/paste/jkjpf screenshot: http://i.imgur.com/2JRo7LE.png

Re the edit: I did basically the same thing, but fudged the upper at 500k. Got the answer and saw that Tyilo had already posted it :(

@Geobits That's a surprisingly accurate guess. Should've put some more 0's on the ends of those numbers.

@BrainSteel I was going to go much lower, but gave it some leeway since I didn't work it all the way through. 0xC0942 is pretty low on the whole, so I figured that if you were playing with positive numbers, a[0] had to be much lower to accommodate all those additions.

Python27, 283 182
Alright, I am very confident in my locker, however it is quite long as I've added 'difficult to reverse' calculations to the input, to make it well - difficult to reverse.
import sys
p=1
for m in map(int,sys.argv[1:6]):m*=3**len(str(m));p*=m<<sum([int(str(m).zfill(9)[-i])for i in[1,3,5,7]])
print'01'[p==0x4cc695e00484947a2cb7133049bfb18c21*3**45<<101]

edit: Thanks to colevk for the further golfing. I realized during editing that there was a bug as well as a flaw in my algorithm, maybe I'll have better luck next time.

This is invariant under reordering of the arguments, so it's not a valid locker.

Besides, I suspect the code as posted is buggy: the key 121174841 121174871 121174901 121174931 121174961 works, but only if the list [1,3,5,7] on line 7 is replaced with [1,3,5,7,11].

Darn, yes I was just fixing my typo, during which I made a crucial mistake in my algorithm, leaving it very easy to crack :|

Actually, finding and fixing the bug was the difficult part; given your algorithm, factoring the constant was kind of an obvious thing to try.

Mathematica 142 146
EDIT: key wasn't unique, added 4 chars, now it is.
n=NextPrime;
f=Boole[
    FromDigits /@ (
        PartitionsQ[n@(237/Plus@##) {1, ##} + 1] & @@@
            IntegerDigits@n@{Plus@##-37*Log[#3],(#1-#5)#4}
    ) == {1913001154,729783244}
]&

(Spaces and newlines added for readability, not counted & not needed).
Usage:
f[1,2,3,4,5]   (* => 0 *)

Initial term 256208, delta -5.

Dang, then still it isn't unique, as this isn't my original key. Did you bruteforce?

Test it, I might have made a mistake because I don't have access to Mathematica to test. Each stage is using brute force, but it's not much computer time. The approach is to work backwards to the output of IntegerDigits and then factor to get candidates for the initial term and delta.

But there's no way this approach could be unique anyway. The second of the five inputs is only used in a sum which is passed to NextPrime; if we vary it by plus or minus one, at least one of those will give the same next prime.

yes but for a arithmetic sequence -as is the required input- it was supposed to be unique.

The unique key is what's required to be an arithmetic sequence, not the input. That can be any sequence of five 32-bit signed ints.

I found out why your key worked as well; the list I feed to FromDigits consists of numbers bigger than 9, making the inverse step impossible to do (ie, FromDigits[{1,22,13}] gives 333, inverting this by using IntegerDigits gives {3,3,3}. There is no way to retrieve the original list. But working backwards from 1913001154 and 729783244 gives possible results to PartitionsQas well.. I should have included a 6 in the key.

Ah ok, my bad, you are right about the input.

CJam, 49 characters
"腕옡裃䃬꯳널֚樂律ࡆᓅ㥄뇮┎䔤嬣ꑙ䘿휺ᥰ籃僾쎧諯떆Ἣ餾腎틯"2G#b[1q~]8H#b%!

Try it online.
How it works
" Push a string representing a base 65536 number and convert it to an integer.            ";

"腕옡裃䃬꯳널֚樂律ࡆᓅ㥄뇮┎䔤嬣ꑙ䘿휺ᥰ籃僾쎧諯떆Ἣ餾腎틯"2G#b

" Prepend 1 to the integers read from STDIN and collect them into an array.               ";

[1q~]

" Convert that array into an integer by considering it a base 2**51 number.               ";

8H#b

" Push the logical NOT of the modulus of both computed integers.                          ";

%!

The result will be 1 if and only if the second integer is a factor of the first, which is a product of two primes: the one corresponding to the secret sequence and another that doesn't correspond to any valid sequence. Therefore, the solution is unique.
Factorizing a 512 bit integer isn't that difficult, but I hope nobody will be able to in 72 hours. My previous version using a 320 bit integer has been broken.
Example run
$ echo $LANG
en_US.UTF-8
$ base64 -d > flock512.cjam <<< IuiFleyYoeijg+SDrOqvs+uEkNaa76a/5b6L4KGG4ZOF76Gi46WE64eu4pSO5JSk5ayj6pGZ5Ji/7Zy64aWw57GD5YO+7I6n6Kuv65aG7qK04byr6aS+6IWO7rSn7YuvIjJHI2JbMXF+XThII2IlIQ==
$ wc -m flock512.cjam
49 flock512.cjam
$ cjam flock512.cjam < flock512.secret; echo
1
$ cjam flock512.cjam <<< "1 2 3 4 5"; echo
0

I've had msieve running on it for over 24 hours, but since its self-imposed time limit is 276.51 CPU-hours and I've only given it one CPU I'm not optimistic.

-2005516409 -1431071926 -856627443 -282182960 292261523. Cracked with a Coppersmith attack that takes less than a CPU-second.

@qbt937 Not me coming up with this idea and then seeing this comment...nice work!

Cracked by @Dennis in 2 hours

Just a simple one to get things started - I fully expect this to be quickly cracked.
Pyth, 13
h_^ZqU5m-CGdQ

Takes comma separated input on STDIN.
Run it like this (-c means take program as command line argument):
$ echo '1,2,3,4,5' | python3 pyth.py -c h_^ZqU5m-CGdQ
0

Fixed the program - I had not understood the spec.
This language might be too esoteric for this competition - If OP thinks so, I will remove it.

Have you just given away that 1,2,3,4,5 is the key?

Every input I tried returned 1, did you switch 1 and 0 as output?

Sorry, I didn't understand the Output vs. Return distinction - the program should work now. Same underlying algorithm.

97,96,95,94,93 (I just killed my cracking score.)

@Dennis Well done. The cracking score system needs to be changed - it's creating some really weird incentives.

Lua 105
I suspect it won't be long before it's cracked, but here we go:
function f(a,b,c,d,e)
   t1=a%b-(e-2*(d-b))
   t2=(a+b+c+d+e)%e
   t3=(d+e)/2
   print(t1==0 and t2==t3 and"1"or"0")
end

(spaces added for clarity, but are not part of count)

3, 7, 11, 15, 19 or 6, 14, 22, 30, 38

@Dennis: sadly it is neither of those. I'll have to work on it a bit later to ensure the non-uniqueness.

t1==0 whenver S is increasing. Also, both conditions are homogeneous; if S is a solution, so is kS.

Perl - 256
sub t{($z,$j,$x,$g,$h)=@_;$t="3"x$z;@n=(7,0,split(//,$g),split(//,$h),4);@r=((2)x6,1,1,(2)x9,4,2,2,2);$u=($j+1)/2;for$n(0..$#r+1){eval{substr($t,$j,1)=$n[$n]};if($@){print 0; return}$j+=$r[$n]*$u}for(1..$x){$t=pack'H*',$t;}eval$t;if($@||$t!~/\D/){print 0}}

I had to put in a lot of error handling logic and this can definitely be golfed down a lot more. It will print a 1 when you get the right five numbers. It will hopefully print a 0 for everything else (might be errors or nothing, I don't know). If anyone wants to help improve the code or golf it more, feel free to help out!

Call with:
t(1,2,3,4,5);

Ruby - 130
Based on Linear Feedback Shift Register. Inputs by command line arguments.
Should be unique based on the nature of LFSRs. Clue: ascending and all positive.
Will give more clues if no one solves it soon.
x=($*.map{|i|i.to_i+2**35}*'').to_i
(9**8).times{x=((x/4&1^x&1)<<182)+x/2}
p x.to_s(36)=="qnsjzo1qn9o83oaw0a4av9xgnutn28x17dx"?1:0

Initial value 781783, increment 17982811

@PeterTaylor Argh... =)

Ruby, 249
a=gets.scan(/\d+/).map(&:to_i)
a.each_cons(2).map{|x,y|x-y}.uniq[1]&&p(0)&&exit
r=(a[0]*a[1]).to_s(5).tr'234','(+)'
v=a[0]<a[1]&&!r[20]&&(0..3).select{|i|/^#{r}$/=~'%b'%[0xaa74f54ea7aa753a9d534ea7,'101'*32,'010'*32,'100'*32][i]}==[0]?1:0rescue 0
p v

Should be fun. Who needs math?

309, 77347, 154385, 231423, 308461 but I don't think it's unique.

Yeah, it's not. For the same regex (i.e. product of the first two numbers), I also find 103, 232041, 463979, 695917, 927855 and 3, 7966741, 15933479, 23900217, 31866955. And I'm pretty sure there are other valid regexes by using additional +s.

Sorry, I guess I messed up the test string. There was supposed to be only one regexp with a unique factorization.

If you want to try to fix it, make sure to take possessive quantifiers into account. I can also create a larger, equivalent regex by inserting () or similar.

C 93 bytes
A simple hash. To follow the rule of unique solution, I bruteforced all the candidates, which took quite some core-hours. Of course the solution can be found in the same way.
The function f accepts a pointer to the 5 input integers and outputs 1 for the unique solution, 0 otherwise.
i=1e5;f(int*x){for(;--i;)x[i&3]+=(x[4]^=x[i&3])*9>>3;return!memcmp(x,"U|]v-W^Scv1(-8V8",16);}

For more adventurous hackers, here's a variant with 64-bit security* (89 bytes), which I could not verify to have a unique solution due to too big search space (but the chance of it happening is less than 1 in a billion).
i=1e5;f(int*x){for(;--i;)x[i&3]+=(x[4]^=x[i&3])*9>>3;return!memcmp(x,"'=P(=31qlite",12);}

* 64-bit security meaning 2^64 function calls. The number of required bit operations is quite bigger.

Javascript 958
Converts the inputs to a number of data types and performs some manipulations relevant to each data type along the way. Should be fairly easily reversed for anyone that takes the time.
function encrypt(num)
{
    var dateval = new Date(num ^ (1024-1) << 10);

    dateval.setDate(dateval.getDate() + 365);

    var dateString = (dateval.toUTCString() + dateval.getUTCMilliseconds()).split('').reverse().join('');

    var result = "";

    for(var i = 0; i < dateString.length; i++)
        result += dateString.charCodeAt(i);

    return result;
}

function unlock(int1, int2, int3, int4, int5)
{
    return encrypt(int1) == "5549508477713255485850495848483249555749321109774324948324410511470" && encrypt(int2) == "5756568477713252485848495848483249555749321109774324948324410511470" && encrypt(int3) == "5149538477713248485856485848483249555749321109774324948324410511470" && encrypt(int4) == "5356498477713256535853485848483249555749321109774324948324410511470" && encrypt(int5) == "5748568477713251535851485848483249555749321109774324948324410511470" ? 1 : 0;
}

Brute forced: 320689, 444121, 567553, 690985, 814417

@Tyilo If you stop now, I think no cracker can beat your score. ;)

@MartinBüttner Unless this can be golfed to under 512 per the OP, I don't think it counts.

C, 239 (Cracked by Dennis)
Go here for my updated submission.
Could probably be golfed a little more thoroughly. Admittedly, I haven't taken the time to prove the key is unique (it probably isn't) but its definitely on the order of a hash collision. If you crack it, please share your method :)
p(long long int x){long long int i;x=abs(x);
for (i=2;i<x;i++) {if ((x/i)*i==x) return 0;}return 1;}
f(a,b,c,d,e){char k[99];long long int m;sprintf(k,"%d%d%d%d%d",e,d,c,b,a);
sscanf(k,"%lld",&m);return p(a)&&p(b)&&p(c)&&p(d)&&p(e)&&p(m);}

So, 0 0 0 0 0?

Sigh that was a bug, but yes that works.

I've updated with a corrected version that should be a little more interesting ;)

See the corrected version here.

C, 212 by Orby -- Cracked
https://codegolf.stackexchange.com/a/36810/31064 by Orby has at least two keys:
13 103 193 283 373
113 173 233 293 353

Orby asked for the method I used to crack it. Function p checks whether x is prime by checking x%i==0 for all i between 2 and x (though using (x/i)*i==x instead of x%i==0), and returns true if x is a prime number. Function f checks that all of a, b, c, d and e are prime. It also checks whether the number m, a concatenation of the decimal representations of e, d, c, b and a (in that order), is prime. The key is such that a,b,c,d,e and m are all prime.
Green and Tao (2004) show that there exist infinitely many arithmetic sequences of primes for any length k, so we just need to look for these sequences that also satisfy m being prime. By taking long long as being bounded by -9.223372037e+18 and 9.223372037e+18, we know that for the concatenated string to fit into long long, the numbers have an upper bound of 9999. So by using a python script to generate all arithmetic sequences within all primes < 10000 and then checking whether their reverse concatenation is a prime, we can find many possible solutions.
For some reason I came up with false positives, but the two above are valid according to the program. In addition there may be solutions where e is negative and the rest are positive (p uses the modulus of x), but I didn't look for those.
The keys I gave are all arithmetic sequences but Orby's script doesn't appear to actually require the inputs to be an arithmetic sequence, so there may be invalid keys too.

MATLAB: Apparently invalid
Very simple, you just have to generate the right random number.
function ans=t(a,b,c,d,e)
rng(a)
r=@(x)rng(rand*x)
r(b)
r(c)
r(d)
r(e)
rand==0.435996843156676

It can still error out, but that shouldn't be a problem.

This approach is prohibited in the comments. If it's not mentioned in the question, propose an edit. Sorry.

@PeterTaylor I guess I am out then, I will just leave it here without score as I am curious whether someone can find a weakness.

MATLAB (with Symbolic Toolbox), 173 characters
This isn't an official entry and won't count towards anyone's cracking score, but it will net you mad bragging rights. ;)
function b=L(S),c=sprintf('%d8%d',S(1),S(2)-S(1));b=numel(unique(diff(S)))==1&&numel(c)==18&&all(c([8,9])==c([18,17]))&&isequal(c,char(sym(sort(c,'descend'))-sym(sort(c))));

The symbolic toolbox is only required to handle subtraction of big integers.
Brute forcing it should be a dog, but if you're familiar with the series it involves, the solution is trivial.

 Python 2 (91)
Edit: This isn't allowed because the argument for uniqueness is probabilistic. I give up.

s=3
for n in input():s+=pow(n,s,7**58)
print s==0x8b5ca8d0cea606d2b32726a79f01adf56f12aeb6e

Takes lists of integers as input, like [1,2,3,4,5].
The loop is meant to operate on the inputs in an annoying way, leaving a tower of sums and exponents. The idea is like discrete log, but with messy complication instead of mathematical simplicity. Maybe the compositeness of the  of the modulus is a vulnerability, in which case I could make it something like 7**58+8.
I don't really know how I'd prove that my key is the only one, but the range of outputs is at least 10 times bigger than the range of inputs, so probably? Though maybe only a small fraction of potential outputs are achievable. I could always increase the number of digits at the cost of characters. I'll leave it up to you to decide what's fair.
Happy cracking!

Mathematica - 72
Version 2 of my script, with the same key as the one intended for my version 1.
This basically removes negative prime numbers for NextPrime.
f=Boole[(p=Abs[NextPrime/@#])-#=={18,31,6,9,2}&&BitXor@@#~Join~p==1000]&

Running:
f[{1,2,3,4,5}] (* => 0 *)

Assuming that I've correctly understood what your code does, I get several solutions of which the smallest is initial term 9244115, delta 25.

@PeterTaylor I can confirm that that one is valid.

@PeterTaylor correct, another key is 1073743739, 1073886396, 1074029053, 1074171710, 1074314367

Python, 86 characters
a,b,c,d,e=input()
print 1if(a*c^b*e)*d==0xd5867e26a96897a2f80 and b^d==48891746 else 0

Enter the numbers like 1,2,3,4,5.
> python 36768.py <<< "1,2,3,4,5"
0
> python 36768.py <<< "[REDACTED]"
1

This isn't a valid submission; it accepts the input 1,0,1,63021563418517255630720,0.

@Dennis Fixed. I hope it's valid now.

19960211, 31167202, 42374193, 53581184, 64788175

@Dennis Correct and awesome. I think I'm very poor at math.

Simply checking if the sequence is in fact arithmetic (e.g., b-a==c-b==d-c==e-d) may have provided uniqueness without revealing so much information about the key. But I had already written a brute force cracker (estimated running time: 5 hours) for the original version. 63021563418517255630720 has only 256 prime factors and d has to be one of them...

@Dennis, 63021563418517255630720 isn't a 32-bit number.

@PeterTaylor: Good point... 274643839 40416932 26790592 8565190 0 then.

CJam, 37 characters (broken)
"煷➻捬渓类ⶥ땙ዶ꾫㞟姲̷ᐂ㵈禙鰳쥛忩蔃"2G#b[1q~]4G#b%!

Try it online.
How it works
See my new answer.
Example run
$ echo $LANG
en_US.UTF-8
$ base64 -d > flock.cjam <<< IueFt+Keu+aNrOa4k+exu+K2peuVmeGLtuq+q+Oen+Wnsu6AhMy34ZCC47WI56aZ6bCz7KWb5b+p6JSDIjJHI2JbMXF+XTRHI2IlIQ==
$ wc -m flock.cjam
37 flock.cjam
$ cjam flock.cjam < flock.secret; echo
1
$ cjam flock.cjam <<< "1 2 3 4 5"; echo
0

737262825 208413108 3974530688 3445680972 2916831257 works but isn't an arithmetic progression. Factored in 3 hours 20 minutes. 512-bit numbers were apparently doable in 72 hours for $75 on EC2 two years ago, so I think that would have been safe.

@PeterTaylor: That returns 1, but the last three integers are greater than MAX_INT, so it's not a valid key. That being said, 3 h 20 m is pretty impressive. The algorithm I was using took 16 hours for a 256-bit semiprime...

I thought there must be some negative numbers in there somewhere because the deltas were almost right but not quite. I'll get on to it.

737262825 208413109 -320436607 -849286323 -1378136039

@PeterTaylor: That's the one. I hope the 512 bit version lasts longer.

Python, 78
(Cracked by Tyilo in 14 mins)
Fun!
def L(a): return 1 if a==[(i-i**6) for i in bytearray(' ','utf-8')] else 0

Okay, it doesn't display properly here :(
Expects a list of five numbers, eg. [1,2,3,4,5]

Pretty easy: [-481890276, -594823292, -728999970, -887503650, -1073741792]

Thought so, well done :)

C, 212 (Cracked)
This is the same idea as my previous submission, golfed more thoroughly, with a bug corrected that passed 0,0,0,0,0 (Thanks to Dennis for pointing out the bug). Compile with -std=c99.
#define L long long
p(L x){x=abs(x);for(L i=2;i<x;i++){if((x/i)*i==x)return 0;}return(x>1);}
f(a,b,c,d,e){char k[99];L m;sprintf(k,"%d%d%d%d%d",e,d,c,b,a);sscanf(k,"%lld",&m);
return p(a)&p(b)&p(c)&p(d)&p(e)&p(m);}

Any sequence (arithmetic or not) of negative primes will work. Two examples: -7 -37 -67 -97 -127, -157 -127 -97 -67 -37

Yeah, my code is just riddled with bugs. The answer nitrous gave is along the lines of what I was looking for. But nice job pointing out the more obvious answers.

 Python 3 (152)
Edit 2: I'm withdrawing this entry because it accepting the correct key seems to depend on hardware or version specifics, which would be unfair to crackers. On online Python 3 interpreters I tried, low-significance bits of the result differed slightly, suggesting the algorithm is sensitive to the exact hardware implementation of arithmetic.
Edit: Made a much longer target to make uniqueness likely given 160 bits of input. Unfortunately, now this target takes over half my characters. This means that this style of submission is unfortunately largely a compression contest.
def f(l,a=[0]):
 for n in l:a+=[(.8+.6j)**(n+a[-1])]
 return a[2::2]==[-0.20857691594748845+0.9907381787645837j,-0.7480510203178323-0.0856921111325014j]

Nothing systematic, just some annoying mangling with complex exponents.

Are you sure this is unique? Your hash has less than 64 bits, and the input has 160.

@MartinBüttner Oh, I see. Is it actually 160 bits or 64-lg(5)? I had understood that only arithmetic sequences needed to be considered.

No, your program needs to return 0 for everything that's not an arithmetic sequence.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes