2010-03-23 28 views
25

Quiero usar el algoritmo de encriptación disponible en el espacio de nombres .Net Security, sin embargo estoy tratando de entender cómo generar la clave, por ejemplo, el algoritmo AES necesita 256 bits, esa clave de 16 bytes y algunos vectores de inicialización, que también son pocos bytes .Cómo crear claves de encriptación para algoritmos de encriptación?

  1. ¿Puedo usar cualquier combinación de valores en mi Key y IV? p.ej. todos los ceros en Key y IV son válidos o no? Conozco los detalles del algoritmo que hace muchos xors, por lo que cero no sirve para nada, pero ¿hay alguna restricción por estos algoritmos?

  2. O ¿Tengo que generar la clave utilizando algún programa y guardarlo permanentemente en alguna parte?

que quiere guardar los datos en la base de datos después del cifrado, los datos del perfil de seguridad como nombre de usuario, contraseña, número de teléfono, etc, y la clave estarán disponibles para el usuario de base de datos mencionada en cadena de conexión única, y para el administrador.

+0

Si desea utilizar AES256, su clave debe ser de 32 bytes y establecer KeySize property = 256. sino que usará AES 128. Puede utilizar todos los ceros, pero en el contexto de la seguridad, no tiene sentido hacerlo como no es seguro. Sí, mejor generar clave aleatoria (como en la respuesta de Michael Howard-MSFT) y almacenar de forma segura. –

Respuesta

10

Si está utilizando el cifrado para intercambiar datos, necesitará un protocolo de intercambio de claves, pero no lo haga en su lugar, use uno comercial como TLS o SSL.

Si usa cifrado para almacenar datos, genere el IV usando CryptGenRandom (o su .net equivalente RandomNumberGenerator.GetBytes) y guárdelo junto al documento (en claro, no es necesario proteger el IV). Nunca escribe la clave, la clave la proporciona el usuario. Normalmente deriva la clave de una frase de contraseña usando CryptDeriveKey, o su .Net equivalente PasswordDeriveKey.CryptDeriveKey.

actualización

Para guardar un secreto en la base de datos que está disponible sólo para el usuario y un administrador tiene que utilizar 3 teclas:

  • uno para cifrar los datos con (llamarlo la clave DK)
  • una clave de usuario para cifrar la clave DK (llámese Reino Unido)
  • una clave de administrador para cifrar la clave DK (llámese AK)

En teoría, encriptas los datos con DK y luego encriptas el DK con el Reino Unido y lo guardas, y encriptas el DK con AK y lo guardas. De esta forma, el usuario puede volver a utilizar el Reino Unido para descifrar el DK y luego descifrar los datos, y el administrador puede usar el AK para descifrar el DK y luego descifrar los datos.El gran problema es el hecho de que el sistema siempre está automatizado, por lo que el sistema necesita acceso a la clave del administrador, lo que significa que no es realmente una clave personal del administrador, sino una clave del sistema (no puede usarse para fines de no repudio por ejemplo).

Como aviso, saber qué es IV o cómo usar AES desde C# y cómo funciona el algoritmo de criptografía le proporcionará exactamente 0 (cero) tracción para resolver este tipo de problemas. El problema nunca es qué IV y qué clave usar, el problema siempre es el aprovisionamiento clave. Para las operaciones de cifrado reales, solo use el soporte integrado de la base de datos, consulte Cryptography in SQL Server. Puedo argumentar fácilmente que el único que necesita es TDE (Transparent Data Encryption) para proteger contra la pérdida accidental de medios.

+0

Quiero almacenar datos en la base de datos después del cifrado, los datos del perfil seguro como nombre de usuario, contraseña, número de teléfono etc., y la clave estará disponible para el usuario de la base de datos mencionado solo en la cadena de conexión y para el administrador. –

+0

En palabras simples, solo necesito proteger la información sensible del usuario de otros desarrolladores que acceden al servidor y copias de seguridad, aunque tienen acceso al servidor muy raramente, las copias de seguridad pueden estar en cualquier lugar pero sin clave; la parte sensible no debe ser visible en texto puro. Las contraseñas –

+0

deben ser hash (encriptación unidireccional) no encriptadas. Otros datos confidenciales pueden ser encriptados. pero encripte solo las columnas que contienen datos confidenciales, no toda la base de datos que causa consecuencias de rendimiento y gastos generales. –

7

Genera un código de letras/hex al azar en una longitud específica.

Esta función (tomado de here) devuelve una clave aleatoria en una longitud específica:

private static string CreateSalt(int size) 
{ 
    //Generate a cryptographic random number. 
    RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider(); 
    byte[] buff = new byte[size]; 
    rng.GetBytes(buff); 

    // Return a Base64 string representation of the random number. 
    return Convert.ToBase64String(buff); 
} 
1

Realmente depende de lo que ned que ver con la tecla.

Si la clave debe ser generada por la computadora (y puede tener cualquier valor aleatorio) generalmente tomo un SHA256 de un par de GUID. Esto es casi tan aleatorio como lo que obtendrás sin un generador de números aleatorios de hardware.

Puede usar claves con todos los 0, pero obviamente no será muy seguro.

+0

Así que, en resumen, puedo generar cualquier basura al azar y almacenarla para siempre, ¿vale ?, y una vez que se pierde la llave, todo vuelve a la normalidad. Seguro intentaré guardar copias en un medio secundario. –

+0

Eso es correcto. Cuanto más aleatoria es la clave, más segura es (dependiendo, por supuesto, de cuán seguro es el almacenamiento de la clave). –

6

Uso System.Security.Cryptography.RandomNumberGenerator para generar bytes aleatorios:

var rnd = new System.Security.Cryptography.RandomNumberGenerator.Create(); 
var key = new byte[50]; 
rnd.GetBytes(key); 
31

que realmente debería hacer esto de la manera correcta :)

1) Use un IV aleatorio generado de forma segura
2) Utilizar una forma segura generada al azar
clave 3) no utilice modo ECB - NUNCA

AesManaged aes = new AesManaged(); 
aes.GenerateKey(); 
aes.GenerateIV(); 

El código anterior generará correctamente y de forma segura una IV aleatoria y una clave aleatoria para usted.

+8

Una respuesta tardía porque estaba leyendo esto: crear una instancia de la clase AESManaged ya genera las claves para usted, solo lea las propiedades .Key y .IV. –

+1

Usted dice que nunca debe usar el modo ECB, y aunque estoy de acuerdo con usted, diría que hay ocasiones en que puede querer usarlo. Es muy raro, pero como por ejemplo, si quisiera implementar AES en CTR (modo contador), entonces necesitaría usar el algoritmo en modo ECB. Para el usuario ordinario, tu afirmación es absolutamente correcta y nunca recomendaría que uses el modo ECB sin entender completamente las posibles dificultades. http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation ofrece una buena recopilación de modos de cifrado de bloques. –

12

Parece que necesita leer en la clase Rfc2898DeriveBytes.

Rfc2898DeriveBytes.GetBytes(); 

Tiene un método (arriba) que le permite adaptar el tamaño de las matrices de bytes que se introducen en las propiedades .KEY y .IV en un algoritmo de cifrado simétrico, simplemente alimentando un valor int. El libro oficial MS 70-536 sugiere hacer esto pro-gramaticalmente dividiendo la propiedad KeySize/8.

I.e TripleDes o AESManaged. Sea lo que sea que uses, el algoritmo en sí tendrá algunos requisitos previos que necesitarán reunirse primero. Es decir, que satisface las condiciones de tamaño de clave. RunTime rellenará automáticamente las propiedades, los campos, etc., los mejores y más sólidos valores para usted. Pero el IV y Key deben venir de ti. Esto cómo se puede hacer lo siguiente:

RijndaelManaged myAlg = new RiRijndaelManaged(); 
byte[] salt = Encoding.ASCII.GetBytes("Some salt value"); 
Rfc2898DeriveBytes key = new Rfc2898DeriveBytes("some password", salt); 
myAlg.Key = key.GetBytes(myAlg.KeySize/8); 
myAlg.IV = key.GetBytes(myAlg.BlockSize/8); 
// myAld should now fully set-up. 

anterior se puede ver lo que quiero decir por hacerlo pro-gramatical, ya que más o menos debe hacerlo todo para usted, sin que ni siquiera tener que realmente alteró -lid en cuanto a cumplir con sus requisitos previos.

El libro Microsoft 70-536 indica que las propiedades .Key esperan que las matrices de bytes proporcionen en bytes y no en bits. La clase RFC funciona en bytes donde, como algoritmos, la propiedad KeySize funciona en bits. 1 byte = 8 bits. ¿Puedes ver a dónde va esto ...? Esto debería darle una idea de por qué la porción de código de ejemplo anterior se realiza de la manera que es. ¡Lo estudié y me parece bastante sensato!

La respuesta anterior debería permitirle crear su objeto de algoritmo con la contraseña proporcionada y un valor de sal estático que puede ser un código duro en ambos extremos. Lo único que debe hacer es preocuparse de cómo asegurarse de que las matrices de bytes almacenadas en .Key y .IV se transporten de forma segura a un destinatario para que pueda descifrar correctamente el mensaje cifrado. Al reconstruir de forma segura el mismo objeto de algoritmo.

OBTW:

AESManaged tiene un tamaño de clave req ': 128 bits = 16 Bytes !!! (8 * 8 = 64, 64 bits/8 bits por byte = 8 bytes) Por lo tanto,

64 * 2 = 128 bits, 8 * 2, ==> ¡Tamaño de la tecla de 16 bytes!

256Bit = 32Bytes !!!!


De acuerdo con el libro oficial kit de formación 70-536, Aes se limita a tener tamaño de clave de 128 bits de tamaño. 256bits, 192 y 128 key size por ejemplo se pueden usar con la clase Rijndael.


Usted podría por el contrario olvidar por completo toda esa basura y simplemente utilizar métodos .GenerateKey y GenerateIV en lugar de ahorrar todos los problemas de la clasificación de los valores de una sal estáticas contraseña y pre-compartida y acordada. Su única preocupación es descubrir una forma de almacenar y recuperar la clave y las matrices de IV byte. Formateador binario? .

Cuestiones relacionadas