Almacenamiento de clave de cifrado y cifrado de punto flotante

1

Estoy trabajando en una aplicación web en la que necesito cifrar algunos campos según la configuración del usuario y mostrar la información descifrada. Los valores de campo pueden ser texto o enteros o flotantes.

Estamos planeando usar AES-128 pero no estoy seguro de la cantidad de claves que se usarán. Lo que quiero decir con esto es que la aplicación tiene actividades que pueden contener datos confidenciales que deben cifrarse. ¿Es mejor tener una sola clave para toda la aplicación o generar claves por actividad? Además, ¿cuál es la mejor práctica para almacenar claves? ¿Deberían almacenarse en la misma base de datos o en un almacén dedicado de clave-valor?

A nivel de prueba de concepto, ¿cómo manejar el cifrado para números de punto flotante? He intentado convertir a cadenas y reconvertir a flotadores, pero las bases de datos dan problemas de precisión.

    
pregunta Avnish 17.03.2015 - 13:32
fuente

1 respuesta

3

El cifrado funciona en secuencias de bits. Puede cifrar cualquier cosa que pueda representarse como bits. No puede encriptar nada que no haya sido convertido a bits. Afortunadamente, cualquier cosa en una computadora, por definición, es, en algún nivel, una secuencia de bits.

La conversión de enteros de punto flotante en bits y viceversa es algo común, sujeto a algunos estándares como IEEE 754 . Algunos lenguajes de programación ya ofrecen funciones para realizar dicha conversión de una manera determinista y bien definida que maximiza la interoperabilidad; p.ej. en Java .

En cuanto a la administración de claves ... el punto más importante que se debe entender es que el cifrado no es un tipo de salsa de seguridad mágica que mejore la seguridad simplemente al ser aplicado de manera más o menos generosa. El cifrado no crea confidencialidad; lo concentra . Supongamos que tiene una parte (posiblemente grande) de datos D , que desea mantener la confidencialidad incluso contra personas que pueden mirar los datos donde están almacenados. Al cifrar D (si se hace correctamente) con una clave K , ha reducido el problema de confidencialidad al de K : si los atacantes no pueden vea K , entonces no podrán ver D incluso si ven la versión encriptada de D . Pero todavía tienes que pensar en cómo mantener a K fuera del alcance de estos atacantes.

Por ejemplo, si sus atacantes pueden tomar un volcado de su base de datos, lleno de datos que fueron cifrados con K , y K también es también almacenado en la base de datos, entonces el cifrado fue totalmente inútil. El cifrado solo puede tener sentido en la medida en que la clave pueda mantenerse fuera del alcance de los atacantes mediante otros métodos (por supuesto, la clave es pequeña y no cambia con frecuencia, lo que facilita la tarea). De lo contrario, el cifrado de todos los datos se convierte, de hecho, en un baile elaborado que gastará los ciclos de la CPU, aumentará los costos de desarrollo y apaciguará a los auditores, sin hacer que las cosas sean más seguras.

El cifrado es una herramienta, no un objetivo. No cifras porque quieres cifrar (bueno, desafortunadamente, el cifrado a menudo se aplica por esa razón exacta). Cifras porque, dentro de un modelo de seguridad dado , has determinado que existe un problema de confidencialidad para los datos que se almacenan o transfieren, y el cifrado puede ayudar a reducir ese riesgo al sacar matemáticamente grandes trozos de hardware y software fuera de la ventana de exposición. El modelo y la arquitectura del sistema le dirán quién (en términos de personas y componentes del sistema) debe acceder a los datos y quién no; en otras palabras, donde se deberá conocer la clave de cifrado / descifrado; esto, a su vez, implica qué tipo de gestión de claves necesita (número de claves, ciclo de vida de las claves ...).

    
respondido por el Thomas Pornin 17.03.2015 - 13:56
fuente

Lea otras preguntas en las etiquetas