Ir al contenido principal

Algoritmo de cifrado

No está mal llevar un registro de tu actividad y hay programas para este proposito, pero claro a día de hoy que sacan más dinero por espiarte que por venderte cosas igual no está de más cifrar la actividad.

Igual tu actividad no es original pero sacando datos a todo el mundo y cocinándolos en ordenadores adecuados con IA, se puede sacar información ventajosa para invertir en bolsa o predecir tendencias... o bueno espiarte también por que no?

No vaya a ser que te enteres de las cosas malas que hacen claro, pues lo tuyo no mola tanto...

De hecho se espia por miedo supongo y para robar y no por cosas buenas, pero algun pretexto hay que tener asi que ya de paso espiar y robar como si fuese algo de chorizos independientes y no algo generalizado?

Una buena forma sería simplemente mezclar con ruido blanco (estadísticamente neutro) tu archivo de texto. 

Se podría saber que hay algo ahí con un análisis entrópico eso sí, pero se podría descifrar?

Sería sumarle o restarle o ambos a tu texto un array de misma extensión con numeros enteros aleatorios basados en una semilla, esto es siempre que se introduzca la misma semilla la ristra de números será la misma (pseudoaleatorio).

Para marear más la perdiz el sumar o restar podría depender también de la semilla y variar según la posición en el array.

Una clave además es algo que no mola para seguridad y habría que pasarla a un hash basado en la clave semilla, implementar un generador de claves sería buena idea.

Tampoco tendría porque tener el mismo tamaño el array resultante del cifrado, pero cuánto más simple mejor que luego hay que testearlo...

Para un texto o archivo grande tendría que ir variando la clave en cada trozo en base a una clave principal de forma no periódica.

Tal vez convenga implementar tu propio algoritmo de números pseudo-aleatorios.
Y bueno claro ya que hay que ponerse con la seguridad pues tal vez programar en .net o java no sea buena idea.

Se podría crear un proceso que al detectar archivos nuevos en una carpeta simplemente los cifre...
El resultado ocuparía más que el original eso sí.

Otro día si me apetece igual me pongo y lo implemento por aquí. 

El funcionamiento sería:

  1. Introduces una clave.
  2. Se calcula el hash y se usa como semilla. 
  3. Se saca un número aleatorio menor que el tamaño del array de bytes del texto o lo que sea.
  4. Se crea un array de números aleatorios enteros mayores que 256 al menos de largo sería el número calculado antes.
  5. Se repetiría el proceso hasta sobrepasar el largo del archivo o texto etc a cifrar. Es decir se volvería al paso 2 pero modificando la clave automáticamente en base a esa clave.Se cambia la semilla.
  6. Como son números enteros y estos necesitan más de un byte se tomaría el texto como un array de enteros.
  7. Se calcularía si se suma o resta aleatoriamente cada entero de la cadena aleatoria con los enteros sacados de convertir los bytes del texto a enteros.
La semilla en verdad se puede ir cambiando todo el rato cada vez que realices una operación , si se deja podrían salir sucesiones que indicarían la semilla si se tiene calculando mucho tiempo a un ordenador por fuerza bruta, mucho mucho tiempo... 
Por ejemplo frases muy usadas podrían pre encriptar se y luego buscarse en textos cifrados , pero claro si cambia todo el rato.

Se podría analizar por frecuencia para ver si hay información pero como es un generador aleatorio propio no tendrías porque haber blanqueado el resultado para que fuera neutro pero eso tal vez daría pistas sobre el algoritmo?

Mejor cambiar de semilla cada pocos números.

Se podrían desordenar los bloques para marear más ...

El archivo queda cifrado.

Se descifra por el mismo proceso Creando el array de enteros aleatorios en base a la clave e invirtiendo la suma o resta.

Por otra parte , algo que no puedan descifrar? Con lo que les gusta el espionaje? Igual entran por la noche y se llevan tu ordenador y aú. Jajaja

 Seguramente no tengas nada tan guay que esconder.

Comentarios

Entradas populares de este blog

Audio de calidad con pocos bit

Si grabas una señal a suficiente velocidad en teoría puedes reducir la velocidad y aumentar la tasa de bits. Sería posible grabar a 12bit y tener señal de 24bit de menor frecuencia. Convertir un archivo PCM a menor tasa de bits pero mayor frecuencia permite conservar la información y si inviertes la forma de onda y los reproduces a la vez se anulan. Pienso es mas interesante para grabar audio con dispositivos de 12bit a mucha velocidad y tener señales de 16 y 24bit de audio. Por ejemplo una Wemos D1 ESP32 tiene entradas analógicas de 12bit pero con esta técnica se puede aumentar la precisión. Un experimento, se genera ruido blanco en audacity que es estadísticamente igual en todas las frecuencias, puro random, y se guarda como 24 bit 48 Khz, se recarga y se guarda como 16 bit 88 Khz. Aquí se busca emular lo que sería grabar a menos bits y reducirlo de velocidad pero aumentar la profundidad. Habrían los mismos datos entre 16 bit y 24? La forma de comprobarlo es invertir la onda de uno d...

FFT mejora mas precisión usando ruido.

Hace tiempo hice un algoritmo FFT para que corriese rápido en máquinas de poca potencia (convierte una onda en una gráfica de frecuencia e intensidad) El algoritmo típico usa senos cosenos... yo use solo sumas y restas lo que puede ser impreciso pero los senos y cosenos también ahora que lo pienso. La solución es tomar la muestra de audio y sumar y restar sus valores con ruido estadísticamente neutro pero acotado en frecuencia. Por ejemplo tomar ruido blanco, sacar la banda de 4hz multiplicar los valores de la muestra por esto. El resultado una desviación del ruido sobre lo que sería neutro pero que ya no solo es buena para ondas sinusoidales sino para todo tipo de ondas. Soy un crack ou yeah!

Ordenador DIY

Es una posibilidad estos días con el open hardware. Pienso que una plataforma simple podría no mostrar su salida en pantalla sino en una web, cosa que seguramente ya exista. Plataformas baratas como Arduino con capacidad wifi podrían recibir la entrada directamente y en lugar de dibujar una matriz de colores sacar simplemente texto html. La pantalla? Pues un móvil un ordenador etc. Podría ser similar a los ordenadores de los 80s con un lenguaje de programación tipo BASIC o C y las capacidades gráficas dependerían del móvil así como la aceleración gráfica. Podría usar recursos de red o realizar operaciones con archivos en una tarjeta SD. Usaría sus entradas y salidas... En este sentido sería un sistema operativo simple para estas plataformas. Arduino, sus clones y otros similares; son plataformas económicas que no tienen apenas consumo de energía y no se calientan. La idea sería hacerlo algo más independiente y poder ejecutar programas o cargarlos desde él mismo. El Arduino básico igual...