It does not make sense to encrypt this since unencrypted information will be available on the client.
Facebook does not encrypt anything even because the engineers who work there know that it has zero effectiveness to do this.
If you do not want to use the table ID, use another unique key, but in essence it is the same.
It is no use hiding the sun with the sieve. If you want security validate everything that comes from outside and do not let user do what he can not. If there is a risk of someone getting the ID and doing what is not supposed to be an application problem, fix this problem.
If any user has to have any right to do something potentially problematic, authenticate him to know who he is, give the privilege only to who should and create a log to audit if someone does what he does not should. Those who have no privilege can not do anything wrong.
If everything is safe, the exposed ID is no problem at all, no matter if it is a primary key or not.
The only problem that can happen is that you will someday resolve to change all sequencing of IDs, something that should not be done, but if you do and someone has an ID in the old template, there may be some inconsistency, but again, it's a application problem.
There is no way for you to associate an exposed item without a unique information linking to the database. And I'm talking about something mathematical / physical, it's not that you do not have a technology that accepts this.
