Encrypting DB primary key for obfuscation on client side

I'm building a web app and I'd like to obfuscate the primary keys of resources the client is viewing in his browser, for security reasons.

Here is an example of a primary key (1001) exposed in the URL: http://ift.tt/2ud18UU

If the primary key is displayed in plain text (number), the user can guess how many resources we have on server, try to open other user's resources (so called FUSK attacks) and other bad things can happen.

To obfuscate the primary key, the most secure way is to add a column to the DB with crypto-random strings, associated with each PK, and use those instead of the PK on client side. However, this security comes at a cost:

1) Generating new random string can require several attempts due to collisions (extremely rare, but not entirely excluded).

2) After deleting a row, the uniqueness of a new random key cannot be verified (against the deleted row), and also can cause collisions with DB requests that come later after the original row was deleted.

The above problems could be solved by maintaining a separate table pre-populated with random strings, but I don't like the quickly piling up expenses for such a simple task.

How about simply encrypting the PK with a symmetric key? There is for example Skipjack encryption method which fits perfectly for 64-bit keys.

The question is, are there any pitfalls of this idea I'm not aware of?

The opponents of the idea say that (unlike the truly random strings) sooner or later the encryption could be broken and result in a security leak. Does it seem really probable? AFAIU, symmetric encryption is considered pretty secure. Besides, my resources are additionally protected with user authentication, so the leak of PK isn't very harmful even if it happens.

What's everyone else is using for the primary DB key obfuscation? Is encrypting primary DB key a common practice? Or does everyone use random string mapping?