While I understand the motivation, I don't understand the logic of the question.
The first issue is that with ever-increasing security demands, it is important to avoid the client-side capture of sensitive information altogether. I would argue that if the data is sensitive enough to encrypt before it hits the data layer, it probably shouldn't be put into an Analytics tool. If it were crucial that this data get into analytics, I would argue against decryption before sending it across the wire. All it would take to grab that value from the analytics beacon is a browser extension with the right permissions (a wolf in sheep's clothing).
Having said that, as a matter of best practice, I do hash user ids and email addresses, but this is done using one-way hashing rather than encryption/decryption. My first preference for hashed ids is that the hashing happen on the server-side and use a private salting procedure to defeat hash cracking using rainbow tables (backward lookups from simple hashes of known values). Barring server-side hashing, I use an SHA-256 hash (which is conveniently provided in the SDI toolkit). The client-side hashing is really just a hedge against lazy hackers who aren't willing to trace the process back to the input of the hash. At the same time, data obfuscation via hashing is good to combat the issue of "perceived insecurity" - the situation where you're doing nothing wrong, but it just looks insecure and could be a liability if called out publicly.
When information is highly sensitive (or the relationship between non-sensitive attributes provides a key to sensitive info), server-side analytics may provide the answer (see AA data insertion API).
Does that help?
-Stew
