Homebrewing algo como SSL

TL; DR: Realmente no encuentro ningún punto positivo para inscribir su propia Seguridad. Puedes intentar implementar los conceptos básicos de SSL en alguna aplicación ficticia para aprender cómo funciona, pero además no deberías considerar eso para usarlo en Productivo. Por su propio bien y por el de cada usuario que debería usar su aplicación.

Además del punto de "no rodar los tuyos" (que siempre es un argumento que elimina la necesidad de una implementación propia porque un desarrollador "normal" no puede desarrollarlo correctamente) según los puntos de Martin:

• tiempo de compilación - > no compilará toda la biblioteca SSL, la usará. Así que usar uno externo es más rápido que el tuyo
• tamaño de repositorio - > utiliza la Biblioteca, su propia implementación sería mucho más grande
• solo codificamos las cosas que necesitamos - > haces exactamente eso;)
• experiencia - > ok, aprenderás los conceptos básicos de SSL. Pero si luego programa algo que está roto al principio y piensa que este código es correcto, aprenderá algo incorrecto y pensará que es correcto. Eso es mucho peor que aprender a usar una biblioteca bien conocida.
• licencia de cosas - > sí, quizás debas poner un texto en tu aplicación que diga que usas esa biblioteca. Pero luego vaya a diferentes aplicaciones grandes (por ejemplo, el sistema operativo Android) y vaya a su parte de licencia. Usted (si usa SSL) siempre verá el texto de la licencia de la biblioteca openSSL allí
• sería genial - > lo que está bien en construir algo que no es bueno;)

Adicional:  Siempre trate de usar las bibliotecas que son bien conocidas. No necesita corregir errores dentro de ellos, son revisados por más ojos que podría pagar y los errores se encuentran mucho más rápido que en su código (sus 10 000 usuarios frente a sus 1 millón de usuarios como ejemplo). Además, hay más información sobre bibliotecas de seguridad que los expertos que saben lo que están haciendo verifican muy a menudo;)

El mejor código es aquel que no escribes.

@Serverfrog alcanzó muchos de los puntos, pero la única razón válida para escribir su propio protocolo de cifrado hoy en día sería aprender de la experiencia.

El problema con escribir el tuyo propio es que no puedes ver sus defectos. Schnier dijo una vez de manera sencilla: "Cualquiera puede crear un algoritmo de cifrado que no puedan romper". Lo mismo es cierto para los protocolos. Así que, por favor, no se sienta mal, porque este es un problema bien entendido en el desarrollo de protocolos criptográficos.

Un problema es que desconoce todos los problemas de seguridad que han plagado a todos los túneles de encriptación anteriores y simplemente no conoce todas las vulnerabilidades contra las que tendría que defenderse. Por ejemplo, ¿sabía que si no codifica su algoritmo de cifrado a la perfección, puede filtrar información que ni siquiera puede ver? Un atacante puede enviar miles de solicitudes cifradas en su máquina, programar las respuestas y usar en el tiempo para Aprende fragmentos de tus claves secretas . ¿O si cifra mensajes comprimidos, un atacante puede medir la longitud de las respuestas para extraer el contenido de un mensaje? ¿Sabe por qué el mundo está usando TLS 1.2, por qué los investigadores están trabajando en TLS 1.3 y lo que le sucedió a TLS 1.1, TLS 1.0? , SSLv3, SSLv2 y SSLv1 ? Y esos son solo algunos ejemplos de los cientos de fallas que se han encontrado.

La historia de la criptografía está llena de cientos de lecciones dolorosas, caras y, a veces, fatales sobre cómo los atacantes pueden descubrir nuevas fallas y explotarlas; a pesar de que los principales estudiosos y expertos en el campo nunca los encontraron a pesar de años de búsqueda.

Si avanza, ¿qué expertos tiene en fila para estudiar sus protocolos criptográficos en busca de puntos débiles? ¿Dónde están estos académicos que van a escribir su tesis de maestría en sus protocolos, probando que no hay defectos ocultos? En el peor de los casos, tu criptografía funcionará contra algunos atacantes simples hasta que tengas mucho éxito, que es el peor momento para que te ataquen.

Imaginemos que tu juego se vuelve tremendamente exitoso - World of Warcraft exitoso. Millones de clientes de todo el mundo están gastando cientos de millones de dólares en compras dentro del juego, y todos ustedes están acumulando dinero como Scrooge McDuck. Eso es mucho dinero, y cuanto más dinero tienes, más poderosamente motiva a los ladrones a robarlo. Un día, cuando llegue al trabajo, descubra que alguien ha roto su criptografía, robó todos los artefactos de cada cliente, descubrió cómo emitir 10 mil millones de piezas de oro que no se pueden rastrear, números de tarjetas de crédito robados y contraseñas de sus bases de datos de clientes, y le han destrozado La economía del juego. La reputación de su empresa está en ruinas. ¿Vale la pena correr el riesgo con un protocolo casero?