Assuming you're using https
to transmit the data from client to server (which is required for any level of security) and thus you will be transmitting the whole phone number anyway (because you want to store the phone number in a retrievable way), there is no real point to doing client-side encryption or hashing of anything. Just send the phone number from client to server under the protection of https. And, if you find a particularly good reason for storing a hash of the last four digits, you can compute that hash on the server from the whole phone number before storing in the database.
And, if you're not using https, then please don't try to reinvent your own public key/private key encryption to try to get some of the benefits of https while still using http. Just use https and stand on the shoulders of 30+ years of development that have gone into that along with all the other benefits it provides.
Any client-side symmetric encryption requires the key be present on the client which is a horribly massive security risk since any client suddenly has access to your key which basically renders the client-side encryption pointless. This is the whole reason that public key encryption was invented and is used by https. So, just let https do it's job to protect the data in transport between client and server.
Your could do public/private key encryption where your server has a private key and you give the client the public key and it uses that to encrypt the data, but it is not really clear what benefit you are getting from that because the data should already be protected in transmit by public key/private key encryption via https.
Once, the data is on the server and you want to store it in your database, it is a separate discussion about whether you want to encrypt it in the database using a server-stored and secured symmetric key. Sometimes that is a good idea and sometimes the circumstances are such that doing so doesn't really increase your level of security for a variety of reasons (mostly around how the key itself isn't more secure than the database).
I don't know of any reason why you would use public key/private key encryption all on the server. That's a bunch of extra computation for no real benefit if everything is stored on the server. The big reason for using public key/private key encryption is so that you can give out the public key to anyone who wants to send you encrypted data, but that public key can't be used to decrypt the data that was encrypted with it. For that, one would have to have the private key. For data that is kept entirely on the server and managed by the server, you already would have to secure the private key so you may as well just use a symmetric key and secure it. There is no "third party" that you're asking to encrypt data without having the ability to decrypt the data which is the main reason for public key/private key encryption.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…