Lorsque Canonical a annoncé le lancement de la collecte des données sur les systèmes des utilisateurs d’Ubuntu au mois de février, la communauté a accouru pour voir de quoi il retourne effectivement. Même si l’entreprise a fait preuve de transparence en donnant le détail sur la nature des données collectées, la polémique sur les possibles usages n’avait pas manqué de faire surface. C’est un fait, dans la communauté on est très pointilleux et les dernières nouvelles liées à Linux 4.17 risquent de renforcer cette posture.Linus Torvalds a annoncé la disponibilité de la dernière version du kernel il y a peu. Depuis les développements relatifs à la RC1, les axes importants en termes d’améliorations sont connus : réduction d’au moins 10 % de la consommation en mode idle de certains systèmes, arrivée de l’architecture Andes 32 utilisée par les appareils médicaux, portables, connectés et autres nécessitant une faible puissance, prise en charge par défaut des processeurs Cannonlake par le pilote DRM, etc. Grâce à un courriel paru sur la liste de diffusion Linux au mois d’avril 2018, il y a un détail supplémentaire à prendre en compte : un algorithme de chiffrement dénommé Speck fait partie des ajouts à la version 4.17 du noyau.
Très rapidement, ce qu’il faut noter à propos de cet algorithme de chiffrement, c’est qu’il vient d’être rejeté par l’Organisation internationale de normalisation (ISO). L’adoption de l’algorithme de chiffrement proposé par la NSA a connu deux reports entre 2014 et 2016, puis un troisième en 2017. D’après de précédents développements, le curriculum vitae plutôt « chargé » (en matière de surveillance électronique) de l’organisme gouvernemental du département de la Défense des États-Unis contribue à plomber ses efforts. Reuters a en effet rapporté avoir eu copie des échanges par courriels des experts en cryptographie qui ont pris part au processus d’approbation. D’après ces derniers, la NSA fait la promotion de Speck auprès d’ISO non parce qu’il s’agit d’outils de chiffrement de qualité, mais parce qu’elle sait comment les casser.
Un autre mail paru sur la lkml au début de ce mois vient éclairer la position des experts. Tomer Ashur – chercheur en cryptographie et membre de la commission ISO qui a statué sur le cas Speck – a livré certaines des raisons qui ont conduit au rejet de cet algorithme. « Je voudrais d’entrée de jeu rappeler que la NSA a fait un énorme boulot pour remplir les eaux de boue en argumentant que Simon & Speck sont sécurisés et que toutes les objections sont politiques. Ce n’est pas vrai et je m’en vais le démontrer à l’aide d’exemples. Le fait est que beaucoup de questions liées à la sécurité de ces algorithmes sont en suspens et la NSA a refusé d’y apporter des réponses à plusieurs reprises », a-t-il écrit. De façon brossée, le chercheur en sécurité a, par exemple, relevé que la documentation de la NSA n’est pas claire sur le choix du nombre de tours. En sus, il y a que même avec le nombre de tours indiqué par l’Agence, les marges de sécurité réévaluées sont plus faibles que celles avancées par cette dernière. Enfin, il y a pire : Tomer Ashur est connu comme celui qui a cassé Speck ; le chercheur dit avoir publié une preuve de concept.
Que fait donc un algorithme aussi controversé au sein du kernel Linux ?
L’intervention de Tomer Ashur au sein de la lkml fait suite à celle d’Eric Biggers de Google, l'auteur du commit controversé au sein du kernel Linux. Biggers est pour sa part d’avis qu’au-delà de la polémique sur les origines de Speck, il s’agit de l’algorithme de chiffrement le plus abouti dans la catégorie des versions légères destinées à tourner sur des appareils sevrés d’instructions de prise en charge du chiffrement AES (les dispositifs mobiles bas de gamme équipés de processeurs ARMv7, etc.). « Actuellement, ces dispositifs ne bénéficient pas de chiffrement parce qu’AES n’est pas assez rapide, ce, même dans le cas de la mise en œuvre de la version pour processeur dotés du support de NEON », a-t-il écrit.
En février 2018, Biggers a proposé une implémentation générique de l’algorithme de chiffrement Speck en version légère sur 5 variantes (pour un total de dix dans la famille). Il s’agissait d’un correctif de la proposition originale (faite en décembre 2017) qui portait sur l’algorithme de chiffrement ChaCha20. Le commit a été approuvé par Herbert Xu, un des mainteneurs du sous-système de chiffrement de Linux.
| Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 | +// SPDX-License-Identifier: GPL-2.0
+#include <asm/unaligned.h>
+#include <linux/bitops.h>
+#include <linux/crypto.h>
+#include <linux/init.h>
+#include <linux/module.h>
+
+/* Speck128 */
+
+#define SPECK128_BLOCK_SIZE 16
+
+#define SPECK128_128_KEY_SIZE 16
+#define SPECK128_128_NROUNDS 32
+
+#define SPECK128_192_KEY_SIZE 24
+#define SPECK128_192_NROUNDS 33
+
+#define SPECK128_256_KEY_SIZE 32
+#define SPECK128_256_NROUNDS 34
+
+struct speck128_tfm_ctx {
+ u64 round_keys[SPECK128_256_NROUNDS];
+ int nrounds;
+};
+
+static __always_inline void speck128_round(u64 *x, u64 *y, u64 k)
+{
+ *x = ror64(*x, 8);
+ *x += *y;
+ *x ^= k;
+ *y = rol64(*y, 3);
+ *y ^= *x;
+}
+
+static __always_inline void speck128_unround(u64 *x, u64 *y, u64 k)
+{
+ *y ^= *x;
+ *y = ror64(*y, 3);
+ *x ^= k;
+ *x -= *y;
+ *x = rol64(*x, 8);
+}
+
+static void speck128_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck128_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u64 y = get_unaligned_le64(in);
+ u64 x = get_unaligned_le64(in + 8);
+ int i;
+
+ for (i = 0; i < ctx->nrounds; i++)
+ speck128_round(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le64(y, out);
+ put_unaligned_le64(x, out + 8);
+}
+
+static void speck128_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck128_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u64 y = get_unaligned_le64(in);
+ u64 x = get_unaligned_le64(in + 8);
+ int i;
+
+ for (i = ctx->nrounds - 1; i >= 0; i--)
+ speck128_unround(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le64(y, out);
+ put_unaligned_le64(x, out + 8);
+}
+
+static int speck128_setkey(struct crypto_tfm *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct speck128_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u64 l[3];
+ u64 k;
+ int i;
+
+ switch (keylen) {
+ case SPECK128_128_KEY_SIZE:
+ k = get_unaligned_le64(key);
+ l[0] = get_unaligned_le64(key + 8);
+ ctx->nrounds = SPECK128_128_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck128_round(&l[0], &k, i);
+ }
+ break;
+ case SPECK128_192_KEY_SIZE:
+ k = get_unaligned_le64(key);
+ l[0] = get_unaligned_le64(key + 8);
+ l[1] = get_unaligned_le64(key + 16);
+ ctx->nrounds = SPECK128_192_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck128_round(&l[i % 2], &k, i);
+ }
+ break;
+ case SPECK128_256_KEY_SIZE:
+ k = get_unaligned_le64(key);
+ l[0] = get_unaligned_le64(key + 8);
+ l[1] = get_unaligned_le64(key + 16);
+ l[2] = get_unaligned_le64(key + 24);
+ ctx->nrounds = SPECK128_256_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck128_round(&l[i % 3], &k, i);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* Speck64 */
+
+#define SPECK64_BLOCK_SIZE 8
+
+#define SPECK64_96_KEY_SIZE 12
+#define SPECK64_96_NROUNDS 26
+
+#define SPECK64_128_KEY_SIZE 16
+#define SPECK64_128_NROUNDS 27
+
+struct speck64_tfm_ctx {
+ u32 round_keys[SPECK64_128_NROUNDS];
+ int nrounds;
+};
+
+static __always_inline void speck64_round(u32 *x, u32 *y, u32 k)
+{
+ *x = ror32(*x, 8);
+ *x += *y;
+ *x ^= k;
+ *y = rol32(*y, 3);
+ *y ^= *x;
+}
+
+static __always_inline void speck64_unround(u32 *x, u32 *y, u32 k)
+{
+ *y ^= *x;
+ *y = ror32(*y, 3);
+ *x ^= k;
+ *x -= *y;
+ *x = rol32(*x, 8);
+}
+
+static void speck64_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck64_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 y = get_unaligned_le32(in);
+ u32 x = get_unaligned_le32(in + 4);
+ int i;
+
+ for (i = 0; i < ctx->nrounds; i++)
+ speck64_round(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le32(y, out);
+ put_unaligned_le32(x, out + 4);
+}
+
+static void speck64_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
+{
+ const struct speck64_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 y = get_unaligned_le32(in);
+ u32 x = get_unaligned_le32(in + 4);
+ int i;
+
+ for (i = ctx->nrounds - 1; i >= 0; i--)
+ speck64_unround(&x, &y, ctx->round_keys[i]);
+
+ put_unaligned_le32(y, out);
+ put_unaligned_le32(x, out + 4);
+}
+
+static int speck64_setkey(struct crypto_tfm *tfm, const u8 *key,
+ unsigned int keylen)
+{
+ struct speck64_tfm_ctx *ctx = crypto_tfm_ctx(tfm);
+ u32 l[3];
+ u32 k;
+ int i;
+
+ switch (keylen) {
+ case SPECK64_96_KEY_SIZE:
+ k = get_unaligned_le32(key);
+ l[0] = get_unaligned_le32(key + 4);
+ l[1] = get_unaligned_le32(key + 8);
+ ctx->nrounds = SPECK64_96_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck64_round(&l[i % 2], &k, i);
+ }
+ break;
+ case SPECK64_128_KEY_SIZE:
+ k = get_unaligned_le32(key);
+ l[0] = get_unaligned_le32(key + 4);
+ l[1] = get_unaligned_le32(key + 8);
+ l[2] = get_unaligned_le32(key + 12);
+ ctx->nrounds = SPECK64_128_NROUNDS;
+ for (i = 0; i < ctx->nrounds; i++) {
+ ctx->round_keys[i] = k;
+ speck64_round(&l[i % 3], &k, i);
+ }
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+/* Algorithm definitions */
+
+static struct crypto_alg speck_algs[] = {
+ {
+ .cra_name = "speck128",
+ .cra_driver_name = "speck128-generic",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
+ .cra_blocksize = SPECK128_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct speck128_tfm_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_u = {
+ .cipher = {
+ .cia_min_keysize = SPECK128_128_KEY_SIZE,
+ .cia_max_keysize = SPECK128_256_KEY_SIZE,
+ .cia_setkey = speck128_setkey,
+ .cia_encrypt = speck128_encrypt,
+ .cia_decrypt = speck128_decrypt
+ }
+ }
+ }, {
+ .cra_name = "speck64",
+ .cra_driver_name = "speck64-generic",
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_CIPHER,
+ .cra_blocksize = SPECK64_BLOCK_SIZE,
+ .cra_ctxsize = sizeof(struct speck64_tfm_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_u = {
+ .cipher = {
+ .cia_min_keysize = SPECK64_96_KEY_SIZE,
+ .cia_max_keysize = SPECK64_128_KEY_SIZE,
+ .cia_setkey = speck64_setkey,
+ .cia_encrypt = speck64_encrypt,
+ .cia_decrypt = speck64_decrypt
+ }
+ }
+ }
+};
+
+static int __init speck_module_init(void)
+{
+ return crypto_register_algs(speck_algs, ARRAY_SIZE(speck_algs));
+}
+
+static void __exit speck_module_exit(void)
+{
+ crypto_unregister_algs(speck_algs, ARRAY_SIZE(speck_algs));
+}
+
+module_init(speck_module_init);
+module_exit(speck_module_exit);
+
+MODULE_DESCRIPTION("Speck block cipher (generic)");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Eric Biggers <ebiggers@google.com>");
+MODULE_ALIAS_CRYPTO("speck128");
+MODULE_ALIAS_CRYPTO("speck128-generic");
+MODULE_ALIAS_CRYPTO("speck64");
+MODULE_ALIAS_CRYPTO("speck64-generic");
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index d5e23a1..058ed5e 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3001,6 +3001,24 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "ecb(speck128)",
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = {
+ .enc = __VECS(speck128_enc_tv_template),
+ .dec = __VECS(speck128_dec_tv_template)
+ }
+ }
+ }, {
+ .alg = "ecb(speck64)",
+ .test = alg_test_skcipher,
+ .suite = {
+ .cipher = {
+ .enc = __VECS(speck64_enc_tv_template),
+ .dec = __VECS(speck64_dec_tv_template)
+ }
+ }
+ }, {
.alg = "ecb(tea)",
.test = alg_test_skcipher,
.suite = {
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 69fb51e..6b15a8a 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -14323,6 +14323,134 @@ static const struct cipher_testvec serpent_xts_dec_tv_template[] = {
},
}; |
Sources : commit Biggers, lkml, Tomer Ashur
Et vous ?
Quel commentaire faites-vous de l’approbation de ce commit ? Avez-vous jeté un oeil au code source ? Si oui, la solution proposée vous satisfait-elle ? Expliquer Quelles dispositions comptez-vous prendre lorsque viendra l'heure de faire usage de cette version du noyau Linux ?Voir aussi :
WindsorGreen : les plans de la NSA pour casser les chiffrements auraient été découverts en libre accès sur Internet, par un chercheur en sécurité Chiffrement : trop improbable la possibilité de l'existence de backdoors dans AES et autres ? Les travaux d'un chercheur tirent la sonnette d'alarme Un algorithme de chiffrement inspiré de la fonction cardio-respiratoire sort, il serait incassable via une attaque par force brute Le protocole HTTPS en danger ? L'algorithme RCA qu'il utilise pour le chiffrement cassé par des chercheurs pour SSL/TLS Des chercheurs trouvent une faille dans l'algorithme RSA utilisé pour chiffrer les échanges en ligne 
Envoyé par Neckara
