Moore's law has several variants. Gordon Moore himself first put it as a double of transistor density every year (i.e. you could put twice as many transistors on a given wafer surface, and production cost increases linearly with the wafer surface). In 1975, Moore altered his law to a double every two years. However, putting more transistors in a given surface also entails making them smaller and closer to each other, and this allows for clocking them at higher rates, too. So the "classical" version of Moore's law is "double performance every 18 months".
Performance depends on the kind of task you are trying to perform. For a general purpose computer, having more transistors does not makes things really better beyond a given point -- if you want to add "real-life" values which fit in 32 bits, then having 64-bit registers will not give you a boost. At some point, "many transistors" turns into "several cores", which helps a lot if (and only if) the task at hand is amenable to parallelism.
For symmetric cryptography, we usually worry about exhaustive search. The cost-effective attacker will use FPGA or ASIC. Parallelism is a given, so the attacker benefits from advances in both transistor density and clock rates. However, for the truly massive attack jobs, energy consumption (and its offspring heat dissipation) becomes a bottleneck, and higher clock rates do not help for that. So you can consider Moore's law to amount to about "1 bit per year" (a 100-bit key is as robust now as a 120-bit key will be in 20 years).
For elliptic curves, the most efficient attack is discrete logarithm using the "generic" algorithms, which work in $O(\sqrt{N})$ for a curve of size $N$. This means that a 256-bit curve fares about as well as a 128-bit symmetric key. Moore's law, then, yields "2 bits per year" of computing power to the attacker.
For integer factorization and classical discrete logarithm (i.e. RSA, DSA, Diffie-Hellman, ElGamal... but not the EC variants thereof), things are more complex. The best known algorithms are subexponential (that's the General Number Field Sieve); but their implementation requires large amounts of fast RAM. RAM size increases with transistor density as per Moore's law, but RAM latency does not get better as fast as that. In fact, base RAM latency is more or less stalled in recent computers. Therefore, it is difficult to give even a rough estimate of Moore's law effect on RSA security.
To account for Moore's law, several individuals and organizations have published estimates of key strength, as "recommendations" for minimal key length, now and in the next few decades. These recommendations vary quite widely from each other; there is a nice summary (with online calculators) on this site. The recommendations always use worst case estimates: they do not want to predict the actual attack cost, they aim at presenting key sizes which are "large enough" to thwart attacks. Therefore, each figure is a mixture of attack cost estimates, and a more or less generous amount of paranoia. For instance, NIST recommends not using 1024-bit RSA keys since last year, and yet the current RSA-breaking record is 768 bits, are it is known right now (2012) that existing academic resources are far from being sufficient to attack a 1024-bit RSA key.
As a very crude but effective estimate: 112-bit symmetric keys, 224-bit elliptic curves, and 2048-bit RSA/DSA/DH keys, ought to be enough for the next two decades (at least).
