Bonjour, j'ai un ami qui veut me programmer un système de chiffrement sur Windows, mais je suis sur mac. Quel langage il doit prendre pour que je puisse avoir une application simple d'utilisation à la fin sur mon mac. Sachant que je ne sais pas programmer du tout.
Mon but étant de n'avoir qu'à ouvrir le mail télécharger et lancer l'application (.app).
Le sien étant de programmer, faire une application Mac OS et me l'envoyer.
Merci de votre aide !
Il y a des systèmes de chiffrement gratuits qui existent. Hormis pour la beauté de l’exercice pourquoi vouloir inventer la roue ?
Rien ne sert de penser, il faut réfléchir avant - Pierre Dac
Certes. Il y a de nombreuses solutions (C/C++ + Qt, Java) mais dans le cas présent, Python serait sans doute le plus simple.Envoyé par JPL
Il faut noter que programmer sur PC pour Mac sans tester revient à conduire en étant aveugle.
Il devrait au moins envisager d'installer un OSX en virtualisé sur son PC pour tester.
Il veut le faire ce cadeau de donner vie à mes idées de chiffrements. Le second avantage est que personne ne pourra décrypter mes messages sans connaître le système. Ou difficilement.
En plus c'est marrant.
C'est assez rare d'avoir le niveau pour inventer des chiffrements sans rien connaitre à la programmation.
Je me permets de douter très fortement... Il n'y a pas besoin de connaitre le système de chiffrement pour décoder. Cela peut aider.
Ensuite, un système de chiffrement aujourd'hui a besoin d'être incroyablement bien conçu pour être résistant.
De faire un système de chiffrement qui a 99.9% de chance de ne pas être résistant ? Chacun son truc.
Pour le niveau, je ne dirais pas rare mais plutôt certain (que le niveau risque d'être insuffisant) quand on en est à demander quel langage utiliser, en toute objectivité, et ça devient totalement illusoire quand on imagine que personne ne pourra décrypter le message...
Quant on pense que des équipes solides se sont planté avec des algos éprouvés...
Avant de parler langage, regardez ce qui se fait en terme d'algo, et si vous maitrisez un langage, "traduisez" ces algos (simples) en ce langage pour vous amuser...
Toujours pour vous amuser, regardez l'histoire de PGP, de son créateur, et ses implémentations libres "modernes"...
Edit: à moins d'être un mathématicien génial et original, toutes les "idées de chiffrement" que vous pourriez avoir ont déjà été étudiées !
Dernière modification par Ikhar84 ; 14/02/2019 à 21h42.
J'ai glissé Chef !
Ca dépend mais il y en a qui sont "indécryptables" (bien qu'il vaut mieux les employer qu'une seule fois...)
Exemple : "les sanglots longs des violons d’automne bercent mon cœur d'une langueur monotone"
Quesquidit ?
Le principe c'est que chaque intervenant convient à l'avance du code à employer pour chaque mot et qu'il passe au code suivant dans sa liste gardée précieusement par devers lui et son acolyte, une fois employé.
A moins d'être devin, c'est impossible à décoder.
Ca marche moins bien avec des fichiers binaire,mais pour se parler c'est le top.
Je vous met au défi du coup :
000004000119000215000300000417 000520000613000702000814000920 001015001105001220001313001404 001518001619001704001800001913 002003002117002214002312002400 002516010020010104010212010300 010417010517010600010702010807 010904011020011113011202011314 011404011520011617011716011820 011904012011012111012204012303 012404012519020004020118020219 020304
Mais le truc c'est de s'amuser et de rendre le jeu utile.
En réalité j'ai déjà créé pas loin de 20 chiffrements différents et le but est simplement de programmer mon système déjà opérationnel. C'est un peu comme du binaire ce que je fais la. Mais en plus compliqué.
Donc on part sur du Python ! Ok, et un émulateur de Mac OS X pour éviter le labyrinthe. Merci !
Dernière modification par Kinkazma ; 14/02/2019 à 23h37.
Aucun intérêt : n'importe qui peut poser un message court comme ça. Cela ne prouve absolument rien sur l'algorithme où on suppose qu'on a un échantillon de message largement plus grand pour travailler.
Le tien est déjà étonnant : la fréquence des différents caractères utilisé est largement non uniforme et ce n'est pas bon signe.
Certes, mais le but étant de troubler le fouineur :
AAEABTACPADAAERAFUAGNAHCAIOAJU AKPALFAMUANNAORAPSAQTAREASAATN AUDAVRAWOAXMAYAAZQBAUBBEBCMBDA BERBFRBGABHCBIHBJEBKUBLNBMCBNO BOEBPUBQRBRQBSUBTEBULBVLBWEBXD BYEBETCAECBSCCTCDE
Le but étant de créer une fausse fréquence. L'autre est d'avoir pour une lettre donnée une position est une valeur.
A = 00 Z = 25
Bonjour -> 0101 0213....
Mais voulant dès texte de plus de 25 caractères, je rajoute un autre compteur de 25. ce qui donne des textes de longueur maximum de 25*25 caractères.
Dans ce cas j'ai laissé tout dans l'ordre, mais on peut mélanger les paquets de 6 pour rendre incompréhensible la logique.
C'est donc infiniment plus simple qu'un Enigma qu'on savait décrypter pendant la 2nde guerre mondiale...
Une sorte de variante en plus faible de la double transpo utilisée durant les 2GM pour les messages non critiques par la résistance française pour communiquer avec Londres et Alger, à partir de 1942.
Ca résistait quelques jours aux cryptographes allemands (qui n'avaient pas d'ordinateurs), et donc cela suffisait pour confirmer un parachutage. Pour les messages plus sérieux, ils utilisaient des masques jetables.
Peut-être, mais le mieux c'est d'éviter de les attirer...
Un message codé qui n'en a pas l'air vaut mieux qu'une série de caractères qui va alerter et intéresser justement ceux qui adorent craquer les codes, juste pour le fun.
Il y a trois étapes dans mon chiffrement et celle là est la première. C'est juste disons... une traduction en code. Je passe cela dans une version améliorée de Cesar, avec Une clef et enfin dans un tableau de vigenere melangé, dans lequel le Z ne figure pas car ce dernier est codé autrement.
Donc c'est quand même solide.
Ca me paraît illusoire d'espérer inventer un système de chiffrement performant ex nihilo. Mais si c'est un jeu pourquoi pas? Attention aussi au fait que la fourniture d'un système de chiffrement est règlementée (doit faire l'objet d'une déclaration il me semble).
Non; plus depuis 2004, sauf exportation (très improbable dans le cas présent ...).
Absolument pas mais vous voulez absolument être persuadé du contraire.
Je ne comprend pas comment quelqu'un peut déchiffrer un message chiffré par trois moyens inconnus mis à la suite (le troisième étant tout de même un style de Vigenère) ?
Il n'y a pas de fréquence. Sans posséder le programme c'est pas possible ! Sans connaître la façon dont est chiffré mon message c'est impossible.
Vous connaissez quelqu'un capable de me montrer le contraire ?
Il n'en reste pas moins que la fourniture d'un système de chiffrement est réglementée, et doit faire l'objet d'une déclaration ou d'une demande d'autorisation préalable.Non; plus depuis 2004, sauf exportation (très improbable dans le cas présent ...
C'est le fournisseur qui doit faire les démarches. Il doit notamment décrire le système utilisé et indiquer les personnes qui en sont responsables, techniquement et administrativement (voir par ici).
En d'autres termes, la personne qui fournit à Kinkazma le logiciel de chiffrement est légalement tenue de donner à l'État la possibilité de déchiffre les messages codés qu'il échangera. Comme système inviolable, ça se pose là !
Dépéchez-vous de publier, vous serez le plus jeune mathématicien ayant jamais reçu la MF.
Not only is it not right, it's not even wrong!
Tu ne vois pas comment en effet : c'est exactement le problème.
"Sans posséder le programme" est là aussi le problème. Ce que tu essaies de faire c'est de la "sécurité par l'obscurité". Un principe de base est justement que l'algorithme est public et que le chiffrage doit résister quand même.
S'il n'est pas public, croire qu'il est secret et qu'il va le rester et qu'une partie de la protection repose là dessus est une énorme faille de sécurité.
Oui mais il faudrait que tu aies les accréditations pour que je te les présente
Perso, j'aurais tendance à dire "dépéchez vous de lire sur le sujet" mais l'humour marche aussi
Mon but c'est juste de tenir mon journal, et de discuter en cours.
Ça ne fuite pas le programme dans ces conditions.
Pour en revenir au sujet, il est tout-à-fait possible de développer des logiciels multi-plateformes (et notamment Windows/Mac) à condition :
- soit de ne pas utiliser des fonctionnalités spécifiques à ces plateformes ;
- soit de prévoir une compilation conditionnelle afin d'intégrer des fonctionnalités équivalentes mais logiciellement différentes ;
- soit de s'en remettre entièrement à un framework multi-plateformes.
Pour ma part, j'applique ces deux premiers points, pratiquement tous les jours, principalement en langage C.
Comme Microsoft a la fâcheuse habitude de ne pas faire comme tout le monde, cela suggère de ne pas utiliser les outils et méthodes de développement classiques sous Windows, mais de se limiter à une programmation plus traditionnelle, comme on la pratique dans le monde *nix (pour rappel, Mac OS X est certifié Unix).
Après, le langage choisi importe peu tant qu'il n'est pas spécifique à la plateforme (comme Visual Basic, par exemple).
Mais à mon avis, le problème réside surtout dans la façon dont le programme doit être intégré dans l'environnement, et notamment dans ses liens avec l'interface graphique, le réseau de communication ou d'autres applications ou services système.
Quel logiciel choisir alors ?
Moi, j'aurais choisi du PHP (avec un serveur sur chaque machine ou un serveur dédié accessible par chaque machine).
* C'est indépendant du client.
* C'est suffisant pour le type de traitement demandé.
* Il possède une bonne bibliothèque en rapport avec le cryptage.
* C'est plutôt facile en terme de programmation.
* De nombreux exemples produits par une communauté de programmeurs.
Manuel : http://php.net/manual/fr/function.crypt.php
Exemple : http://phpsources.org/code/php/class...-et-decryptage
Le moins, c'est qu'il faut faire attention à la version de PHP lorsqu'on choisi telle ou telle fonction (mais bon, ça se gère).
On ne peut pas répondre tant qu'on ne sait pas comment le logiciel de chiffrement/déchiffrement doit être utilisé dans ton environnement.
S'agissant du langage de programmation, comme je l'ai déjà indiqué, ce n'est pas important tant qu'on n'en choisit pas un qui est spécifique à Windows.
Du point de vue sécurité, PHP est une vraie passoire. Il risquerait de servir de point d'accès au piratage des machines, ce qui permettrait à un intrus éventuel de lire les messages en clair. De plus, cela ne règle pas le problème de communication entre le logiciel de chiffrement et le système. Si par exemple il est prévu de chiffrer et déchiffrer directement les e-mails dans Apple Mail, je ne vois pas comment un serveur PHP pourra s'en sortir simplement.
Merci beaucoup, mais il n'y a pas plus simple ? Genre un logiciel et un mac virtuel, puis une clé USB et mon mac ?
Bonjour,
Je m'insère furtivement,
Tout à l'heure quelqu'un à proposé python (qui a l'avantage d'être mutli OS et très pratique), en revanche puisque pour le PHP, vous parlez de passoire et de risque,
Si on veut faire quelque chose de sécurisé, est-ce que le fait que python est un langage interprété n'est pas un problème? puisque le code est facilement accessible, n'importe qui ayant accès au code source peut connaître le système de chiffrement utilisé, contrairement à un langage compilé ou le code n'est pas présent
Comment faire dans ces cas là avec les langages interprétés? il n'y a pas moyen de faire en sorte de "cacher" le code d'une manière ou d'une autre?
Tu devrais tout lire : les méthodes de chiffrement ne reposent pas sur le secret du code source. Et du code compilé ne protège pas d’ailleurs : on peut facilement retrouver l’algorithme.
