This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Unless you know how to wrap the phone number in a GuardedObject using a java.security.Permission that relies on an java.security.cert.X509Certificate provided by a bunch of stuff that gets deep in md-5, then I would instead ask for the tele number from the user and wrap it with a toHashCode method and only use some or another hash-code method ( there are plenty in the java api - just about all of the java api's ) and do not ever send out the telephone number in any fashion, just use it internally in your app and come upwith some sort of randomizer using the java dot random classes.
There is a night-mare scenario: What happens if the device is momentarily not in view of the person ? Few people keep their cell device chained to a secure environment. Many of the issues involved in identity-theft are not within scope of a reasonable mind.
Use some internally generateed hashCode(), those can be hardcoded in or placed in persistent storage on all but the most limited of api's.
"The differential equations that describe dynamic interactions of power generators are similar to that of the gravitational interplay among celestial bodies, which is chaotic in nature."