GostCrypt

Le projet GostCrypt a débuté fin 2013 en tant que fork de TrueCrypt. Les révélations de Snowden ont démontré que l'usage systématique du chiffrement devient plus que jamais une impérieuse nécessité. Cela n'est possible que s'il existe une offre variée et riche de solutions open source de type TrueCrypt, et ce avec le soutien actif de la communauté du hacking et des développeurs. A cette époque, nous n'imaginions pas le choc et le bouleversement sans précédent provoqué par l'arrêt subit du projet TrueCrypt. Plus que jamais, cela montre que de nombreux autres projets doivent prendre le relais. Le projet Gostcrypt est donc un projet parmi d'autres, aussi nombreux que possible nous l'espérons. La variété et la richesse d'offres en matière de solutions de chiffrement ouvertes est LA solution.

Avec le projet GostCrypt, nous souhaitons aller encore plus loin : depuis la fin des années 70s, la plupart des algorithmes (pour ne pas dire tous) sont d'inspiration UKUSA, et par conséquent ont été choisis, favorisés, imposés et standardisés sous le contrôle des USA. Il est plus que probable (a minima le principe de précaution doit s'appliquer), que parmi les différents niveaux et mécanismes de contrôle, figurent sinon des trappes ou backdoors mathématiques su moins des faiblesses identifiées mais non révélées par les organismes pilotant techniquement les choix (essentiellement la NSA en liaison avec le NIST et éventuellement les organismes de standardization, le cas récent du Dual_EC_DRBG, révélé par Snowden est illustratif). Il est acceptable de penser que ni Vincent Rijmen ni Joan Daemen n'ont intentionnellement mis des backdoors mathématiques dans l'algorithme Rijndael. Mais il est probable que le choix de cet algorithme (par la NSA et le NIST) a pu reposer sur l'existence de faiblesses insoupconnées (dont l'existence, pour certaines, a été admise par V. Rijmen et J. Daemen dans leur livre [The Design of Rijndael, Chap. 9, page 124, paragraphe 2]) mais identifiées par les prescripteurs techniques du concours AES. . Nous avons donc décidé d'utiliser des systèmes de chiffrement forts (pour autant qu'il est possible d'en avoir la certitude et malgré quelques articles récents prétendant le contraire et qui ont été encore récemment réfutés, par exemple [Babenko & Maro, 2014] car non rigoureux, sans algorithme clair et donc non reproductibles/vérifiables). Nous voulions en outre des algorithmes qui ne soient pas non plus invasifs et hégémoniques comme cela est le cas avec les algorithmes de chiffrement de type UKUSA (et en particulier l'AES) actuellement. Les algorithmes Gost (chiffrement et fonctions de hachage) n'ont pas envahi tous nos systèmes et ont été conçus par les russes pour les russes. Outre que ce sont des systèmes fournissant un haut niveau de sécurité, (lorsque correctement implémentés et pourvus d'une gestion de clefs adéquate) cette situation de non-hégémonie est un point clef. Les algorithmes Gost n'ont jamais cherché à s'imposer à quiquonque ou à devenir un standard hégémonique. Il a même été rejeté du processus de standardisation ISO en 2012 du fait d'allégations non reproductibles et irréalistes de soi-disant faiblesse.

Quelles que puissent être les qualités et caractéristiques d'un projet de technologie de sécurité, ce dernier ne peut être valide que s'il repose sur la confiance. Cette dernière n'est possible qu'avec l'ouverture du code source et surtout du fait d'un soutien actif et constructif de la communauté des hackers et des développeurs, s'agissant des aspects sécurité liés à l'implémentation, par des commentaires, une remontée constante de bugs, des suggestions et contributions au projet. Aussi bienvenue à toutes les bonnes volontés.

Le nouvel algorithme Grasshopper (GOST Kuznyechik) a été implémenté dans GostCrypt. Pour tous les détails techniques, vous pouvez vous référer à la documentation officielle ici

Choix de sécurité

L'algorithme de chiffrement par blocs GOST 28147-89 utilise une clef de 256 bits. En interne, cette clef est divisée en sous-clefs de 32 bits. Lors du processus de mise à la clef, la S-Box interne est modifiée à l'aide de ces sous-clefs, apportant un premier degré de diversification de l'algorithme par l'utilisateur (et donc une résistance accrue face aux attaques connues qui supposent un algorithme fixe).

Pour cela, le paramètre S-box 'GOST R 34.11-94 CryptoProParamSet' du RFC 4357 est utilisé comme S-Box initiale. La clef secrète de 256 bits est d'abord hachée à l'aide de la fonction de hachage GOST R 34.11-2012, laquelle produit une valeur de 512 bits. Comme la S-Box initiale et cette valeur sont de la même taille (512 bits), on opère une addition bit à bit modulo 2 sur les entrées de 4 bits de la S-Box (voir le schéma ci-après). La S-Box résultante, laquelle est donc clef-dépendante, est utilisée pour le chiffrement et le déchiffrement. Durant les opérations de chiffrement/déchiffrement, GOST 28147-89 est utilisé en mode XTS. L'identifiant d'unité de donnée (un offset disque dans le mode XTS) est combiné bit à bit modulo 2, avec la clef GOST 28147-89. Cela assure que la clef réelle (clef initiale et marquant de données) est différente pour chaque section de 512 octets du disque, assurant ainsi une résistance contre toutes les attaques connues, lesquelles nécessitent de grands volumes de données produites avec la même clef.