Methods of making ASIC/GPU resistant encryption? Is there way to make encryption scheme ASIC and GPU resistant, besides using a lot of memory?

And what is there ciphers or modes of use for such purpose? Including public keys algorithms maybe too, if there is any methods for them.

Or it's only worth to defend key derivation function? (Like scrypt, but it obviously failed in the case of litecoin.)

Clarification: 'encryption scheme' is protocol and/or system using cryptography to encrypt text. It's meaning opposes single algorithm, like AES or whatever. And it should be resistant against ASIC/FPGA/GPU/crypto-hardware optimized algorithms, like brute-force, or whatever algos there is for such hardware. It should make such attack not orders faster than on standard CPU or orders more expensive.
As pointed in this comment, using a huge random key for a sound block cipher is an excellent defense to resist ASIC/GPU attacks. Each bit added doubles the effort required. If an adversary was able to build $10^{12}$ ASICs each capable of testing $10^{12}$ keys per second, odds of finding a 128-bit key by brute force running that for a decade are less than one in $10^6$. Thus 128 bits of key are good enough to resist ASIC/GPU attacks in the foreseeable future if you discount the possibility that quantum computers will become useful cryptanalytic tools; make it 256 bits if you account for that or a number of other questionable possibilities. Use this as key for a cipher without a backdoor, on a platform with no exploitable side channel: confidentiality problem solved (but neither integrity or anonymity). Fine, but:


Generating a true random secret key is non-trivial; and it is impossible to distinguish from its output that some allegedly true random generator is bad (that's for many incompetently designed/implemented generators, and any competently rigged one).
In many applications, both sides must agree on the secret key (Public Key cryptography can help that, but I won't touch key establishment or distribution here).
Real platforms have side channels, accidental or deliberate.
Typical users have great pain remembering even a 80-bit random key (roughly equivalent to learning three 8-digits phone numbers, not including prefix).


The last issue is often dealt with exclusively by key stretching (also known as password-hashing, or Password-Based Key Derivation Function; you know when a field is immature when its name has not even settled). A PBKDF turns a weak passphrase into a wider key, using as many iterations as practical of some appropriate transformation. This is when (and only when for a proper system, with the possible exception of PK crypto as used in key establishment or distribution) ASICs/FPGAs/GPUs should be a threat.

The current state of art in key-stretching is scrypt. In order to reduce the speedup obtainable at a given cost by using ASICs/FPGAs/GPUs, scrypt strives to make best use of resources available by the legitimate key stretcher with a modern CPU:


considerable memory;
multiple cores;
fast operations (addition, xor, and fixed rotations) so that software performance is not too bad.


How to improve on that is the subject of active research, and the ongoing Password Hashing Competition.