Desde siempre soy un gran aficionado a la criptografía, y en mi opinión Whitfield Diffie se merece el premio Nobel de matemáticas por su contribución a la humanidad 🙂

El caso es que en .NET hay un gran soporte criptográfico, tanto en código manejado, como haciendo uso de la API de criptografía del sistema operativo. Sobre todo en .NET 2.0, porque en .NET 1.x había bastantes carencias en cuanto al manejo de algoritmos de clave pública basados en certificados (lo sufrí enun proyecto a base de bien).

En .NET 3.5, o la versión de la plataforma que saldrá conorcas dentro de unos meses, el soporte de criptografía se ha mejorado mucho. En concreto se han centrado en ofrecer todos los algoritmos conocidos como Suite B, de la NSA.

Esta suite contempla una serie de algoritmos avanzados de seguridad exigidos por el Estado USA e implica ofrecer soporte para AES, SHA-256 y SHA-384 (ya los ofrecía) y una serie de algoritmos criptográficos de curvas elípticas que se han tenido que incorporar (ECDH (Elliptic Curve Diffie-Hellman) para intercambio de claves y ECDSA (Elliptic Curve Digital Signature Algorithm) para firma digital, ambos con curvas de módulos de 256 y 384 bits.).

la criptografía elíptica es similar a la de clave pública tradicional como RSA (algoritmos asimétricos) pero es más eficiente y segura que ésta. Por ejemplo, la NSA recomienda usar claves de 15.360 bits para proteger una clave simétrica de 256 bits con RSA, mientras que la longitud de clave recomendada si usamos un algoritmo elíptico es de 512 bits.

Además de esto el equipo de .NET ha querido soportar implementaciones de estos algoritmos certificadas por el FIPS (Federal Information Processing Standard). Por ejemplo, las implementaciones de SHA de las anteriores versiones no estaban certificadas por FIPS y las nuevas sí lo estarán.

Ello nos ayudará a crear aplicaciones de seguridad mucho más confiables y, en el hipotético caso de que llegásemos a trabajar para organismos oficiales, no tendríamos problema para certificar nuestra aplicación.

Algunas implementaciones de los algoritmos sacan apartido a una nueva API que está presente por primera vez en Windows vista, llamada CNG (Crypto Next Generation). Pos este motivo algunas implementaciones de algoritmos están atadas a determinados sistemas operativos. En concreto todas las nuevas clases de criptografía cuyo nombre termine en ‘Cng’ usan la APi de Windows Vista y necesitan ese sistema o uno superior (Windows Server 2008 de momento) para poder funcionar. Por ejemplo ECDsaCng.

Esta pregunta ha surgido en uno de los cursos de campusMVP que imparto y me ha parecido interesante comentarla aquí.

Resulta que un alumno tenía un ejecutable que, entre otras cosas, necesitaba escribir una serie de registros en un inofensivo archivo de texto. Al ejecutar la aplicación en local todo iba perfectamente, pero al hacerlo cuando el .exe estaba en una unidad de red compartida o en una carpeta remota el programa, lógicamente, le rompía con un error de falta de permisos.

El motivo de que no funcione el código en estas circunstancias es que, al ejecutarlo desde la Red, el ejecutable cae bajo el conjunto de permisos «LocalIntranet» que es mucho más recortado que el conjunto normal que se aplica a los ejecutables .NET y que se llama «FullTrust».

Lo primero que se debería hacer es declarar los permisos que el código necesita para que al menos el runtime pueda saber qué necesita esos permisos antes de «petar», nada más intentar ejecutarla. De este modo si se ejeucta sin los permisos suficientes advierte antes de ello y no se limita a romper cuando la aplicación vaya a escribir a disco. Eso se consigue con este atributo aplicado al ensamblado:

<Assembly:FileIOPermission(SecurityAction.RequestMinimun, Unrestricted:=True)>