Dans quelle mesure AES-128-CTR nest-il pas sûr de crypter tout type de données à laide du format de fichier de keystore Ethereum?
On novembre 18, 2020 by adminJutilise le format de fichier de keystore Ethereum pour crypter toute autre donnée telle que du texte brut ou JSON.
Voici un exemple de pseudocode de limplémentation:
MY_PASSWORD = "VeryDifficultPasword432131!@!#%" MY_TEXT = "This is my secret text" iv = randomBytes(16) kdfparams = { dklen: 32, n: 262144, r: 1, p: 8, salt: randomBytes(32) } key = scrypt(MY_PASSWORD, kdfparams) ciphertext = encryptCipheriv("aes-128-ctr", MY_TEXT, key, iv) mac = sha3(key[16:32], ciphertext)
Avec ce code, je peux générer le fichier keystore qui ressemble à ceci:
{ "crypto" : { "cipher" : "aes-128-ctr", "cipherparams" : { "iv" : "83dbcc02d8ccb40e466191a123791e0e" }, "ciphertext" : "d172bf743a674da9cdad04534d56926ef8358534d458fffccd4e6ad2fbde479c", "kdf" : "scrypt", "kdfparams" : { "dklen" : 32, "n" : 262144, "r" : 1, "p" : 8, "salt" : "ab0c7876052600dd703518d6fc3fe8984592145b591fc8fb5c6d43190334ba19" }, "mac": "102aedfe8c308c735a76295f9908d9b7de40fb1c07f2f71e05de7a0b2f323a12" } }
Cest le fichier standard qui stocke des millions de dollars de personnes dans Ethers.
Questions:
- Est-ce sécurisé?
- Si non, pourquoi?
- Si oui, est-ce que le cryptage sécurisé en texte brut ou JSON (pas de format hexadécimal)?
- Est-il sûr de définir un
kdfparams.n
?
Edit: Pour clarifier pourquoi je « demande ceci, cest parce quune autre personne a dit ceci:
Ce nest pas du tout sécurisé. Cette implémentation contient de nombreuses erreurs de base. Un exemple est lutilisation dun générateur de nombres aléatoires non sécurisé, qui détruit complètement la sécurité du cryptage. Un autre utilise AES- 128 CTR sans authentification.
Commentaires
- Tout dabord, définissez » secure » . Mais selon toute définition raisonnable de cela, avec un mot de passe dans la même ligue que ‘ 1234 ‘, et un texte en clair si volumineux et redondant, rien d’utilisable n’est sécurisé.
- Sécurisé en termes de très très difficile à casser même si un bon cryptographe. L et moi modifiez pour clarifier que ce serait un mot de passe très fort.
- Maintenant, définissez » break » . Est-ce trouver le mot de passe dorigine? Deviner le texte en clair à partir dun texte chiffré? Deviner une partie du texte en clair de beaucoup de partage de texte chiffré que certains? Deviner un texte en clair à partir de plusieurs textes chiffrés et de tous les autres textes en clair? Pouvons-nous obtenir de laide dun exécutable fonctionnant sur la même machine (et si oui, quel processeur exactement avec quel patch de microcode? AES-NI est-il utilisé?). Pouvons-nous utiliser EMI comme canal secondaire? Un keylogger, hardware ou sotfare? En effet, quelle ‘ est limplémentation de randomBytes, qui a une influence?
- Vous ne pouvez pas répondre à cette question en regardant psuedocode. La mise en œuvre réelle peut contenir toutes sortes de vulnérabilités et de canaux secondaires . La sécurité n’est pas non plus un binaire, ‘ dépend de la mesure dans laquelle vous ‘ êtes prêt à aller pour vous protéger contre toujours plus de attaques exotiques .
- @ fgrieu désolé, la seule question à laquelle je peux répondre est: nodejs.org / api / … @EllaRose Je suppose que les bibliothèques que jutilise nont pas de vulnérabilités. Donc mon pseudocode ci-dessus est juste une implémentation de ces fonctions de bibliothèques, par exemple randomBytes.
Answer
Le pire la faiblesse purement cryptographique est le mot de passe (1). Les pires (et bien pires) faiblesses pratiques sont probablement dans la mise en œuvre (6) (7), et celles (4) (5) que les cryptographes rejettent comme étant hors du champ du cryptage (le seul objectif déclaré de la question).
Candidats aux faiblesses, de la cryptographie (mais encore à considérer) à limplémentation:
- Le mot de passe: il est difficile de se souvenir dun mot de passe avec plus de 48 bits dentropie ( cest à peu près équivalent à un nombre à 16 chiffres, comme 3141592653589793 ou 2718281828459045, et plus que ce que prévoit le XKCD obligatoire). En utilisant N = 262144 = 2 18 , r = 1, p = 8 = 2 3 , achète au moins 18 + 3 + 1 = 22 bits (voir this ) par rapport à un hachage SHA-256 simple suivi par AES-128, je suppose environ 32 bits plus fort, donc la clé pourrait être denviron 80 bits, ce qui est pas entièrement incassable par la force brute mais toujours assez sécurisé.
- AES-128: il a une clé de 128 bits, pas de purement cryptanalytique connu attaque mieux que la force brute, et est donc bien meilleur que le mot de passe.
- Mode CTR: avec le bloc de 128 bits d’AES, la seule façon dont la réutilisation du flux de clés pourrait démarrer serait un mauvais nombre aléatoire générateur pour lIV (voir 6)
- La taille du texte en clair peut être déduite sans effort de la taille du texte chiffré. Ceci nest explicitement pas une faiblesse théorique du chiffrement, car la longueur est exclu de ce quun chiffrement est censé cacher à propos du texte en clair. Cependant, cela peut être une faiblesse pratique. Supposons que lanalyse du texte chiffré conclut quil est 17267095423 octets; et il existe, quelque part dans les pièces de laccusation, un dossier avec exactement cette taille, qui est manifestement antérieur à la fouille et à la saisie du texte chiffré, et dont la simple détention est illégale.
- Absence de détection daltérations (intentionnelles ou accidentelles) du texte chiffré, correspondant à une altération prévisible du texte en clair: encore une fois, ce nest explicitement pas une faiblesse théorique du chiffrement, mais peut permettre certaines attaques si ladversaire peut modifier le texte chiffré (exemple: si le texte en clair est un exécutable ou un PDF avec une fraction connue, cela peut permettre de changer ce que fait lexécutable à propos de nimporte quoi, ou de faire afficher le PDF comme à propos de nimporte quoi). Le chiffrement authentifié ( AES-GCM ..) résout cela.
- Générateur de nombres aléatoires: si cest mauvais, ou pire devient plus ou moins bloqué (obligatoire XKCD et Dilbert qui se transforment trop souvent en réalité), cela permettrait de récupérer du texte en clair dans de nombreux scénarios, y compris le chiffrement répété de différents textes ou adresses e-mail anglais avec le même mot de passe.
- Un canal secondaire, cest-à-dire au sens large parler dune fuite dinformations imprévue ou non atténuée dans le contexte de mise en œuvre ou dutilisation. Il y en a tellement:
- Récupération du mot de passe du détenteur du mot de passe en exploitant une erreur procédurale (mot de passe sur une note de postit, liste de mots de passe principale), cryptanalyse en caoutchouc (obligatoire XKCD ), variantes juridiques (impliquant lutilisation dexpressions sur lair de l outrage au tribunal ), corruption, imprégnation chimique ..
- Récupération du mot de passe par surf sur lépaule , enregistreur de frappe (logiciel ou matériel), caméra, microphone (une bonne capture audio de le son des touches lors de la saisie dun mot de passe fuit beaucoup dinformations sur le mot de passe, en particulier lorsquil est corrélé à une saisie au clavier connue par le même opérateur dans les mêmes conditions).
- Compromis direct du texte en clair comme indiqué à lécran (avec TEMPEST variantes de celui-ci), imprimées, transmises à une imprimante ou accessibles à distance par un réseau, ou simplement stockées « temporairement » ..
- Compromis direct de lOS du mach en faisant du cryptage ou du décryptage (obtenir un accès root temporaire suffit, cela signifie quen 7.7 sont un jeu pour lattaquant).
- Canal latéral cryptanalytique à distance, y compris DPA et la variante électromagnétique DEMA, et hypothétiquement timing si la machine effectuant le chiffrement / déchiffrement est accédée par un réseau et nutilise pas Instructions AES .
- Canal côté cryptanalytique dun processus sexécutant sur le même matériel (y compris une autre VM), y compris le ciblage basé sur le cache pour AES lorsque vous nutilisez pas AES instructions, ou plus générales (Meltdown, Spectre) qui font fureur ces jours-ci.
- Exploitation de divers bogues logiciels; cest énorme.
Commentaires
- Ce serait plus utile si je hachais le mot de passe avant le cryptage? Comme utiliser sha ou md5?
key = scrypt(sha(MY_PASSWORD), kdfparams)
- @EnZo: Le hachage du mot de passe avant la saisie en scrypt ne change pas grand-chose à la difficulté dattaque du mot de passe ( point 1). Pour améliorer cela, il faut un meilleur mot de passe, un meilleur paramétrage pour scrypt, ou un meilleur schéma de dérivation de clé basé sur un mot de passe (Argon? Balloon?)
Réponse
Le principal élément de sécurité qui peut être attaqué dans le schéma ci-dessus est – bien sûr – la phrase de passe. Maintenant, le sel est important pour éviter les attaques de table arc-en-ciel, mais sinon il najoute pas autant de sécurité. Si le sel et le mot de passe sont raisonnablement uniques, la clé est également unique. Dans ce cas, lIV nest pas que important.
Donc, bien que lutilisation dun générateur de nombres aléatoires non sécurisé soit mauvaise, elle naura probablement pas beaucoup dinfluence sur la sécurité pratique. , cela indique que de mauvaises pratiques ont effectivement été déployées. Que se passe-t-il si la phrase secrète a été générée à laide du même générateur aléatoire non sécurisé? Que faire si dautres erreurs dimplémentation surviennent?
Lutilisation dun texte chiffré non authentifié pose davantage problème, car cela permettrait à ladversaire de changer le texte en clair pour chaque bit. Ladversaire peut simplement inverser nimporte quel bit de texte chiffré et le bit en clair à la même position basculera également. Cela signifierait que vous obtiendriez une erreur ou un problème lors de lutilisation du portefeuille. La confidentialité du contenu du portefeuille nest probablement pas perdue, mais lutilisation dun cryptage authentifié est certainement la meilleure pratique.
Commentaires
- Merci! Pourriez-vous expliquer à peine comment obtenir un texte chiffré authentifié avec ce mode? Je vais éditer e Les exemples ci-dessus parce que je pense que cest lié à la propriété mac dorigine que jai supprimée du fichier de keystore dorigine.
- Le mode CTR est le mode sous-jacent de CCM, GCM, EAX, SIV et tout un tas dautres authentifiés chiffrements. Cependant, une combinaison du mode CTR avec un (H) MAC peut certainement aussi être sécurisée.Les deux produisent une étiquette dauthentification avec à peu près la même taille / sécurité. CCM et EAX ne sont guère plus que des combinaisons spécifiques de CTR et de MAC où la même clé peut être utilisée pour le chiffrement et le MAC.
- Notez que je ‘ ve a répondu à cette question au mieux de mes capacités, en utilisant une connaissance générique des chiffrements (pas tellement Ethereum). Ella Rose a raison de dire que nous ne pouvons pas conclure à la sécurité du système à partir des informations qui nous sont fournies dans la question. Donc je ‘ me suis concentré uniquement sur lutilisation du CTR.
- Eh bien, le hasard semble reposer – en fin de compte – sur le système aléatoire. Souvent, les sources aléatoires du système sont relativement sûres et le terme CSPRNG est en effet mentionné par la source. Donc, laffirmation selon laquelle ce nest pas aléatoire est fausse, à moins que le système aléatoire ne soit pas bien implémenté ou prédéfini.
- La création directe dun MAC à partir de SHA-3 nest pas recommandée, KMAC aurait dû être utilisé à la place (il simplement ‘ t spécifié à l’époque). Mais je ne peux penser à aucune situation où lutilisation sur la concaténation de la clé et du texte chiffré poserait un problème.
Laisser un commentaire