+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    février 2017
    Messages
    532
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : février 2017
    Messages : 532
    Points : 17 787
    Points
    17 787

    Par défaut Controverse autour de Linux 4.17 : la dernière mouture du kernel supporte Speck

    Controverse autour de Linux 4.17 : la dernière mouture du kernel supporte Speck
    Un algorithme de chiffrement rejeté par l’ISO

    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.

    Nom : linux 4.17 .png
Affichages : 9816
Taille : 100,1 Ko

    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 - Visualiser dans une fenêtre à part
    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[] = {
     	},
     };
    « Speck pourrait ne pas être aussi sécurisé qu’AES et ne doit être utilisé qu’avec les systèmes sur lesquels AES n’est pas assez rapide », prévient une fois de plus Biggers. Tomer Ashur a critiqué cette approche en arguant que l'on ne saurait offrir une telle solution aux utilisateurs en se disant « mieux vaut celui-là que rien », mais ne dit-on pas « un tien vaut mieux que deux tu l’auras ? »

    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 732
    Points : 17 789
    Points
    17 789

    Par défaut

    Tomer Ashur a critiqué cette approche en arguant que l'on ne saurait offrir une telle solution aux utilisateurs en se disant « mieux vaut celui-là que rien »
    Sophisme de la solution parfaite ?
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

  3. #3
    I.A. en bêta-test Avatar de MikeRowSoft
    Homme Profil pro
    Sans profession
    Inscrit en
    avril 2013
    Messages
    1 755
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Sans profession

    Informations forums :
    Inscription : avril 2013
    Messages : 1 755
    Points : 555
    Points
    555

    Par défaut

    Citation Envoyé par Patrick Ruiz Voir le message
    « 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 »


    P.S. : c'est un système bipartie leur politique. Comme par hasard, politiquement, si il n'est pas avec eux il est contre eux, surtout sans en avoir fait la preuve que leur " truc " ne fonctionne pas selon les droits de la constitution des U.S.A. .

  4. #4
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2013
    Messages
    29
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : septembre 2013
    Messages : 29
    Points : 87
    Points
    87

    Par défaut

    Citation Envoyé par Neckara Voir le message
    Sophisme de la solution parfaite ?
    Attention a ne pas voir des sophismes partout, si le chiffrement est bidon autant passer sur AES256 ou twofish qui sont plus sécurisé. Effectivement on peut se dire qu'on est dans le cas du sophisme ce qui peut être potentiellement vrai, mais d'un point de vue sécurité il me parait dangereux de priorisé un chiffrement peu fiable mis en avant par la NSA quand on a des alternatives fonctionnel.

  5. #5
    Expert éminent sénior

    Avatar de Neckara
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2011
    Messages
    6 732
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : décembre 2011
    Messages : 6 732
    Points : 17 789
    Points
    17 789

    Par défaut

    Citation Envoyé par Itachiaurion Voir le message
    Attention a ne pas voir des sophismes partout, si le chiffrement est bidon autant passer sur AES256 ou twofish qui sont plus sécurisé. […] (Effectivement on peut se dire qu'on est dans le cas du sophisme ce qui peut être potentiellement vrai, mais d'un point de vue sécurité il me parait dangereux de priorisé un chiffrement peu fiable mis en avant par la NSA quand on a des alternatives fonctionnel.
    Justement de ce que je lis, ce n'est pas le cas, nous n'avons pas d'alternatives satisfaisantes pour certains type d'appareils:

    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.
    On dit "chiffrer" pas "crypter" !

    On dit "bibliothèque" pas "librairie" !

    Ma page DVP : http://neckara.developpez.com/

Discussions similaires

  1. Ubuntu : controverse autour du système d’affichage Mir
    Par Hinault Romaric dans le forum Ubuntu
    Réponses: 34
    Dernier message: 04/10/2013, 17h37
  2. Réponses: 27
    Dernier message: 15/04/2012, 11h42
  3. Réponses: 0
    Dernier message: 27/10/2009, 16h13
  4. 8.04.1 dernière mouture
    Par leman dans le forum Bubuntu
    Réponses: 4
    Dernier message: 05/07/2008, 06h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo