Discussion :

[derderder]

Je n'y vois rien de stupide personnellement, il y a encore quelques décennies le chiffrement était limité à une longueur de clé de 128 bits dans le domaine civil (il me semble, je n'ai pas de source donc je n'en fais pas un argument solide, je l'admet volontiers je reste très objectif à chacun de mes messages pour ma part).
Je ne trouve pas cela normal que, selon le droit public, donc parfaitement légal, la force publique puisse défoncer la porte d'une propriété privée pour y arréter un suspect mais que tout en étant autorisé à casser un système crypté pour appréhender un crime en préparation, il soit impossible de le faire dans un délai relativement court pour empêcher ce dit crime. Alors oui peut etre que ce serait innéficace car comme vous le dites des sources sont disponibles sur internet, des couteaux de toute taille sont aussi disponibles à vente en magasin, pourtant, la loi définit quel type de couteau peut être porté dans l'espace public, sa longueur de lame, son cran d'arret, etc, et c'est tout à fait normal, pourquoi en serait il autrement pour un système de cryptage qui dispose d'un meme niveau d'accessibilité ? C'est avant tout une question de fond, on ne fait pas de droit sur la forme, et il est parfaitement normal que la question soit posée et qu'il puisse y avoir légifération le cas échéant.

Les terroristes n'utilisent pas toujours de chiffrement, sont quasi tous repérés, donc il est totalement inutile de limiter le chiffrement pour une sécurité illusoire. De plus, comment vérifier que les echanges chiffrés sont tous aux normes ? En les cassant tous ? En imaginant qu'il soit possible de restreindre le chiffrement, c'est rendre vulnérable toutes les entreprises à l'espionnage industriel, ce qui risque d'entrainer un exode massif des entreprises. Et pendant ce temps les terroristes utiliseront toujours des SMS en clair ou Telegram via... les messages de groupes qui sont actuellement non chiffrés et on ne saura toujours pas les arrêter, mais Mme Michu sera rassurée.

Et je ne trouve pas normal au contraire que l'état nous interdise de porter un couteau de la taille que l'on veut sur soi.

Et je n'ai pas dit que ceux qui chiffrent sont ceux qui vendent vos informations, j'ai pointé du doigt les sociétés qui mettent en avant la pseudo sécurité de leur plateforme ou encore des clauses mettant en avant la protection de la vie privée de leurs utilisateurs, alors qu'il n'en est nullement le cas et que les informations sont vendues à des Etats ou d'autres organisations privées commerciales. Les exemples ne manquent pas pourtant.

D'accord sur ce point.

Quel corrélation entre le pourcentage des dépenses publiques par rapport au PIB et la capacité de "nuisance" de l'Etat ? Rien qu'en parlant de "capacité de nuisance", on sent tout de suite l'emprise idéologique qui doit influer sur votre objectivité. Autant, j’admets volontiers que mes connaissances en systemes de cryptographie ne sont surement pas assez élevés pour poser un argumentaire technique pointu, autant le votre à ce sujet est vraiment un non sens.

Ca me fait quand même sourire, parce que si vous venez débattre avec un ultra libéraliste, il va doucement rire en vous disant que la plupart des dépenses sont relatives aux dépenses dites "sociales". J'aurais bien utilisé le mot stupide pour cet argument moi aussi mais je fais preuve de respect pour votre point de vue, mème si je le trouve pour le coup vraiment fantasque et absolument non fondé. Donc cet argument fait de la norvège et de son gouvernement la puissance la plus nuisible d'Europe ...

http://www.lemonde.fr/les-decodeurs/...4_4355770.html

Rajoutez le budget de l'éducation nationale, de la justice, des subventions aux régions et aux autres collectivités territoriales, il vous reste quoi ? Ou est l'écrasante puissance publique ? Ou se cache donc la nuisance ? Dans une niche fiscale en Irlande ? C'est google ca.
i.

Le niveau de dépense de l'État montre à quel point il est important, et ne je jamais oublier qu'au final cet argent qui ne sort pas de nulle part ( C'est gratuit c'est l'état qui paye comme a dit un grand homme d'élection ) est le vôtre et le mien. Les prestations "sociales", sont une redistribution arbitraire ( Injuste diront certains, mais je préfère rester neutre, on pourrait atteindre un point Godwin, Vichy tout ça) des richesses, sans compter le système de retraite obligatoire ( et c'est bien là le problème ), l'éducation que l'on pourrait privatiser etc...

Je suis pessimiste, je considère que l'état ne nous veut pas du bien, mais n'est qu'un amas de personnes défendant leurs intérêt propres, pouvant être opposés aux miens, et moins ces personnes auront de contrôle mieux cela vaudra.

[Marco46]

Je n'y vois rien de stupide personnellement

Parce que tu ne comprends ni les enjeux ni de quoi on parle.

Les chiffrements modernes reposent sur des algorithmes mathématiques connus de tous. N'importe quel développeur disposant de ces algorithmes, et ils sont très faciles à trouver, sera capable de les implémenter. Pire, les implémentations déjà réalisées sont très nombreuses, n'importe quel développeur débutant est capable de réaliser une application permettant d'utiliser ces méthodes de chiffrement. Donc ça n'empêchera en rien quelqu'un de mal intentionné de se protéger s'il s'en donne les moyens.

Limiter la taille des clefs ou forcer l'implémentation de backdoors c'est diminuer la sécurité pour tous les autres, ceux qui seront contraints de respecter la législation (les SI des entreprises, le business des entreprises qui vendent via internet, et enfin les clients finaux, c'est à dire nous tous).

Cela signifie :
- faciliter le travail des criminels qui s'attaquent aux banques et aux transactions sur le réseau, et donc faire peser un risque ultra critique sur l'économie mondiale : Faire perdre la confiance qu'ont les gens sur l'économie numérique.
- faciliter le travail de l'intelligence économique : En limitant la sécurité tu facilites l'espionnage industriel.

Bref, ce n'est pas seulement stupide, c'est parfaitement irresponsable car cela fait peser trop de risques sur les infrastructures de communication actuelles.

Je ne peux pas croire que les entreprises impliquées n'iront pas effectuer un lobbying de malade en emboitant les pas de l'ANSSI pour expliquer à nos gouvernants des conséquences de cette initiative.

[ab1___]

Je comprend parfaitement le point de vue et j'y adhère sur de nombreux points (pas tous évidemment, nous nous sommes compris). Comme se plaisait à le dire Churchill, la démocratie est le pire systeme politique après tous les autres. Je partage ce point de vue et je terminerais la dessus. Merci d'avoir débattu avec moi.

Quelle valeur a ce que dit Churchill ou tel ou tel politicien qui pense que la guerre est quelque chose de raisonnable ? Si la démocratie est élire des élitocrates qui pensent tous que la guerre est l'unique solution aux problèmes du monde, qu'il y a des guerres justes, ou que l'intérêt de la nation prime avant le vivre-ensemble de l'humanité, comme c'est le cas actuellement, alors elle n'a pas grande valeur.

Le problème ne vient pas du système politique mais des individus qui font les systèmes politiques, les citoyens qui votent et ceux qui se font élire. Si les politiciens n'ont aucune bonté, aucun sens pour l'humanité, et ne connaissent que l'ambition, ne pensent qu'à l'enrichissement individuel, des entreprises ou celui de la nation, comment peuvent-ils créer un monde de paix ?

S'ils ne connaissent que la guerre en réponse aux conflits internationaux, comment peut-il y avoir intelligence ? Et si pour eux "intelligence" signifie surveillance ou espionnage des "étrangers" ou des "citoyens", alors l'on crée nécessairement les fondations d'une dictature qui ne dit pas son nom.

Vouloir, pour un gouvernement, espionner toutes les communications à l'heure de la communication globale et des machines connectées, c'est vouloir contrôler les citoyens, et non pas les défendre. Si c'est ce que vous voulez, être contrôlé pour votre sécurité, qu'à cela ne tienne, mais cela ne réglera jamais les problèmes de sécurité étant donné que l'insécurité est créée par cette même manière de vivre, issue d'une pensée étroite et limitée.

Il n'y a aucun problème avec le chiffrement, qui relève de la simple communication privée des citoyens entre eux, de manière locale ou mondiale, par contre, il y a problème avec l'autoritarisme étatique, la surveillance de masse, l'industrie de l'armement, les politiques guerrières et l'uniformisation politique qui relève plus du sectarisme de pensée nationaliste et communautaire que de la démocratie ouverte dans un monde qui est commun à tous les êtres humains.

[LSMetag]

Il y a des lois limitant la taille des clés de chiffrement. Mais il suffit d'imbriquer les algos légaux ou d'en créer de nouveau. Le chiffrement peut s'effectuer coté client avec une clé générée dynamiquement ce qui empêche l'interception d'une clé par un tiers et la non possibilité de connaitre les données coté serveur.

Un chiffrement avec du Javascript obfusqué a mort (en bytecode par exemple) via une clé se basant sur une adresse MAC, ca peut le faire.

Soit tu deviens liberticide en interdisant tout chiffrement ou en imposant la création de backdoors (2 aveux d'incompétence), soit tu mets les moyens pour avoir des supercalculateurs et de bons hackers qui progresseront sans cesse.

[MikeRowSoft]

C'est comme les immatriculation des automobiles.
Soit pair, soit impair. (zéro étant ?)
Cela dit se n'est pas la période ? (il fait chaud, c'est pollué et en plus c'est valable tous les jours.)
Bonne vacances à ceux qui y sont encore et bon courage à ceux qui travail.

[Jipété]

C'est comme les immatriculations des automobiles.
Soit pair, soit impair. (zéro étant ?)

Moi je dirais pair, car comme il n'est jamais tout seul dans ce contexte, il est obligatoirement précédé d'un autre chiffre et l'ensemble forme un nombre pair et voilà.
En plus ça équilibre la balance : 5 nombres impairs et 5 nombres pairs, du coup, même si, d'un pur point de vue mathématique, ça (avec un c cédille) n'est pas vraiment vrai.

[...] bon courage à ceux qui travail.

À ceux qui lisent à la va-vite, merci de ne pas reproduire ce genre d'abomination qui, hélas, se répand comme une traînée de poudre...
ceux qui travaillent , du verbe travailler, et oui...

Les principes exactes et naturels des matériaux étant régis par des comportements physiques et chimiques, les principes exactes et naturels de la biologie ne sont pas forcément les principes exactes et naturels de l’ingénierie.

[sneb5757]

Il y a des lois limitant la taille des clés de chiffrement. Mais il suffit d'imbriquer les algos légaux ou d'en créer de nouveau. Le chiffrement peut s'effectuer coté client avec une clé générée dynamiquement ce qui empêche l'interception d'une clé par un tiers et la non possibilité de connaitre les données coté serveur.

Un chiffrement avec du Javascript obfusqué a mort (en bytecode par exemple) via une clé se basant sur une adresse MAC, ca peut le faire.

Soit tu deviens liberticide en interdisant tout chiffrement ou en imposant la création de backdoors (2 aveux d'incompétence), soit tu mets les moyens pour avoir des supercalculateurs et de bons hackers qui progresseront sans cesse.

Quel limite ?

La LCEN a libéré l'usage du chiffre il y'a 10 ans il est possible de chiffré avec une clé de n'importe quel longueur. La seule contrainte est qu'il faut fournir la clé aux autorités si nécessaire.

Je ne comprend pas ce protocol cryptographique et cette histoire de chiffrement côté client. Comment l'interlocuteur peut il déchiffrer le message ?

[LSMetag]

Quel limite ?

La LCEN a libéré l'usage du chiffre il y'a 10 ans il est possible de chiffré avec une clé de n'importe quel longueur. La seule contrainte est qu'il faut fournir la clé aux autorités si nécessaire.

Je ne comprend pas ce protocol cryptographique et cette histoire de chiffrement côté client. Comment l'interlocuteur peut il déchiffrer le message ?

On peut dépasser le 2048 bits pour les clés ? On m'avait dit que sinon c'était considéré comme un cryptage de guerre.

Un petit exemple de cryptage côté client (y a mieux mais je ne trouve plus) :

https://jscrambler.com/fr/how-it-works

Il suffit d'utiliser du cryptage côté Javascript avec des infos côté client, de le transmettre via une interface sécurisée (style WebSocket Secured), et d'obfusquer le code Javascript.
Les données sont encodées au niveau client, avec une clé que toi seul connais, le serveur reçoit du déjà crypté (mot de passe crypté en amont + SSL) sans savoir comment le décrypter et le stocke donc tel quel, et on ne sait pas ce que ton Javascript a fait.
Ca c'est le cadre d'un site web.

Dans le cadre d'un Chat, il suffit de s'échanger sa clé secrète de la même manière, mais encryptée (c'est à dire qu'il faudrait faire "if SHA256('clé') pour tester la validité de la clé (ou te connecter) côté serveur. Cette clé cryptée d'après ton matos (par exemple) est quasiment inviolable, puisqu'elle est cryptée avant même d'être envoyée au serveur pour contrôle et ne repose sur aucune vraie logique.

[Neckara]

Chiffrement* chiffrer* chiffrée*

On peut dépasser le 2048 bits pour les clés ? On m'avait dit que sinon c'était considéré comme un cryptage de guerre.

Non, cela fait un petit bout de temps qu'il n'y a plus de limitations pour un usage "normal".

et d'obfusquer le code Javascript

La sécurité par l'obscurité ne vaut pas grand chose.

mais encryptée (c'est à dire qu'il faudrait faire "if SHA256('clé') pour tester la validité de la clé

Hein ?

Cette clé cryptée d'après ton matos (par exemple) est quasiment inviolable, puisqu'elle est cryptée avant même d'être envoyée au serveur pour contrôle et ne repose sur aucune vraie logique.

.

Ou plus simplement, tu utilises des algorithmes connus et éprouvés de chiffrement symétriques avec échanges de clés basés sur du chiffrement asymétrique. Du TLS en quelque sorte, possiblement étendu pour ajouter le support d'autres algorithmes si besoin.

[LSMetag]

Chiffrement* chiffrer* chiffrée*

J'accepte la flagélation

Non, cela fait un petit bout de temps qu'il n'y a plus de limitations pour un usage "normal".

Tant mieux mais ça ne change pas grand chose vu qu'ils ont déjà du mal avec du 1024 bits.

La sécurité par l'obscurité ne vaut pas grand chose.

Ce n'est qu'une couche par dessus les autres. Si je fais quelque chose d'un peu sensible côté client, j'ai envie de le cacher, et bien. Il y a maintenant des solutions vraiment efficaces. Elles ne font pas que chiffrer le code de différentes façons, elles ajoutent des morceaux de code inutiles (leurres) ou qui font planter en cas de tentative de modification,... Bref, de quoi faire cogiter énormément. J'attends bien sûr Web Assembly pour avoir du vrai ByteCode.

Après de toute façon dans ton Javascript, tu peux par exemple créer statiquement (par l'utilisateur) ou dynamiquement un "mot de passe maître". Tu utilises ensuite une bibliothèque pour chiffrer ce mot de passe maître + autres infos (login) que tu envoie (https://github.com/emn178/js-sha256). Le serveur reçoit les données chiffrées via le protocole SSL (d'où les WebSocket Secured), surcouche je sais. Le serveur a dans sa base uniquement des données chiffrées. Tout ce qu'il sait, c'est quel algorithme de chiffrage a été utilisé côté client (via des specs). Et donc, quand le client tape son id et son mot de passe, les chaînes chiffrées sont envoyées au serveur, qui va les comparer avec les chaînes chiffrées dans la base de données. Il n'y aura aucune donnée stockée en clair, qui circulera en clair, et qui ne pourront, au retour chez le client n'être déchiffrées que derrière un Javascript obfusqué à mort. L'utilisateur ne pourra pas réclamer son mot de passe et son login en cas de perte.

Hein ?

.

Ou plus simplement, tu utilises des algorithmes connus et éprouvés de chiffrement symétriques avec échanges de clés basés sur du chiffrement asymétrique. Du TLS en quelque sorte, possiblement étendu pour ajouter le support d'autres algorithmes si besoin.

Oui tu peux faire plus simple. Moi ça sort de mon cerveau en suractivité qui aime bien avoir des gardes fous dans tous les sens. C'est qu'un exemple parmi d'autres (très probablement meilleurs) de chiffrement de bout en bout. L'utilisateur crée son pass (ou on peut le créer à la Microsoft, selon la signature matérielle), et après plus personne ne sait ce qu'il devient, et seul quelqu'un qui connaît le pass en clair (l'utilisateur de base, ou celui à qui il a transmis le pass (pour un chat par exemple)

Après tout, si le code Javascript est "éclairci", l'attaquant sait comment est créé le pass. Si le transfert n'est pas sécurisé ensuite, il intercepte la clé chiffrée. S'il connaît et la méthode de chiffrement et la clé chiffrée et certaines habitudes de l'utilisateur, il peut parfaitement récupérer le mot de passe, dont même côté serveur on n'a pas connaissance.

[Neckara]

Ce n'est qu'une couche par dessus les autres.

On en a pas vraiment besoin.

Si je fais quelque chose d'un peu sensible côté client, j'ai envie de le cacher, et bien.

Non, la sécurité par l'obscurité ne vaut pas grand chose, l'utiliser pour tenter de fournir une quelconque sécurité serait une faille en elle-même.

elles ajoutent des morceaux de code inutiles (leurres) ou qui font planter en cas de tentative de modification

Et si on modifie tout simplement le script en entier ? .


Ce que tu nous montres, c'est plus pour les applications propriétaires qui ne veulent pas que le citoyen voit, copie ou modifie leur code. Rien à voir avec une quelconque sécurité pour des opérations cryptographique.

Après de toute façon dans ton Javascript, tu peux par exemple créer statiquement (par l'utilisateur) ou dynamiquement un "mot de passe maître". Tu utilises ensuite une bibliothèque pour chiffrer ce mot de passe maître + autres infos (login) que tu envoie (https://github.com/emn178/js-sha256). Le serveur reçoit les données chiffrées via le protocole SSL (d'où les WebSocket Secured), surcouche je sais. Le serveur a dans sa base uniquement des données chiffrées. Tout ce qu'il sait, c'est quel algorithme de chiffrage a été utilisé côté client (via des specs). Et donc, quand le client tape son id et son mot de passe, les chaînes chiffrées sont envoyées au serveur, qui va les comparer avec les chaînes chiffrées dans la base de données. Il n'y aura aucune donnée stockée en clair, qui circulera en clair, et qui ne pourront, au retour chez le client n'être déchiffrées que derrière un Javascript obfusqué à mort. L'utilisateur ne pourra pas réclamer son mot de passe et son login en cas de perte.

Pour stocker le mot de passe, il vaut mieux utiliser une fonction de hachage. On a même des protocoles encore plus performants à base de 0-knowledge.

Le fait de stocker les données chiffrées sur un serveur avec une clé seulement connue de l'utilisateur et possiblement dérivée de son mot de passe est en effet une bonne sécurité pour protéger sa vie privée.
Cependant, utiliser JavaScript sur le navigateur du client me semble quelque peu dangereux, le navigateur pouvant être corrompu. Un client lourd me semble quelque peu plus "sûr".

Moi ça sort de mon cerveau en suractivité qui aime bien avoir des gardes fous dans tous les sens.

Je comprend, cependant tes propos ne sont pas toujours très clairs.
De plus, penser et proposer de nouveaux modèle de sécurités demande de très fortes connaissances dans le domaine.

Après tout, si le code Javascript est "éclairci", l'attaquant sait comment est créé le pass.

Si cela pose problème, la méthode de création du pass comporte donc des failles.
Il convient donc de corriger ces failles plutôt que de vouloir les cacher en offusquant le code.

[LSMetag]

...

Désolé je sais que je ne suis pas forcément clair. J'écris au kilomètre ce que je pense sur le moment. Et je ne suis pas spécialiste c'est vrai, mais j'essaie de proposer des idées et de progresser.

Le client lourd c'est mieux en effet pour les applis de chat et tout ça. Après pour un site web, je ne vois pas trop d'autre solution. Je n'ai pas envie de forcer l'utilisateur à installer une extension ou une VM. Je ne suis pas convaincu que l'obfuscation ne soit pas une bonne mesure de sécurité, si la lib utilisée est sérieuse et maintenue. Tu n'es pas non plus tenu d'utiliser une librairie tierce. Il y a des sites où tu t'abonnes et qui fonctionnent un peu comme un cloud dédié à l'obfuscation/chiffrement perpétuel, avec monitoring, d'un code.

L'attaquant peut bien essayer de modifier le code chiffré ou d'injecter dans l'URL (que tu peux protéger par exemple avec du Base64). Il ne fera que planter l'application localement et momentanément.

Après oui, le hachage est un très bon moyen aussi. Mais ce qui m'intéresse c'est que le serveur ne puisse pas voir les données en clair. Question de vie privée et de confidentialité en effet ^^

C'est pour celà justement que les autorités se lèvent pour essayer de "contrer" ce genre de méthodes.

Je pense qu'il y a peu de méthodes de sécurité inviolables. Comme les algorithmes de chiffrage. Truecrypt (et maintenant VeryCript) a comblé ça en imbriquant les solutions existantes de chiffrage, ce qui l'a fait "interdire" par le FBI.
Soit tu as une excellente solution, soit tu imbriques d'autres solutions.

[Mandotnet]

Tous les systèmes de cryptage actuels tomberont très prochainement. La NSA, la Chine et sans doute d'autres grandes nations ont déjà (et travaillent encore) sur la conception de supercalculateurs quantiques.

Voilà ce que la France doit proposer à l'Europe. Au delà de l'enjeux de sécurité, c'est toute notre économie qui est menacée.

(Les programmes révélés par Snowden montrent que déjà les USA conservent les échanges qui sont actuellement cryptés dans l'objectif de les décrypter plus tard).

Enfin je ne parle même pas des progrès que cela permettrait de réaliser dans tous les domaines de recherche...

[Neckara]

Et je ne suis pas spécialiste c'est vrai, mais j'essaie de proposer des idées et de progresser.

Mais cela n'est pas d'une grande aide si tu n'as pas connaissance de l'état de l'art du domaine.
La communauté scientifiques a déjà apporté des réponses à plusieurs questions et a déjà exploré beaucoup de pistes. Plutôt que de proposer ses propres idées, il faudrait déjà voir ce qui a été fait de ce coté là.

L'attaquant peut bien essayer de modifier le code chiffré ou d'injecter dans l'URL (que tu peux protéger par exemple avec du Base64). Il ne fera que planter l'application localement et momentanément.

Pourquoi tant vouloir à cacher des failles plutôt que de les corriger ?
S'il est possible de faire des injections dans l'URL, c'est déjà que ton site a de gros problèmes de sécurité.

Après oui, le hachage est un très bon moyen aussi. Mais ce qui m'intéresse c'est que le serveur ne puisse pas voir les données en clair.

Autant utiliser une fonction non-inversible .

Soit tu as une excellente solution, soit tu imbriques d'autres solutions.

Cela peut être très dangereux au niveau de la sécurité, il ne faut pas tout imbriquer n'importe comment.

Tous les systèmes de cryptage actuels tomberont très prochainement. La NSA, la Chine et sans doute d'autres grandes nations ont déjà (et travaillent encore) sur la conception de supercalculateurs quantiques.

Et on a déjà une nouvelle génération d'algorithmes prêt à l'emploi.

Au passage, j'ai entendu dire que les ordinateurs quantiques sont une menace aux algorithmes de chiffrement à clé publique, mais que le chiffrement symétrique n'est pas menacé.

[LSMetag]

Mais cela n'est pas d'une grande aide si tu n'as pas connaissance de l'état de l'art du domaine.
La communauté scientifiques a déjà apporté des réponses à plusieurs questions et a déjà exploré beaucoup de pistes. Plutôt que de proposer ses propres idées, il faudrait déjà voir ce qui a été fait de ce coté là.

Je suis d'accord mais c'est aussi pour concevoir mes applications que je raisonne tout d'abord en faisant abstraction de ce qui existe, même si je le connais, pour ensuite regarder si ce qui se fait correspond à mon besoin. Mais oui, je n'ai pas une grande connaissance mais cherche à appliquer ceci à un projet personnel

Pourquoi tant vouloir à cacher des failles plutôt que de les corriger ?

Ca n'implique pas "coder comme un sagouin" ! Tu code sérieusement en prenant soin de gérer les failles d'injection JS, SQL ou XHR (c'est juste des exemples parmi d'autres). Après si je travaille côté client sur une partie importante (ce qu'on ne devrait pas faire, je le sais, mais voila ^^), il faut aussi cacher son code pour qu'on n'ait pas idée du mode d'action de l'application, aussi bien codée et protégée soit-elle. C'est le problème du côté client. Ce ne sera plus un problème avec Web Assembly, que j'utiliserai à mon avis beaucoup.

S'il est possible de faire des injections dans l'URL, c'est déjà que ton site a de gros problèmes de sécurité.

Justement, je parlais des solutions typiques habituellement utilisées pour contrer ça

Autant utiliser une fonction non-inversible .

C'est ce dont je parlais.

Cela peut être très dangereux au niveau de la sécurité, il ne faut pas tout imbriquer n'importe comment.
Et on a déjà une nouvelle génération d'algorithmes prêt à l'emploi.

Evidemment, ça doit être fait avec le plus grand soin et une architecture en béton, par un spécialiste (pas moi donc, mais je dois essayer pour mon projet perso, SAUF si les solutions new-age sont super)

Au passage, j'ai entendu dire que les ordinateurs quantiques sont une menace aux algorithmes de chiffrement à clé publique, mais que le chiffrement symétrique n'est pas menacé.

C'est une bonne chose pour que les services secrets arrêtent de nous demander des backdoors. Je ne pense pas qu'un simple hacker puisse se payer ça. C'est un budget d'Etat.

[Neckara]

Je suis d'accord mais c'est aussi pour concevoir mes applications que je raisonne tout d'abord en faisant abstraction de ce qui existe, même si je le connais, pour ensuite regarder si ce qui se fait correspond à mon besoin. Mais oui, je n'ai pas une grande connaissance mais cherche à appliquer ceci à un projet personnel

Le problème, c'est que tu risques de réinventer la roue, voir même d'inventer la roue carrée et toute cabossée.

Il y a des années de recherches sur le sujet, avec des chercheurs aux connaissances très pointues qui ont déjà pu démontrer en quoi ce que tu essayes de faire est une mauvaise idée.

Après si je travaille côté client sur une partie importante (ce qu'on ne devrait pas faire, je le sais, mais voila ^^), il faut aussi cacher son code pour qu'on n'ait pas idée du mode d'action de l'application, aussi bien codée et protégée soit-elle. C'est le problème du côté client.

Non, ça c'est avant tout un problème de conception. La sécurité par l'obscurité n'est pas une bonne sécurité, cela fait consensus dans le milieu depuis un bon bout de temps.

Qu'on le protège pour des raisons de licences, pourquoi pas. Mais penser offrir une sécurité en faisant en sorte que l'utilisateur "n'ait pas idée du mode d'action" est au contraire générateur de failles, faisant moins attention à la sécurité réelle de l'application vu que "le code est offusqué".
Une application correctement pensée n'a pas besoin d'offuscation pour sa sécurité.

C'est ce dont je parlais.

Une fonction de chiffrement est inversible. Tu parlais bien dans tes posts précédent d'utiliser une fonction de chiffrement pour cela.

SAUF si les solutions new-age sont super

Tu as déjà plein de solutions à ce niveau là. Tu as même des tentatives sur le chiffrement homomorphique.
Bref, tu as beaucoup de littérature très intéressante dans ce domaine.

[LSMetag]

...

Je vois en effet que j'ai beaucoup à lire ^^ Merci pour toutes ces infos. Et en effet, compter sur de l'obscurcissement de code n'est pas une sécurité sur laquelle on peut se reposer. On est bien d'accord. Je voyais ça comme une couche finale sur un vrai travail de qualité.

Oui c'est sûr que les chercheurs qui ont planché des années ont créé des trucs énorme par rapport à un mec lambda qui a cherché pendant quelques heures ^^'

Tu as raison, c'était inversible. J'avais pas les yeux en face de trous. Dans ce cas, comment retranscrire des données chez un client avec du non inversible ? Pour faire du login/mot de passe, c'est bien mais ce n'est valable que pour de l'émission. Tu es obligé de déchiffrer ce que tu reçois.

Après, pour les problèmes de conception, je ne peux pas trop dire. Comment empêcher un serveur de connaître la moindre chose sur toi, rendre caduques les possibles interceptions en cas de faille zéro day d'un protocle de transfert, tout en empêchant également le reverse engineering ?

[Neckara]

Après, pour les problèmes de conception, je ne peux pas trop dire. Comment empêcher un serveur de connaître la moindre chose sur toi, rendre caduques les possibles interceptions en cas de faille zéro day d'un protocle de transfert, tout en empêchant également le reverse engineering ?

Avoir une architecture décentralisée (?).

[LSMetag]

Avoir une architecture décentralisée (?).

Idée très intéressante. Mais quid de l'apparition de données en clair côté serveur, passibles de réquisition par les FAI ou services secrets ?

[manu007]

C'est pas en interdisant le chiffrage des messages que l'on va en finir avec le terrorisme, mais en ayant des services de renseignement plus efficaces et mieux organisés que les terroristes. Mais enfin, le terrorisme a bon dos et c'est l'excuse parfaite pour faire ce que le politiciens adorent, interdire et empêcher la societé d'evoluer vers lá oú elle veut aller.