IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Algorithmes et structures de données Discussion :

[Cryptographie] Questions sur chiffrement XOR


Sujet :

Algorithmes et structures de données

  1. #1
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut [Cryptographie] Questions sur chiffrement XOR
    Bonjour,

    pour faire un chiffrement XOR, il faut que la clef de chiffrement soit en théorie de même longueur que la suite à chiffrer

    par exemple si je veux chiffrer "1001" il faut que ma clef comporte 4 bits par exemple "1010"... mais du coup j'essaie de comprendre, en pratique je ne peux disposer d'une clef de chiffrement de longueur infinie, et par exemple avec une clef de 128 bits, je ne pourrai chiffrer que 128 bits .

    Ma question est donc de comprendre si on répète la clef de chiffrement N fois , pour coller à la longueur du texte à chiffrer

    donc par exemple si ma chaîne à chiffrer fait m bits et ma clef de chiffrement N bits, j'aurai à répliquer ma clef de chiffrement {m/N}+1 fois en gros ? est ce que du coup il ne s'agit pas un peu d'une sorte de faiblesse ? est ce qu'on ne pourrait pas imaginer avoir une clef à entête qui permettrait par exemple d'introduire un peu d'incertitude dans la cyclicité de la clef ? ou opérer des opérations arithmétiques internes à la clef qui feraient que celles ci changerait de longueur ? par exemple si je me met en base 10 et que je considère 2 clefs

    la première A = 21 et B = 43

    si j'élève la première clef au carré j'obtiendrai 441 donc une clef à 3 chiffres et pour la deuxième 1849 donc une clef à 4 chiffres. Avec un peu d'imagination on peut imaginer pleins de stratagèmes exotiques pour affecter la façon dont la clef est lue: est ce que tout ceci à une quelconque utilité (on suppose que l'attaquant à l'algorithme à disposition donc peut faire du chiffré choisi et du texte en clair choisi)


    Merci pour vos retours,
    Gorz

  2. #2
    Expert éminent sénior Avatar de Flodelarab
    Homme Profil pro
    Inscrit en
    Septembre 2005
    Messages
    5 243
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Charente (Poitou Charente)

    Informations forums :
    Inscription : Septembre 2005
    Messages : 5 243
    Points : 13 458
    Points
    13 458
    Par défaut
    Bonjour

    Le chiffrement par "ou exclusif" est mathématiquement parfait : N'importe quel message de départ a pu donner le message chiffré à l'arrivée. Contrairement à Enigma, où Les cryptanalystes pouvaient tenter de chiffrer des messages de météo, pour voir si ça marchait.

    Tout système de sécurité a la résistance du maillon le plus faible. Donc si le chiffrement proprement dit est parfait, on va lister les failles extérieures.
    • On ne doit pas pouvoir deviner la clé par confrontation des messages chiffrés. Ce qui est possible si on utilise toujours la même clé.
    • On ne doit pas pouvoir deviner la clé par confrontation des bouts du message chiffré. Ce qui est possible si la clé est trop petite, donc réutilisée.
    • On ne doit pas pouvoir reconstruire la clé. Ce qui est possible puisque les machines obéissent et sont donc incapables de faire des choses aléatoires. On parle de "pseudo-aléatoire".


    Conclusion : il faut une clé suffisamment longue et originale (aléatoire et jetée après utilisation).

    pour faire un chiffrement XOR, il faut que la clef de chiffrement soit en théorie de même longueur que la suite à chiffrer
    Ou plus grande.

    par exemple avec une clef de 128 bits, je ne pourrai chiffrer que 128 bits .
    C'est exactement ça !

    si on répète la clef de chiffrement N fois
    Faute ! La répétition de motif est une faille. Si toutes les lettres sont codées 11xy, on va voir apparaître tout un tas de 01zw dans le chiffrement car la clé est 1010. Une analyse fréquentielle permet de retrouver les lettres et ta sécurité est morte.

    introduire un peu d'incertitude
    Mais si la clé est aléatoire l'incertitude est déjà totale ! Ton "un peu" affaiblit la sécurité. Et si tu n'as pas d'incertitude, alors ta clé n'est pas aléatoirement générée. Retour au début.

    dans la cyclicité de la clef ?
    Le codage dont tu parles porte d'autres noms comme "Code de Vernam", "One time pad encryption", "chiffrement par bloc jetable". On ne recycle pas ! On jette.

    ou opérer des opérations arithmétiques internes à la clef qui feraient que celles ci changerait de longueur ?
    Là, tu es dans la construction. La clé ne doit pas être re-constructible.

    (on suppose que l'attaquant à l'algorithme à disposition donc peut faire du chiffré choisi et du texte en clair choisi)
    Je ne comprends cette phrase. Mais elle inspire cette question: Si le "ou exclusif" est parfait, pourquoi on utilise pas cela partout et avec une hégémonie sans partage ?
    Réponse : Justement parce qu'on est incapable de générer des clés aléatoires en continue sans faille.
    La cryptographie quantique existe. Mais la première marche est plutôt la distribution quantique de clés classiques (celles dont tu parles). QKD = Quantum key distribution. Les chinois semblent en pointe dans le domaine.

    Désolé pour le pavé.
    Cette réponse vous apporte quelque chose ? Cliquez sur en bas à droite du message.

  3. #3
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    merci beaucoup pour ces explications parfaitement limpides.

    cela dit dans le cadre d'un échange de clefs publiques, la longueur de la clef privée est limitée par la taille du p, si par exemple je me place dans le protocole de Diffie-Hellmann (solution que j'ai retenue pour mon système) - la clef de chiffrement n'est donc pas aléatoire, par contre la clef secrète oui mais elle ne sert qu'à calculer la clef de chiffrement (après je suppose qu'il suffit de corrompre une seule des 2 machines, par accès RAM, pour pouvoir reconstituer la clef de chiffrement)

    typiquement la longueur de la clé privée va être donc de 100, ce qui correspond à un message assez court, quelques phrases tout au plus.

    Par ailleurs, l'échange de clef publiques se fait habituellement une seule fois, au début d'un échange, la même clef est donc utilisée pour chiffrer une série, dans mon esprit la clef été jetée à la fin de l'échange.

    si je comprends ce que tu dis il faudrait donc ou effectuer une réinitialisation des clefs à chaque échange d'information de longueur maximale celle de ma clef, ce qui oblige l'interlocuteur a rester en listen et obère la messagerie différée

    ou alors avant l'émission des clefs prévenir l'interlocuteur que l'on souhaite avoir une clef de n caractères, donc en gros j'écris mon message, et je demande à mon interlocuteur de paramétrer son générateur de clef sur la longueur de mon message et je fais de même de mon côté...

    en tout état de cause tout ceci semble particulièrement fastidieux.. j'avais compris que les pratiques habituelles consistaient à échanger une clef publique, à calculer chacun de son côté la clef secrète, et ensuite de garder cette clef secrète pour la série d'échanges, et c'est d'ailleurs ce que semblait faire quelqu'un dans cet exemple

    https://stackoverflow.com/questions/...and-decrypting

    après de ce que j'imagine, on peut avec la primo-clef secrète asymétrique, échanger à chaque échange une clef symétrique servant à décoder le message envoyé

    donc par exemple à chaque échange i j'envoie

    {clef symétrique pseudo-aléatoire S(i) chiffrée avec la clef secrète asymétrique S0 calculée par échange de clefs publiques}
    {message chiffré avec la clef symétrique S(i)}

    est ce que c'est bien ça la façon de procéder ?

    mais du coup c'est ce qui me chiffonne c'est que les longueurs de clefs symétriques sont forcément bornées par la longueur de la clef S0, qui elle même est limitée

    est ce qu'on peut envisager d'envoyer une clef symétrique plus longue que la clef secrète, en répétant la clef secrète autant fois que nécessaire ? si on suppose que la clef symétrique est quasi-aléatoire (je peux rajouter de l'entropie timer+souris p.e.), et de toute façon la clef S0 ne change pas lors des échanges successifs de clefs symétriques donc la même question se poserait à la longue


    par ailleurs je ne comprends pas très bien ce que tu veux dire par
    si toutes les lettres sont codées 11xy
    ça serait une erreur d'avoir un tel pattern dans le message en clair qui doit déjà être bien mélangé

    je veux dire je procède comme suit:

    je veux envoyer


    1. "la soupe est chaude"





    ce qui se traduit en numérique par exemple en

    1. 56416574987651357498710034


    ce qui après chiffrement XOR via clef donnerait par exemple

    1. 152445676541324132468745452


    le passage de 1 à 2 est potentiellement connu (principe de transparence) par contre il est conçu pour limiter les patterns je suis parti sur des n-uplets avec décalage selon position dans la chaîne à chiffrer ce qui limite l'analyse fréquentielle, et dépend également de la clef asymétrique (selon la clef asymétrique l'algorithme de numérisation ne se comporte pas pareil), je me sers d'un bout de la clef symétrique pour mélanger mes n-uplets de différentes façon - c'est déjà une forme de pré-chiffrement en soit, et je pourrai même en rester là sauf que le nombre de combinaisons de dictionnaires de n-uplets possibles est trop facile à casser en brute force

    Merci beaucoup en tout cas pour ces premières indications,
    Gorz

  4. #4
    Expert éminent sénior Avatar de Flodelarab
    Homme Profil pro
    Inscrit en
    Septembre 2005
    Messages
    5 243
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Charente (Poitou Charente)

    Informations forums :
    Inscription : Septembre 2005
    Messages : 5 243
    Points : 13 458
    Points
    13 458
    Par défaut
    Citation Envoyé par Gorzyne Voir le message
    je me place dans le protocole de Diffie-Hellmann
    C'est un algorithme à secret partagé. Cela ne dit rien de ce que tu fais de la clé, après. Si tu fais un XOR, ce n'est pas bien.

    Citation Envoyé par Gorzyne Voir le message
    (solution que j'ai retenue pour mon système) - la clef de chiffrement n'est donc pas aléatoire, par contre la clef secrète oui mais elle ne sert qu'à calculer la clef de chiffrement
    Il faut être précis sur le vocabulaire. L'information échangée dans Diffie-Hellman n'est pas une clé.

    Citation Envoyé par Gorzyne Voir le message
    (après je suppose qu'il suffit de corrompre une seule des 2 machines, par accès RAM, pour pouvoir reconstituer la clef de chiffrement)
    Oui. Ou la torture. On s'éloigne des concepts mathématiques.

    Citation Envoyé par Gorzyne Voir le message
    si je comprends ce que tu dis il faudrait donc ou effectuer une réinitialisation des clefs à chaque échange d'information de longueur maximale celle de ma clef, ce qui oblige l'interlocuteur a rester en listen et obère la messagerie différée
    Avec un XOR, oui. Mais personne ne fait cela.

    Citation Envoyé par Gorzyne Voir le message
    j'avais compris que les pratiques habituelles consistaient à échanger une clef publique, à calculer chacun de son côté la clef secrète, et ensuite de garder cette clef secrète pour la série d'échanges
    Les pratiques habituelles avec RSA sont de générer une paire de clés publique/privée.
    Les pratiques habituelles avec Diffie-Hellman sont d'utiliser AES. N'est-ce pas ?

    Citation Envoyé par Gorzyne Voir le message
    , et c'est d'ailleurs ce que semblait faire quelqu'un dans cet exemple
    On ne dit pas que ça n'existe pas. On dit que c'est une sécurité faible
    C'est son droit de mal protéger ses données.

    Citation Envoyé par Gorzyne Voir le message
    après de ce que j'imagine, on peut avec la primo-clef secrète asymétrique,
    Il faut être précis sur le vocabulaire. Dans ton cas, Diffie-Hellman, il n'y a pas de clé asymétrique.

    Citation Envoyé par Gorzyne Voir le message
    est ce que c'est bien ça la façon de procéder ?
    Je ne comprends pas ce que tu fais. Les termes ne sont pas les bons.

    Citation Envoyé par Gorzyne Voir le message
    par ailleurs je ne comprends pas très bien ce que tu veux dire par ça serait une erreur d'avoir un tel pattern dans le message en clair
    Le problème, c'est la confrontation des messages chiffrés qui devraient être indépendants et qui ne le sont pas à cause de la clé commune.
    On parle bien de faille conceptuelle et pas de mise en place directe. Je comprends bien qu'on peut toujours faire des croche-pattes aux cryptanalistes en ajoutant des manipulations sans valeur sécuritaire mais casse-pieds quand on est en face.

    Citation Envoyé par Gorzyne Voir le message
    1. "la soupe est chaude"
    Le temps de faire ton chiffrement, la soupe sera froide.
    Cette réponse vous apporte quelque chose ? Cliquez sur en bas à droite du message.

  5. #5
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    merci pour ces compléments d'information, effectivement je ne maîtrise pas forcément le bon vocabulaire

    donc on reprend depuis le début, et je vais essayer de préciser le cadre de ce que je veux faire

    donc Bob pars d'une clef secrète pseudo-aléatoire A générée avec un logiciel L
    Alice avec le même logiciel L dispose d'une clé B
    avec ces deux clefs ils génèrent donc deux clefs publiques GA et GB qui fonctionnent donc comme des sortes d'adresses de contact (je ne me soucie pas d'authentification à ce stade)

    grâce aux clefs publiques, Alice et Bob sont capable de partager une clef secrète GAB que Eve ne peut calculer, même en interceptant GA et GB.

    La question suivante est, qu'est ce qu'Alice et Bob vont faire de leur clef secrète. Faire un XOR directement avec cette clef secrète est évidemment une mauvaise idée car il suffit de disposer de deux chiffrés avec la même clef GAB pour avoir le chiffré d'un message avec l'autre...


    en effet si Bob envoit un message M1 XOR GAB a Alice et Alice répond avec un message M2 XOR GAB à Bob, alors Eve qui dispose de (M1 XOR GAB) et (M2 XOR GAB) peut calculer (M1 XOR M2).

    donc c'est éventuellement là où je me dit que les messages que pourraient s'envoyer Alice et Bob avec la clef partagée Diffie-Hellmann seraient uniquement les clefs de chiffrement des messages cibles, qui elles pourraient être jetées à chaque message, et de longueur souhaitée...


    Les pratiques habituelles avec Diffie-Hellman sont d'utiliser AES. N'est-ce pas ?
    Aucune idée, pour moi Diffie-Hellmann sert de handshake, en permettant le partage sécurisé d'une clef secrète à travers l'échange de 2 clefs publiques non sécurisées.

    J'imagine que cette clef partagée doit servir à autre chose par la suite. Chiffrer un et un seul message avec cette clef, message ne pouvant dépasser la longueur de la clef, me paraît très peu efficient, d'autant plus que se pose dès lors le problème d'authentification en parallèle de l'échange des clefs publiques. Ce fonctionnement nécessite pour chaque message de s'échanger les clefs publiques, Alice et Bob passeraient donc leur temps à s'échanger des clefs tout au long des échanges d'information ce qui complexifie la gestion du flux global d'information entre les deux...


    pour résumer ma question (à ce stade)

    est ce qu'on peut envisager en début de protocole le calcul d'une clef partagée S0 (algo DH) entre A et B
    puis à l'aide de S0 , chiffrer par XOR une suite de clé pseudo-aléatoires S1... Sn correspondants aux messages M1...Mn à chiffrer, par XOR également, ce qui donne deux séries
    S'1....S'n les chiffrés XOR de S1... Sn par S0 et C1...Cn les chiffrés de M1...Mn par S1...Sn

    les interlocuteurs s'échangent des couples (S'i , Ci) et sont capable de reconstituer le couple (Si, Mi) en deux étapes

    S'i xor S0 => Si
    Si xor Ci => Mi


    ou pour décrire plus précisement une étape

    étape 1
    échange des adresses publiques
    calcul de la clé partagée S0 entre A et B
    écriture du message M0
    étape 2
    préchiffrement faible de M0 en M1 entropie ~19 bits
    calcul de la longueur du message M1
    création d'une clé pseudo-aléatoire S1 de chiffrement XOR du message M1
    chiffrement XOR de cette clé avec la clé S0 ce qui donne S1'
    étape 3
    chiffrement de M1 avec S1 ce qui donne C1
    envoi de A à B de S1' et C1
    étape 4
    B déchiffre S1' à l'aide de S0 et obtient S1
    étape 5
    B déchiffre M1 à l'aide de S1 et obtient M1
    B déchiffre M1 et obtient M0


    quelles seraient les failles et faiblesses d'une telle approche ?
    je comprends que le système n'est pas "PFS" ... à la rigueur il faudrait envisager de faire expirer régulièrement S0
    après sur le fait de réutiliser S0, étant donné que S0 ne servirait qu'à chiffrer des clés pseudo-aléatoires et aucun message structuré, quelle information pourrait fournir la connaissance des (S'i , Ci) ?

    ce que je comprends aussi c'est que l'attaquant serait capable de reconstituer M1 x M2 facilement
    en effet C1 xor C2 = (M1 xor S1) xor (M2 xor S2) = (M1 xor M2) xor (S1 xor S2)

    or S1 xor S2 = (S'1 xor S0) xor (S'2 xor S0) = (S'1 xor S'2) xor (S0 xor S0) = (S'1 xor S'2) qui est potentiellement connu ce qui permet donc facilement de calculer M1 xor M2

    et étant donné que M1 xor M2 n'est pas chiffré fortement, il doit être possible d'obtenir de l'information sur l'une ou l'autre chaîne (pas évident mais faisable en théorie)

    bref tu avais bien raison sur le fait que ou je n'ai pas le droit de réutiliser S0 ou bien que je n'ai pas le droit de faire un xor avec S0
    bref j'avance

    Gorz





    MErci pour ton aide
    Gorzyne

  6. #6
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    Bonjour.
    J'ai étudié ce sujet à un niveau amateur et j'en ai rédigé une documentation (voir https://laurent-ott.developpez.com/t...el-vba-tome-4/) qui est un rapide résumé des principales méthodes de cryptage et de leurs faiblesses.

    En lisant Gorzyne je pense qu'il y a confusion dans l'utilisation des clés (mais j'ai peut-être mal compris) car le cryptage ne se fait pas octet par octet avec une clé RSA car cela est bien trop long vu les mathématiques qui sont utilisées, et facilement cassable par une analyse des fréquences.

    A mon avis (mais je ne suis pas un pro) il faut utiliser une méthode asymétrique de type RSA (où il y a deux clés : une publique qui permet de chiffrer et une privée qui permet de déchiffrer) pour échanger une clé symétrique (si possible longue et jetable), puis utiliser cette clé pour le cryptage avec cette fois un XOR, qui est bien plus rapide, comme indiqué au chapitre 4 de la documentation.
    Le tout en essayant de brouiller les pistes via un traitement sur la clé symétrique pour éviter les attaques par fréquence. Ça reste du bidouillage mais ça peut inspirer.

    Cordialement.

  7. #7
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    Bonjour LAurent et merci pour ton intérêt
    A vrai dire je ne me suis pas (encore) interessé à RSA mais à son concurrent l'échanges de clefs Diffie-Hellmann, qui est un algo asymétrique permettant de partager une clef secrète, sur la base d'une information publique, appelons ça comme on veut, clef, adresse, ... peut importe. A et B s'échangent une information en clair, et son capable de reconstituer un secret partagé à partir de l'info en clair,... ça me paraît sur le principe assez proche de RSA, modulo la question de l'authentification, le protocole de DH étant vulnérable à une attaque MitM...


    Bref, la question que je me posais était que faire de ce secret. En effet si je dois chiffrer une longue sérire d'information, est ce qu'il existe des méthodes sûre pour à partir de cette clef secrète, générer une suite de clefs symétriques...

    J'avais en tête de chiffrer mes clefs symétriques aléatoires avec cette clef initiale, ce qui rend vulnérable au nonce reuse... mais bon je me demande sur des clefs symétriques bien aléatoires en quoi le nonce reuse peut servir.. donc je vais me cultiver sur ce point. Evidemment cette méthode n'est pas du tout PFS :/

    Sinon comment le suggérai Flodelarab, il faut recalculer une clef DH à chaque échange (pour moi la clef DH était valable pour une session ie une série de messages à chiffrer) , du coup ça ralentit beaucoup , mais pourquoi pas.. ce qui me pose problème c'est la longueur de la clef. En général la longueur de mon message DH est un multiple de la longueur de ma clef, donc il y a un reuse cette fois directement sur du message, et pas sur de la clef aléatoire, donc se pose également la question du nonce reuse à ce stade

    Bref si vous avez des pistes pour m'aider sur ces sujets.

    Gorz

  8. #8
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    Laurent j'ai regardé ton lien je trouve ça très bien et très intéressant... Mais juste une question dans ton code tu traites que avec des longs et pas en string il me semble ?

    En effet je lis

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Malheureusement, il est impossible de manipuler des nombres à 100 chiffres en VBA.
    Au risque de paraître prétentieux mais j'arrive à faire de l'exponentiation modulaire avec des centaines de chiffres en VBA, en quelques secondes, un mélange de Trachtenberg, de Knuth et un peu de liant... Il existe d'autres solutions pour traiter des très longs strings caractère par caractère bref...

    J'aurai aussi envie d'ajouter que c'est dommage de baser le tirage pseudo aléatoire sur le rnd() natif... Ajouter un peu d'entropie via souris pointapi ne coûte pas très cher

    En tout cas ton article va sans doute me donner de belle idées

  9. #9
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    Citation Envoyé par Gorzyne Voir le message
    ... j'arrive à faire de l'exponentiation modulaire avec des centaines de chiffres en VBA, en quelques secondes, un mélange de Trachtenberg, de Knuth et un peu de liant... Il existe d'autres solutions pour traiter des très longs strings caractère par caractère bref...
    Bonjour Gorzyne.
    En VBA les fonctions mathématiques natives de base ne peuvent traiter que des nombres d'une longueur maximale de 29 caractères (soit 14 octets), en utilisant le format DECIMAL (car le format DOUBLE ne va pas si loin).
    Dans le tome 4 que tu as lu, j'utilise les fonctions trouvées sur le site « http://fordom.free.fr/ » pour le calcul de l'exponentiation modulaire (voir l'annexe 2) et je me contente de travailler sur des nombres entiers au format DECIMAL.
    Mais en effet il est possible de manipuler des nombres bien plus grands, en utilisant le format String, ce sera le cas dans la prochaine documentation que je devrais publier prochainement, qui a comme sujet la factorisation par la méthode du crible quadratique où il faut manipuler des nombres de 100.000 caractères.
    Les fonctions utilisées sont issues de "fordom.free.fr", et certaines ont dû être adaptées pour les grands nombres. Le principal problème était qu'il manquait les fonctions pour la division des grands nombres (donc du modulo) que j'ai dû écrire.

    Pour répondre à ta question, même s'il est possible en VBA de générer une clé RSA de 200 caractères, cela n'a aucun intérêt pour le cryptage des cellules EXCEL comme dans ma documentation (car les clés RSA ne servent qu'à échanger une clé symétrique, et c'est cette clé qui est utilisée pour chiffrer et déchiffrer, comme indiqué dans mon précédent message). Dans mon cas c'est la messagerie sécurisée des utilisateurs qui se charge de cet échange.

    A ce sujet, en m'inspirant de ce que j'ai développé pour CryptoVBA, j'ai réfléchi à une méthode qui peut t'inspirer :
    Sachant que Alice et Bob ont préalablement échangé deux clés secrètes (RSA ou autre méthode).
    1) Quand Bob veut communiquer avec Alice, il lui fait une demande en clair "Bonjour Alice, besoin de communiquer..."
    2) Alice reconnait Bob (sa voix ? son numéro de téléphone ? son mail crypté ? autre astuce ?) et lui retourne deux informations chiffrées : un nombre aléatoire Q et le poids le Q quand il est non chiffré. (Attention dans mon exemple, Q doit avoir une nombre de caractères multiple de 4, par exemple 32 caractères.)
    3) Bob déchiffre Q (car il connait la clé d'Alice) et calcule le poids de Q, puis déchiffre le poids envoyé par Alice et compare les résultats. S'ils sont identiques c'est que Q vient bien d'Alice.
    4) Bob chiffre son message M avec Q comme dans le chapitre 4 de ma documentation, c'est à dire que Q est découpé en 4 parties, les 8 premiers chiffres sont la clé C1, les 8 suivants C2, puis C3 et C4. Puisque M doit avoir une taille multiple de 4 et d'au moins 100 caractères (ou plus suivant les goûts) pour éviter que la taille puisse donner des indices, il faut ajouter un caractère 0 à M suivi de caractères aléatoires pour répondre à ces contraintes.
    Il faut aussi calculer l'entier Coef = (C1 x C2 x C3 x C4) / 400
    Boucle sur la taille de M
    Modification des clés pour éviter l'attaque par fréquence :
    C1 = C1 + ((C1 x Q) MOD Coef)
    C2 = C2 + ((C2 x Q) MOD Coef)
    C3 = C3 + ((C3 x Q) MOD Coef)
    C4 = C4 + ((C4 x Q) MOD Coef)
    Lecture de 4 octets de M (O1, O2, O3, O4) :
    M1 = O1 XOR (C1 MOD 255)
    M2 = O2 XOR (C2 MOD 255)
    M3 = O3 XOR (C3 MOD 255)
    M4 = O4 XOR (C4 MOD 255)
    Génération du message chiffré MC = MC + O1 + O2 + O3 + O4
    Fin de la boucle
    5) Bob envoie à Alice 3 informations : Q (chiffré avec sa clé), le poids de M avant son chiffrement (chiffré avec sa clé), et MC (le message chiffré).
    6) Alice déchiffre Q (car elle connait la clé de bob) et vérifie que c'est bien le même nombre que celui qu'elle a envoyée : Bob est donc bien l'expéditeur.
    Puis elle déchiffre MC avec la clé Q (en utilisant des XOR très rapides) et obtient M.
    Elle calcule le poids de M et vérifie qu'il est identique à celui envoyé par Bob : si c'est le cas le message n'a pas été modifié.

    A noter : si Bob ne contacte pas Alice (étape 1) pour avoir Q (étape 2) il choisit un nombre Q et continue les étapes. Alice pourra déchiffrer MC (car elle connait la clé de Bob) mais ne sera pas certaine que le message vient de Bob (vol de sa clé).

    Bonne continuation.

  10. #10
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    merci pour ces compléments
    est ce que Miller Rabin est le plus adapté pour générer des grands nombres premiers ? pour les générer on a pas d'autre méthode que de seeder au pif et passer par un test de primalité ?
    je demande avant d'adapter ce test en string

    sur ta partie 4) je pense que c'est cette partie qui m'intéresse je comprends que tu chiffres directement ton M avec Q bidouillé, donc si ton Q est corrompu, toute la session est corrompue ?

    en admettant que tu change de Q à chaque message, celui ci va quand même nécessité plusieurs Q

    je saisi pas "pour éviter l'attaque par fréquence"
    est ce que tu peux pourrais préciser ce que tu entends par les opérateurs + , * etc, et les bases ? et pourquoi mod 255 ?

    pourquoi considère tu que cette méthode est robuste ? c'est l'algo type pour la partie symétrique du RSA ?

  11. #11
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    Citation Envoyé par Gorzyne Voir le message
    est ce que Miller Rabin est le plus adapté pour générer des grands nombres premiers ?
    Le test de Miller Rabin ne génère pas de nombres premiers, mais teste si un nombre est premier. Il existe d'autres tests, mais celui-ci est rapide et j'avais le code source en VBA sous la main.

    Citation Envoyé par Gorzyne Voir le message
    pour les générer on a pas d'autre méthode que de seeder au pif et passer par un test de primalité ?
    Je ne vois que cette façon de faire.

    Citation Envoyé par Gorzyne Voir le message
    je demande avant d'adapter ce test en string
    Dans quel langage de programmation ? Si c'est en VBA ne perds pas ton temps, je te donnerai mes codes source.

    Citation Envoyé par Gorzyne Voir le message
    sur ta partie 4) je pense que c'est cette partie qui m'intéresse je comprends que tu chiffres directement ton M avec Q bidouillé, donc si ton Q est corrompu, toute la session est corrompue ?
    Oui.
    Citation Envoyé par Gorzyne Voir le message
    en admettant que tu changes de Q à chaque message, celui ci va quand même nécessité plusieurs Q
    Un Q à chaque message, c'est nécessaire pour ne pas chiffrer de la même façon un même message (relit le chapitre 4 de ma documentation, tu comprendras mieux). De toute façon Q est un nombre aléatoire très rapide à générer.

    Citation Envoyé par Gorzyne Voir le message
    je saisi pas "pour éviter l'attaque par fréquence"
    Si tu chiffres le caractère "e" avec toujours la même clé tu obtiens toujours le même chiffrement. Par exemple "P". Si ce caractères est très fréquent dans le message chiffré alors on en déduit que "P" signifie "e". (voir le chapitre 2 de ma documentation). Il faut donc brouiller les clés.

    Citation Envoyé par Gorzyne Voir le message
    est ce que tu peux pourrais préciser ce que tu entends par les opérateurs + , * etc, et les bases ?
    + est une concaténation : C1 = C1 + ((C1 x Q) MOD Coef) signifie : On transforme C1 en lui donnant une nouvelle valeur : Sa valeur d'origine plus le reste de la division de (C1 d'origine fois Q) par Coef

    Citation Envoyé par Gorzyne Voir le message
    et pourquoi mod 255 ?
    Parce qu'un octet est compris entre 0 et 255, tu ne peux pas avoir un résultat supérieur à 255. MOD est le reste de la division. Par exemple 300 MOD 255 donne 45.

    Citation Envoyé par Gorzyne Voir le message
    pourquoi considères tu que cette méthode est robuste ? c'est l'algo type pour la partie symétrique du RSA ?
    Je n'ai aucune idée de la robustesse de cette méthode. J'ai essayé de brouiller les pistes en utilisant une méthode rapide car elle utilise des mathématiques simples. Tu peux utiliser la méthode de ton choix pour un chiffrement symétrique.

  12. #12
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    D'accord mais comment tu chiffres Q avec ta clef RSA ?

    Ce que je cherches à chiffrer n'est normalement pas vulnérable à une attaque triviale par fréquence, ma problématique est de savoir s'il y a d'autres failles au nonce reuse que l'attaque triviale par fréquence.

    Je crois que les bonnes pratiques sont d'utiliser les schémas de Feistel mais je n'ai pas saisi la preuve de robustesse à part les tests empiriques sur le nombre de tours à opérer

  13. #13
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    Citation Envoyé par Gorzyne Voir le message
    D'accord mais comment tu chiffres Q avec ta clef RSA ?
    Tu peux chiffrer Q avec l'algorithme de ton choix, RSA ou autre, ce n'est pas le problème.
    Je souligne que je n'ai aucune idée de la robustesse de la méthode que j'ai présentée, c'était juste pour te donner des idées.

  14. #14
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    je t'ai envoyé un MP est ce que tu peux m'envoyer Miller-Rabon en string stp ?

  15. #15
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    Citation Envoyé par Gorzyne Voir le message
    je t'ai envoyé un MP est ce que tu peux m'envoyer Miller-Rabon en string stp ?
    Ca utilise les fonctions des 3 modules envoyés dans la discussion sur la division des grands nombres.

    Code VBA : 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
    '---------------------------------------------------------------------------------------
    ' http://fordom.free.fr/
    '---------------------------------------------------------------------------------------
     
    Option Explicit
     
    '---------------------------------------------------------------------------------------
    Public Function TestMillerRabinGN(ByVal n As String) As Boolean
    '---------------------------------------------------------------------------------------
    ' Test MILLER RABIN pour les grands nombres.
    ' Retourne Vrai si n a une forte probabilité d'être un nombre premier.
    '---------------------------------------------------------------------------------------
    Dim a As Long, BaseMaxi As Long, i As Integer
    Dim Base As Variant
    Dim x() As Byte
    Dim nm1 As String
     
    ' Convertit la chaîne en nombres:
    x = StrConv(n, vbFromUnicode)
     
    ' Si le dernier chiffre est différent de 1, 3, 7, 9 alors quitter:
    Select Case Chr(x(UBound(x)))
        Case "0", "2", "4", "5", "6", "8": Exit Function
    End Select
     
    ' Si la somme des nombres de n modulu 3 donne 0 alors quitter:
    For i = 0 To UBound(x): a = a + x(i) - 48: Next i
    If a Mod 3 = 0 Then Exit Function
     
    ' Base à tester:
    Base = Array(2, 3, 5, 7, 11, 13, 17, 19, 23)
     
    ' Test si n est divisible par un (très petit) nombre de la base, en
    ' commençant par 7 car 2, 3, et 5 déjà testés:
    For a = 3 To UBound(Base)
        If ModGNPD(n, Base(a)) = 0 Then Exit Function
    Next a
     
    ' Calcul rapide de n - 1 (car n ne finit jamais par 0):
    nm1 = n
    Mid(nm1, Len(nm1), 1) = Chr(x(UBound(x)) - 1)
    ' Si 2^n-1 MOD n <> 1 alors quitter:
    If ExpoModGN(2, nm1, n) <> "1" Then Exit Function
     
    ' Optimisation nb base à tester:
    BaseMaxi = Int(4 + LogGN(n) / 8 - Abs(4 - LogGN(n) / 8))
     
    ' Algo:
    a = 0
    Do
        If MillerRabinGN(n, Base(a), nm1) = False Then Exit Function
    a = a + 1
    Loop Until a > BaseMaxi
     
    TestMillerRabinGN = True
    End Function
     
    '---------------------------------------------------------------------------------------
    Private Function MillerRabinGN(ByVal n As Variant, ByVal a As Variant, ByVal nm1 As String) As Boolean
    '---------------------------------------------------------------------------------------
    ' RQ : IMPOSSIBILITE DE REPONDRE SI n multiple de a
    '---------------------------------------------------------------------------------------
    ' Paramètres:
    Dim H As Long, d As Variant, i As Long, Reste As Variant
     
    ' Calcul de n-1 = 2^h * d avec d impair:
    Do
        H = H + 1: If H > 30 Then Exit Do
        d = DGN(nm1, 2 ^ H, Reste)
    Loop Until Reste = 0 And Right(d, 1) Mod 2 = 1
     
    ' Test a^d=1 mod n:
    MillerRabinGN = (Val(ExpoModGN(a, d, n)) = 1)
    If MillerRabinGN Then Exit Function
     
    ' Test s'il existe un 0<= i <= h-1 tel que a^(h*2^i)=-1 mod n:
    For i = 0 To H - 1
        MillerRabinGN = (ExpoModGN(a, PGN(d, 2 ^ i), n) = nm1)
        If MillerRabinGN Then Exit For
    Next i
     
    End Function
    '---------------------------------------------------------------------------------------
    '---------------------------------------------------------------------------------------
    Cordialement

  16. #16
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut j'ai toujours pas compris
    en fait je vais être relou et revenir à ma question initiale mais je ne comprends toujours pas où est la faille de réutiliser une clé partagée DH pour xorer une clef symétrique

    autant je comprends tout à fait que faire un XOR avec la même clé sur un message structuré pose problème, autant le fait de xorer une clef symétrique, je vois pas à quel niveau se situe ma faille

    je dispose d'une clef partagée de longueur n. Comme mon message est beaucoup plus long que ma clef, j'ai envie de xorer mon message de longueur M avec une clef symétrique de longueur M également. Un chiffrement XOR entre les deux garantit à ce stade la sécurité sémantique.

    maintenant il ne me reste qu'à envoyer cette clef symétrique, en la chiffrant avec ma clef partagée

    vu que ma clef symétrique est aléatoire (on fait l'hypothèse qu'il s'agit d'un nombre vraiment aléatoire), je ne vois pas vraiment comment celle ci pourrait être retrouvée même si je réutilise ma clef

    dans l'exemple ci-dessous je xor mes alea(i) avec la clé, et j'obtiens aléa_chiffré(i). Ma clé est bien réutilisé plusieurs fois (6 fois) pourtant mes aléa_chiffrés sont tout aussi aléatoire que mes aléas initiaux. J'aimerais comprendre comment il serait possible mathématiquement de retrouver mes aléas à partir de mes aléas_chiffrés

    Nom : xorclef.jpg
Affichages : 2665
Taille : 144,3 Ko

  17. #17
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    je ne suis pas un spécialiste du sujet mais j'ai une petite idée de la réponse que l'on va te faire :

    Citation Envoyé par Gorzyne Voir le message
    je dispose d'une clef partagée de longueur n. Comme mon message est beaucoup plus long que ma clef, j'ai envie de xorer mon message de longueur M avec une clef symétrique de longueur M également. Un chiffrement XOR entre les deux garantit à ce stade la sécurité sémantique.
    Donc tu vas chiffrer avec une clé asymétrique ta grande clé symétrique de longueur M. Sachant que les crypto systèmes asymétriques sont très longs car ils utilisent des mathématiques complexes, tu risques d'avoir des temps de traitement très longs. C'est peut-être ici que se pose le problème, imagine ce que ça va donner pour chiffrer un fichier image de 14Mo, c'est-à-dire une clé de 14Mo en asymétrique puis déchiffrer cette même clé côté utilisateur ?

  18. #18
    Membre régulier Avatar de Gorzyne
    Profil pro
    Collégien
    Inscrit en
    Janvier 2008
    Messages
    326
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Janvier 2008
    Messages : 326
    Points : 116
    Points
    116
    Par défaut
    mm nan c'est pas le souci je proposais justement de simplement xorer ma clef symétrique avec le modulo d'une clef partagée donc c'est très rapide au contraire. La clef partagée est petite, rapide et on peut même réfléchir à la changer à chaque message... la clef symétrique fait 14Mo mais c'est un random donc très rapide à générer aussi

    j'essaie de saisir l'idée des maths derrière la cryptanalyse permettant d'attaquer du nonce re-use

  19. #19
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    Faudrait pas non plus que ta clé partagée soit trop petite car il suffirait à un attaquant qui dispose d'un ordinateur rapide de tester toute les combinaisons pour la retrouver.
    Il faudrait trouver un juste milieu.

  20. #20
    Rédacteur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2013
    Messages
    947
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Finance

    Informations forums :
    Inscription : Août 2013
    Messages : 947
    Points : 4 058
    Points
    4 058
    Par défaut
    J'y pense à l'instant : avoir un algorithme fiable est une chose, qu'il s'exécute en un temps raisonnable en est une autre.
    Puisque tu dis pouvoir rapidement chiffrer un fichier de 14 Mo, fait le donc pour voir le temps que ça prend, voir si ça tient la route. C'est à mon avis la première étape avant de passer à la suite.

Discussions similaires

  1. Question sur le chiffrement/dechiffrement
    Par deglingo592003 dans le forum Sécurité
    Réponses: 5
    Dernier message: 05/08/2009, 12h03
  2. Quelques questions sur le TWebBrowser...
    Par CorO dans le forum Web & réseau
    Réponses: 3
    Dernier message: 17/01/2003, 21h23
  3. Question sur les handles et les couleurs...
    Par MrDuChnok dans le forum C++Builder
    Réponses: 7
    Dernier message: 29/10/2002, 08h45
  4. Réponses: 2
    Dernier message: 11/08/2002, 21h27
  5. question sur les message box !
    Par krown dans le forum Langage
    Réponses: 7
    Dernier message: 02/08/2002, 16h11

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