Idea para una aplicación no cifrada que no sea web.

Question

Idea para una aplicación no cifrada que no sea web.

#1 de Philipp (3 votos)
#2 de drewbenn (2 votos)

5

Tengo una idea para una aplicación que podría ser útil (aunque si no lo es, todavía aprendí en el proceso, que es lo que importa).

Hay un montón de aplicaciones web de pastebin encriptadas (por ejemplo, defuse.ca/pastebin.htm) que realizan el cifrado / descifrado en el cliente mediante JavaScript. Para lograr el cifrado de extremo a extremo, A MENOS QUE alguien piratee el servidor y modifique el JavaScript para que los futuros usuarios que se conecten obtengan un código JavaScript modificado que filtre su contraseña no cifrada al hacker.

Mi idea es que el usuario debe interactuar con una aplicación de cliente independiente en lugar de una aplicación de navegador para eliminar la vulnerabilidad de JavaScript.

El usuario descarga la aplicación independiente del cliente. Se proporciona cierta seguridad durante la descarga / instalación porque: a. La aplicación del cliente está firmada digitalmente segundo. Las descargas se realizan desde un servidor https do. SHA hashes están disponibles para archivos descargados re. El código fuente de la aplicación cliente está disponible
El usuario inicia la aplicación y selecciona "nueva pegar". Él ve un cuadro de texto grande.
El usuario escribe / pega texto y hace clic en "Enviar". Al usuario se le solicita una contraseña y la ingresa.
La aplicación de cliente CSPRNG genera sal S. de 128 bits.
La función de derivación lenta toma la contraseña y S y deriva la clave K de 256 bits y el vector de inicialización IV de 128 bits.
Se realizó el cifrado Aes (tamaño de bloque de 128 bits, clave de 256 bits, modo CBC, relleno PKCS7) utilizando texto sin formato, K y IV para producir Cyphertext C.
La aplicación del cliente llama al servidor (reste la llamada a https uri) y le pasa S y C.
El servidor almacena S y C en una fila de la base de datos (S es la clave principal).
El servidor le dice al cliente que los datos están almacenados. El cliente le dice al usuario "datos guardados" y presenta S al usuario como el identificador único de pegado.
El usuario toma una nota de S (archivo de texto en su computadora, correo electrónico a sí mismo, etc ... no tiene que mantenerse en secreto). La contraseña debe mantenerse en secreto.
Más tarde, el usuario vuelve a iniciar la aplicación cliente.
Él elige "abrir pasta existente". Él ingresa S y selecciona encontrar.
La aplicación del cliente le pide al servidor que encuentre una S que coincida con el pegado (llamada restante a https uri). Si lo hace, devuelve el texto cifrado.
Si se encuentra pegar, la aplicación cliente solicita al usuario la contraseña de descifrado. Él lo escribe.
La función de derivación lenta toma la contraseña y S y deriva la clave K de 256 bits y el vector de inicialización IV de 128 bits.
Se realizó el descifrado Aes (tamaño de bloque de 128 bits, clave de 256 bits, modo CBC, relleno PKCS7) usando texto plano, K y IV para producir texto plano.
La aplicación del cliente coloca texto sin formato en el cuadro. El usuario puede alterarlo y volver a cifrarlo o cerrarlo y hacer una nueva pegada (volver al paso 2).

Notas:

Varios usuarios pueden ver el mismo pegado si: a. Acuerdan de antemano una contraseña o la contraseña se comunica del usuario 1 al usuario 2 después de que realiza el pegado, Y segundo. El usuario que hace el pegado comparte S con otros usuarios (esto puede ser compartido de forma insegura).

Preguntas:

¿Qué vulnerabilidades de seguridad tiene esta configuración y cómo podría mejorarse?
¿Me estoy perdiendo algo vital en términos de la experiencia del usuario?
Re: Paso 17. Leí que nunca debes usar la misma sal dos veces. Sería molesto que el identificador de la pasta (S) cambie con cada modificación / reencriptación (si varios usuarios están accediendo a la misma pasta, deberían recomendar la nueva S cada vez que se realice una actualización / reencryption), pero es ¿Es inevitable hacer esto si no quiero sacrificar la seguridad?

Gracias de antemano!

hash encryption

pregunta Ralph P 07.04.2016 - 21:42

fuente

2 respuestas

Lea otras preguntas en las etiquetas hash encryption

¿Cuáles son los problemas con la carga de claves cifradas del lado del cliente en keybase.io? ¿Por qué está adicional_data vacía en TLS 1.3?

score 3 · Answer 1

Soy un miembro de la policía del pensamiento en un estado policial distópico y puedo escuchar todo el tráfico de Internet.

A través de mi trabajo de detective, descubrí que Bob es un criminal del pensamiento. Pero Bob está fuera de mi alcance.
Noté que Bob usó tu programa para cargar varios cyphertexts con las sales S1, S2 y S3 a tu servidor.
También noté que Alice, Charlie y Dora solicitaron los cyphertexts con las sales S1, S2 y S3 de su servidor.

¿Sé cuál es el contenido de esos mensajes? Aún no, pero cuando detenga a los tres y los interrogue por un tiempo, entonces uno de ellos seguramente se quebrará. ¿Me importa? En realidad, no lo hago. Asociarse con Bob es motivo suficiente para condenarlos por traición.

¿Cómo podrías hacer mi trabajo más difícil?

Utilice TLS con secreto de envío para la comunicación entre el servidor y los clientes. De esa manera solo sé quién usa su servicio y cuándo, pero no qué mensaje exactamente se cargaron / descargaron. Cuando la cantidad de archivos no traidores es mucho mayor que la cantidad de archivos traidores, arrestar a todos sus usuarios por si acaso no sería factible (solo tenemos muchas salas de interrogación y nuestra economía no puede permitirnos encerrar demasiados de nuestro trabajo drones a la vez). Advertencia: cuando logre aprovechar su servidor, puedo volver a escuchar a sus usuarios nuevamente.

También puede hacer que su cliente solicite muchos archivos aleatorios (pero válidos) que el usuario no solicitó y ni siquiera tiene la contraseña para. De esa manera, puede ofuscar la red de comunicación de sus usuarios y obligarme a perder mi tiempo deteniendo a muchas personas aleatorias que no saben nada.

Pero si realmente quieres darme un dolor de cabeza, deshazte de tu servidor central y cambia a una arquitectura distribuida como Freenet donde todos los datos se distribuyen a través de la red cliente y nadie sabe qué cliente guarda qué documentos (ni siquiera los clientes mismos). Pero un cambio de arquitectura tan drástico lo enviaría de vuelta al tablero de dibujo para rediseñar su protocolo desde cero.

score 2 · Answer 2

Parece que el enlace más débil es la contraseña, ya que es lo único que se necesita para descifrar el texto, por lo que los usuarios DEBEN crear buenas contraseñas. No puedo hablar sobre la mayoría de las decisiones de seguridad que eligió, pero tengo algunas opiniones sobre la interfaz de usuario:

Hay un potencial para colisiones de S . ¿Por qué no hacer que la aplicación cliente consulte al servidor por S como parte del paso 2, y el servidor devuelve una ID única? Es posible que algunas (muchas) de esas ID nunca se utilicen (si el Paso 7 no se completa, enviando C de nuevo al servidor), pero está bien.
Puede incluir una cadena mágica (por ejemplo, el nombre de su aplicación) como un prefijo al texto sin formato antes de cifrar. El usuario no lo vería, pero cuando se produce el descifrado, su aplicación puede verificar la existencia de la cadena mágica y, si no está allí, notificar una advertencia al usuario. Esto sería más fácil de usar que mostrar caracteres de basura de un descifrado fallido.
Está bien reutilizar la sal un par de veces, solo quieres que generalmente sea diferente para evitar que un atacante use una tabla de arco iris para "invertir" un hash. La única vez que se reutilizará la sal es si el usuario cambiara su contraseña de un conjunto limitado (por ejemplo, un PIN numérico de 4 dígitos) y un atacante tuviera la oportunidad de crear una tabla de arco iris, o si el atacante ya creó una tabla arco iris con esa sal (así que use algo largo como un UUID (el usuario probablemente esté enviando un correo electrónico alrededor del enlace, así que no importa si S es muy largo; si necesita para abreviar, también podría agregar una funcionalidad de acortador de URL que solo apunte a S )).