Empecemos al revés.
Tienes un contenido confidencial a proteger de un observador malicioso. Necesitas implementar un proceso de encriptación y otro de desencriptación.
Estos procesos requieren el contenido a encriptar o desencriptar como primer insumo. Podemos decir que el algoritmo de cifrado es su segundo insumo. Dependiendo de éste, el proceso puede requerir más insumos:
- Rot13: no necesita nada más
- AES: necesita una llave, que se usará para encriptar, desencriptar, firmar y verificar
- RSA: una llave pública (para encriptar o verificar) y una privada (para desencriptar y firmar)
- ChaCha20: una misma llave
Hay escenarios donde el intercambio de mensajes implica el uso de pares público/privado de parte de dos interlocutores para establecer una llave simétrica temporal, que es la que se usa el resto de la sesión.
Como ves, el procedimiento puede no necesitar llave, pero siempre necesita algoritmo. En el caso más simple, se trata del algoritmo: "deja la weá tal como está" o función identidad.
Segundo, dado que hablamos de encriptar grandes volumenes de datos, es simplemente impracticable hacerlo con llaves asimétricas. Tampoco tiene utilidad en este escenario donde no andas intercambiando llaves (la maneja la plataforma).
Tercero, el estándar es AES. Nadie usaría DES para encryption-at-rest hoy en día. Por ahí algún hipster podría usar algo basado en ChaCha20
Lo que queda en la incertidumbre o sujeto a configuración sería:
- Dependiendo del largo de la llave, se tratará de AES128, AES192 o AES256 (hay otros, como el famoso AES69 que te da vuelta los datos)
- Dependiendo del modo de operación será AES-128-CTR, AES-256-XTS, etc. Esto describe la técnica para trabajar la información en bloques. También se puede operar con streams en vez de bloques pero no se usa en discos.
