[C/C++] BruteForce

[k-otik]

b0fh a très bien répondu .

Le problème est que, en comparant des strings, le temps de comparaison est proportionnel au nombre de mots communs en début de la chaine. Donc plutôt que de devoir bruteforcer un hash complet, il peut essayer plusieurs h ayant des débuts différents, mesurer le temps de réponse du serveur, et garder le plus long; et ainsi reconstruire hash en temps linéaire plutôt qu'exponentiel.

Pour éviter ça, il faut t'assurer que le temps de comparaison ne dépende pas de tes données. Et donc pas de break/continue, qui changent le nombre d'itérations de tes boucles.

C'est une type de side-channel attack que je trouve très élégant. Avec des applications diverses si on élargit l'éventail au-delà de l'attaque de serveur de distribution de clé.

Permet de vérifier rapidement la présence d'él'ements divers dans des bases de données (nom d'utilisateur, champs de table etc..). Des délais de quelques microsecondes sont facilement décelables statitisquement au milieu du bruit (fluctuations poisonniennes liées au changement de contexts du thread, le pigeon sur le fil qui modifie la dispersion du signal etc) si l'algorithme de comparaison des données du client et du serveur n'est pas constant dans le temps.

En effet,

Code :

==

est très anodin mais ceci cache une comparaison octect par octect dont le temps d'exécution croit avec l'exactitude des premiers octets comparés comme :

Code :

for(int i = 0; i <client_input_data_len; i++)
    if(client_input_data[i] != server_test_data[i]) return false;

Ici la comparaison est linéaire, tout dépend de l'algorithme. Mais en restant évasif, quelqu'un pourrait comprendre qu'en "bruteforcant" avec des entrées qui ont par exemple des distances de Levenshtein différentes à la valeur comparée, on peut mesurer en MOYENNE des écarts systématiques dans les délais de réponse du serveur.

Le sujet est riche, en passant par le champ time-stamps du protocol TCP/IP, à d'autres protocoles modernes. En gros, tout traitement de données client-serveur qui n'est pas invariant dans le temps est intéressant

Je pourrais partager l'idée peut-être qu'il existerait des banques qui utiliseraient des dispositifs QKD (quantum key distribution) pour la cryptographie et l'échange de données sur quelques kilomètres reposant sur l'intrication EPR entre des modes comprimés de la lumière. La création de clés a usage unique (non composites) étant le résultat de plusieurs mesures effectuées sur l'une des deux quadratures de la lumière (phase ou amplitude). Si vous êtes encore entrain de lire , le choix de la mesure de la phase ou de l'amplitude se faisant aléatoirement avec un phase-shifter de 90 degree, un attaquant pourrait reconstituer la séquence de mesures (phase amplitude amplitude phase phase etc..) car la bande passante des phase-shifter telecom est faible (cela prend un certain temps de passer d'une quadrature à une autre) .. enfin bref gruik j'espère que tu te portes garant pour le blabla que je pourrai raconter