Re: Encriptar campo

Creo que debes contemplar todo lo que te ha dicho Álvaro Herrera. Si solo es un campo, creo que puedes usar un hash (sha) o cifrado simetrico (AES), pero si es toda la tabla o la BD, entonces debes tener en cuenta lo que dijo Álvaro Herrera

>________________________________
> De: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
>Para: Conrado Blasetti <conrado(at)mapfre(dot)com(dot)ar>
>CC: "pgsql-es-ayuda(at)postgresql(dot)org" <pgsql-es-ayuda(at)postgresql(dot)org>
>Enviado: Jueves 28 de febrero de 2013 15:16
>Asunto: Re: [pgsql-es-ayuda] Encriptar campo
>
>Conrado Blasetti escribió:
>> Gente, buenos días.
>>
>> Estoy trabajando sobre Win7 con una app desktop con c# (.net) y PostgreSQL 9.0.
>> Tengo una tabla con un campo del tipo character varying(20), el cual representa un Nro de Documento (Argentina).
>> Necesito encriptar este campo de manera tal que, desde la base de datos, no pueda ser legible y que solo pueda ser consumida desde la misma app desktop.
>>
>> El campo será indexado y de busquedas constantes.
>> Qué tipo de encryptado o técnica me sugieren?
>
>Este es un problema bastante complejo que requiere pensar muy bien antes
>de hacer nada.  Lo que estás diciendo básicamente es que quieres que en
>la BD la info esté cifrada, y que no se pueda obtener el valor sin
>cifrar mirando sólo la BD.  Es decir, la llave de cifrado debe estar en
>la aplicación.  Entonces la aplicación debe extraer el valor cifrado
>desde la BD, y descifrarlo a posteriori *sin involucrar a la BD para esto*.
>
>Una de las primeras cosas que tienes que preguntarte cuando tratas con
>temas de cifrado es cómo manejarás las llaves.  ¿Qué pasa si la llave se
>filtra y necesitas cambiarla?  En la BD tendrás que cambiar todos los
>valores almacenados, pero necesitas saber cuáles valores están cifrados
>con la llave antigua y cuáles con la llave nueva ... de lo contrario una
>caída en medio del cambio resultará catastrófica (recuerda que no puedes
>pasarle la llave a la BD para hacer un UPDATE masivo, por lo tanto
>tienes que cambiar una por una).  En conclusión, de alguna forma debes
>almacenar una "versión de llave" junto con los valores.  La aplicación
>debe almacenar todas las llaves con su versión.
>
>(Observa que lo anterior no aplica sólo a llaves que se filtran;
>deberías tener una política de crear llaves nuevas en forma periódica)
>
>El tema de las búsquedas usando los valores cifrados es simple: la
>aplicación debe pasar el valor cifrado a buscar.  Obviamente no puedes
>darle un prefijo del valor, es decir búsquedas con LIKE o similares son
>imposibles; todo eso deberás implementarlo en la aplicación, de ser
>necesario.
>
>¿Cómo harás respaldos?  De la BD es fácil, porque no hay nada que
>esconder dado que los datos están todos cifrados; pero el almacén de
>llaves de la aplicación es muy delicado.
>
>El tema de si usarás un algoritmo de cifrado simétrico o asimétrico no
>es súper relevante.  Procura usar un algoritmo moderno, quizás alguno de
>NESSIE (posiblemente AES/Rijndael).
>
>--
>Álvaro Herrera                http://www.2ndQuadrant.com/
>PostgreSQL Development, 24x7 Support, Training & Services
>
>-
>Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
>Para cambiar tu suscripción:
>http://www.postgresql.org/mailpref/pgsql-es-ayuda
>
>
>