¿Es la encriptación de clave pública la opción correcta?

Estás hablando de generar una clave pública / privada para cada usuario. Eso es una exageración. En su lugar, asegúrese de utilizar un certificado SSL firmado con TLS 1.2 (o posterior) para la comunicación entre la aplicación y su servidor. Para comprender mejor el proceso, lea ¿Cómo funciona SSL / TLS?

Para mantener los datos separados, ahí es donde entra en juego algo así como una sesión (la mayoría de los lenguajes de programación web más importantes admiten algún tipo de gestión de sesión). Las sesiones almacenan datos en el extremo del servidor y luego le dan al usuario un hash aleatorio de algún tipo. Si bien siempre existe la posibilidad de envenenamiento de sesión (donde obtengo el hash de otra persona), las probabilidades son generalmente bajas. No son más altos que intentar intercambiar claves públicas / privadas (lo que deberá hacerse antes de enviar cualquier información).

Una vez que tenga una sesión, puede almacenar algo como una ID de usuario en el interior (el usuario no puede acceder directamente a este y nunca lo ve). Luego, cuando el usuario solicita un registro, verifica si ese usuario tiene permiso para acceder a ese registro y permite / deniega en consecuencia.

Como se menciona en la respuesta de @machavity, el uso de una clave privada pública para cada usuario de aquí no es una buena solución.

  

• Los datos siempre se ingresarán en la aplicación y se verán a través del sitio web, por lo que solo los usuarios del sitio web necesitarán una clave pública y privada, ya que solo necesitan ver la información (se podría usar híbrido, pero los mensajes serán cortos)
  
• Cifre el lado del servidor de datos utilizando la clave pública del usuario correcto autorizado para ver la información
  

¿Qué pasa si los usuarios quieren compartir datos entre sí?

  

• Los datos cifrados se almacenarán en la base de datos
  

Si bien puede ejecutar consultas para usuarios individualmente, ¿qué sucede si desea ejecutar algunas consultas en los datos de varios usuarios? Di tratando de encontrar patrones o cosas

Esto es lo que debes considerar:

• Haga que los usuarios creen cuentas tanto en la aplicación como en el sitio web. De esta manera, tendrá una identidad única de cada usuario
• Use los mecanismos de control de acceso para asegurarse de que una identidad particular pueda acceder solo a los datos a los que tienen acceso
• Teniendo en cuenta que los datos son confidenciales, implemente la comunicación TLS entre su aplicación y el sitio web.
• Deje los datos en la base de datos tal como están. ¡Con excepciones de contraseñas, por supuesto!

(Supongo que ya has cifrado la conexión con HTTPS, lo que deberías hacer).

Es común dejar los datos en la base de datos sin cifrar. Esto es necesario para permitir consultar la base de datos en un formato por lotes. (es decir, quiero ver a todos en un código postal en particular, o ver quién tiene una dirección de correo electrónico en particular, qué nombres de usuarios se toman, etc.) El control de acceso es posible de cualquier manera.

Si no se requiere la consulta en formato de lote, (es decir, el contenido del mensaje) el cifrado puede ser una buena característica de seguridad. Esto suele ser una segunda línea de defensa en caso de que el servidor esté comprometido.

Un problema con el cifrado almacenado es cómo almacenar la clave de cifrado. Si la aplicación cliente no es lo suficientemente inteligente / confiable para administrar el archivo de clave, debe almacenarse en el servidor. Pero si almacena la clave en el servidor y los datos cifrados, entonces un pirata informático podría llegar a ambos.

(Sus contraseñas de inicio de sesión de usuario deben estar ocultas, por supuesto, no cifradas)

Incluso con estos problemas, debe cifrar cualquier información especialmente sensible, como contraseñas a otros servicios, SSN, documentos súper secretos, etc. en caso de que su servidor se vea comprometido debido a algún otro defecto.

(Los números de las tarjetas de crédito también se cifrarían, pero para evitar los problemas de PCI DSS, lo subcontrataría a la puerta de enlace de procesamiento).

Una opción es tener una única clave de cifrado maestra y simplemente almacenarla fuera de la base de datos. De esa manera, si un pirata informático utiliza SQLi para obtener datos cifrados en la base de datos, aún no tendrá acceso a la clave porque está fuera de la base de datos. Sin embargo, para otras infracciones, además de SQLi, probablemente podrá encontrar su archivo clave con bastante facilidad.

Si te sientes ambicioso, puede obtener claves de las contraseñas del usuario como esta . Sin embargo, es probable que esto no sea compatible con la función de restablecimiento automático de contraseña.

Pero como he dicho, es más común dejar los datos sin cifrar. En particular, si los datos no son demasiado confidenciales o si necesitará utilizar una consulta por lotes de la base de datos para acceder a todos ellos.