> Fessant un ptit peut de pilotage moi même, j'ai comme un doute dans > ton explication, parce que pour poser l'avion,
C'est un drone, pas un avion. Il est autopiloté : Quand son GPS lui dit qu'il se trouve au dessus de sa base, c'est lui qui réalise tout seul l a manuvre pour se poser.
J'ai déjà vu des être humain derrière des consoles piloter un drone ... Remarque que dans votre raisonnement ils ont trouvés deux inconnu, la longitude et la latitude, pour que le drone croit qu'il est la maison et passe en mode atterrissage, de plus le système GPS, pour la partie militaire qui sont des fréquences différente de la partie civil que le commun des mortel utilise ne serait pas crypté (bon !) Donc les chinois ou les russes ont des radars très performant qui ne sont pas déjouer par la furtivité de ces derniers drones ! ( que les iraniens ont acheté ... ) Se ne sont que des hypothèses ni les contributeurs ni moi ne seront informés ... ( mais l'armement va faire des progrès ) Au passage, je ne crois pas que les algos utilisés par le drone soi publié !
> Enfin tu peux voir qu'il n'est pas toujours bon de publier les algos, > parce que dans ce cas de figure, certes moi j'ai pas les capacités me s > d'autre seront pressé de partager leur exploit ....
Comme bus.error l'a signalé, en fait maintenant CI Plus le successeur d e Mediaguard publie officiellement tous les algos, ce qui est une très excellente chose.
Oui, j'ai pensé chercher une faille comme celle publié par le professeur Ross Anderson en 2010 sur les visas et le code pin. Remarque que cette faille n'a rien avoir avec l'algo AES-128, et pas sur que CI + utilise la même chose !
Tu ne semble pas faire la différence entre publier un algo et le casser : - Un algo sérieux, c'est un algo qui reste incassable après avoir é té publié, toute la sécurité reposant sur des clés qui sont des donn ées, et non des algo.
Oui, mais là tu as l'algo, le message chiffré, le message déchiffré ... ( il manque clés privée et clés public, peut on envisager une attaque de l'homme du milieux même si l'échange de clé passe par un algo de hash ? ) Alors que ton raisonnement c'est j'ai l'algo et le message chiffré donc trois inconnus ... ( il me semble que c'est donc plus facile à casser ? )
- A contrario, l'histoire de la crypto démontre à répétition que tous les algo que l'on cherchait à cacher ont été cassé facilement une fois révélé. Le type qui a suffisamment confiance en soi pour penser que l'algo qu'il a inventé et pas pas publié est solide a toutes les chan ces d'avoir complètement tort. Y compris quand il travaille pour un gouvernement d'ailleurs.
Ce que l'on connait c'est en général ce que les universitaires publie, pour le reste par expérience du genre humain, j'ai toujours des doutes ... ( sinon c'est juste de la curiosité je ne me lancerai pas dans une telle aventure !)
Ptilou
Bonjour,
On 26 jan, 15:40, Jean-Marc Desperrier <jmd...@gmail.com> wrote:
ptilou a écrit :
> Fessant un ptit peut de pilotage moi même, j'ai comme un doute dans
> ton explication, parce que pour poser l'avion,
C'est un drone, pas un avion. Il est autopiloté : Quand son GPS lui dit
qu'il se trouve au dessus de sa base, c'est lui qui réalise tout seul l a
manuvre pour se poser.
J'ai déjà vu des être humain derrière des consoles piloter un
drone ...
Remarque que dans votre raisonnement ils ont trouvés deux inconnu, la
longitude et la latitude, pour que le drone croit qu'il est la maison
et passe en mode atterrissage, de plus le système GPS, pour la partie
militaire qui sont des fréquences différente de la partie civil que le
commun des mortel utilise ne serait pas crypté (bon !)
Donc les chinois ou les russes ont des radars très performant qui ne
sont pas déjouer par la furtivité de ces derniers drones ! ( que les
iraniens ont acheté ... )
Se ne sont que des hypothèses ni les contributeurs ni moi ne seront
informés ...
( mais l'armement va faire des progrès )
Au passage, je ne crois pas que les algos utilisés par le drone soi
publié !
> Enfin tu peux voir qu'il n'est pas toujours bon de publier les algos,
> parce que dans ce cas de figure, certes moi j'ai pas les capacités me s
> d'autre seront pressé de partager leur exploit ....
Comme bus.error l'a signalé, en fait maintenant CI Plus le successeur d e
Mediaguard publie officiellement tous les algos, ce qui est une très
excellente chose.
Oui, j'ai pensé chercher une faille comme celle publié par le
professeur Ross Anderson en 2010 sur les visas et le code pin.
Remarque que cette faille n'a rien avoir avec l'algo AES-128, et pas
sur que CI + utilise la même chose !
Tu ne semble pas faire la différence entre publier un algo et le casser :
- Un algo sérieux, c'est un algo qui reste incassable après avoir é té
publié, toute la sécurité reposant sur des clés qui sont des donn ées, et
non des algo.
Oui, mais là tu as l'algo, le message chiffré, le message
déchiffré ... ( il manque clés privée et clés public, peut on
envisager une attaque de l'homme du milieux même si l'échange de clé
passe par un algo de hash ? )
Alors que ton raisonnement c'est j'ai l'algo et le message chiffré
donc trois inconnus ...
( il me semble que c'est donc plus facile à casser ? )
- A contrario, l'histoire de la crypto démontre à répétition que tous
les algo que l'on cherchait à cacher ont été cassé facilement une fois
révélé. Le type qui a suffisamment confiance en soi pour penser que
l'algo qu'il a inventé et pas pas publié est solide a toutes les chan ces
d'avoir complètement tort. Y compris quand il travaille pour un
gouvernement d'ailleurs.
Ce que l'on connait c'est en général ce que les universitaires publie,
pour le reste par expérience du genre humain, j'ai toujours des
doutes ...
( sinon c'est juste de la curiosité je ne me lancerai pas dans une
telle aventure !)
> Fessant un ptit peut de pilotage moi même, j'ai comme un doute dans > ton explication, parce que pour poser l'avion,
C'est un drone, pas un avion. Il est autopiloté : Quand son GPS lui dit qu'il se trouve au dessus de sa base, c'est lui qui réalise tout seul l a manuvre pour se poser.
J'ai déjà vu des être humain derrière des consoles piloter un drone ... Remarque que dans votre raisonnement ils ont trouvés deux inconnu, la longitude et la latitude, pour que le drone croit qu'il est la maison et passe en mode atterrissage, de plus le système GPS, pour la partie militaire qui sont des fréquences différente de la partie civil que le commun des mortel utilise ne serait pas crypté (bon !) Donc les chinois ou les russes ont des radars très performant qui ne sont pas déjouer par la furtivité de ces derniers drones ! ( que les iraniens ont acheté ... ) Se ne sont que des hypothèses ni les contributeurs ni moi ne seront informés ... ( mais l'armement va faire des progrès ) Au passage, je ne crois pas que les algos utilisés par le drone soi publié !
> Enfin tu peux voir qu'il n'est pas toujours bon de publier les algos, > parce que dans ce cas de figure, certes moi j'ai pas les capacités me s > d'autre seront pressé de partager leur exploit ....
Comme bus.error l'a signalé, en fait maintenant CI Plus le successeur d e Mediaguard publie officiellement tous les algos, ce qui est une très excellente chose.
Oui, j'ai pensé chercher une faille comme celle publié par le professeur Ross Anderson en 2010 sur les visas et le code pin. Remarque que cette faille n'a rien avoir avec l'algo AES-128, et pas sur que CI + utilise la même chose !
Tu ne semble pas faire la différence entre publier un algo et le casser : - Un algo sérieux, c'est un algo qui reste incassable après avoir é té publié, toute la sécurité reposant sur des clés qui sont des donn ées, et non des algo.
Oui, mais là tu as l'algo, le message chiffré, le message déchiffré ... ( il manque clés privée et clés public, peut on envisager une attaque de l'homme du milieux même si l'échange de clé passe par un algo de hash ? ) Alors que ton raisonnement c'est j'ai l'algo et le message chiffré donc trois inconnus ... ( il me semble que c'est donc plus facile à casser ? )
- A contrario, l'histoire de la crypto démontre à répétition que tous les algo que l'on cherchait à cacher ont été cassé facilement une fois révélé. Le type qui a suffisamment confiance en soi pour penser que l'algo qu'il a inventé et pas pas publié est solide a toutes les chan ces d'avoir complètement tort. Y compris quand il travaille pour un gouvernement d'ailleurs.
Ce que l'on connait c'est en général ce que les universitaires publie, pour le reste par expérience du genre humain, j'ai toujours des doutes ... ( sinon c'est juste de la curiosité je ne me lancerai pas dans une telle aventure !)
Ptilou
Jean-Marc Desperrier
ptilou a écrit :
Oui, mais là tu as l'algo, le message chiffré, le message déchiffré ... [...] Alors que ton raisonnement c'est j'ai l'algo et le message chiffré donc trois inconnus ... ( il me semble que c'est donc plus facile à casser ? )
Un algorithme sérieux résiste même placé dans les pires conditions imaginables, sinon il faut l'abandonner.
Exemple non pas avec l'algo lui même à strictement parler, mais avec le chaînage CBC. On s'est rendu compte il y a quelques années que pouvoir insérer un contenu en clair choisi dans une partie du flux, et pouvoir modifier le contenu chiffré, ainsi qu'observer la réaction du serveur en face permettait de déduire des informations sur l'autre partie du flux non connue, quand le vecteur d'initialisation était fixe. En première approche on peut raisonnablement avoir l'impression que cette faiblesse est inutilisable en pratique.
Mais avec l'attaque BEAST, on a réalisé qu'en fait ce n'est pas le cas dans le cas d'un attaquant qui achète une page de publicité, qui va être insérée dans un site web, dont il contrôlera alors une partie du contenu et il se trouvera dans les conditions idéales pour réellement mettre en place ce type d'attaque pour récupérer des info du type une valeur de cookie.
Bref, si l'algorithme et sa mise en œuvre ne sont pas blindés contre *tous* les cas de figure, y compris celui du clair choisi, on finit toujours par avoir des emmerdes. Pour préciser, le problème n'était pas dans AES qui résiste aux attaques à clair connu, mais dans CBC avec un vecteur d'initialisation connu => conclusion, on aurait du abandonner depuis longtemps CBC avec vecteur d'initialisation connu
Quelques références au sujet de cette attaque : http://www.journaldunet.com/solutions/securite/securite-du-web-ssl-et-https-pirate/chiffrement-ssl-casse.shtml http://www.bortzmeyer.org/beast-tls.html http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html http://eprint.iacr.org/2004/111.pdf
ptilou a écrit :
Oui, mais là tu as l'algo, le message chiffré, le message
déchiffré ... [...]
Alors que ton raisonnement c'est j'ai l'algo et le message chiffré
donc trois inconnus ...
( il me semble que c'est donc plus facile à casser ? )
Un algorithme sérieux résiste même placé dans les pires conditions
imaginables, sinon il faut l'abandonner.
Exemple non pas avec l'algo lui même à strictement parler, mais avec le
chaînage CBC. On s'est rendu compte il y a quelques années que pouvoir
insérer un contenu en clair choisi dans une partie du flux, et pouvoir
modifier le contenu chiffré, ainsi qu'observer la réaction du serveur en
face permettait de déduire des informations sur l'autre partie du flux
non connue, quand le vecteur d'initialisation était fixe. En première
approche on peut raisonnablement avoir l'impression que cette faiblesse
est inutilisable en pratique.
Mais avec l'attaque BEAST, on a réalisé qu'en fait ce n'est pas le cas
dans le cas d'un attaquant qui achète une page de publicité, qui va être
insérée dans un site web, dont il contrôlera alors une partie du contenu
et il se trouvera dans les conditions idéales pour réellement mettre en
place ce type d'attaque pour récupérer des info du type une valeur de
cookie.
Bref, si l'algorithme et sa mise en œuvre ne sont pas blindés contre
*tous* les cas de figure, y compris celui du clair choisi, on finit
toujours par avoir des emmerdes.
Pour préciser, le problème n'était pas dans AES qui résiste aux attaques
à clair connu, mais dans CBC avec un vecteur d'initialisation connu =>
conclusion, on aurait du abandonner depuis longtemps CBC avec vecteur
d'initialisation connu
Quelques références au sujet de cette attaque :
http://www.journaldunet.com/solutions/securite/securite-du-web-ssl-et-https-pirate/chiffrement-ssl-casse.shtml
http://www.bortzmeyer.org/beast-tls.html
http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
http://eprint.iacr.org/2004/111.pdf
Oui, mais là tu as l'algo, le message chiffré, le message déchiffré ... [...] Alors que ton raisonnement c'est j'ai l'algo et le message chiffré donc trois inconnus ... ( il me semble que c'est donc plus facile à casser ? )
Un algorithme sérieux résiste même placé dans les pires conditions imaginables, sinon il faut l'abandonner.
Exemple non pas avec l'algo lui même à strictement parler, mais avec le chaînage CBC. On s'est rendu compte il y a quelques années que pouvoir insérer un contenu en clair choisi dans une partie du flux, et pouvoir modifier le contenu chiffré, ainsi qu'observer la réaction du serveur en face permettait de déduire des informations sur l'autre partie du flux non connue, quand le vecteur d'initialisation était fixe. En première approche on peut raisonnablement avoir l'impression que cette faiblesse est inutilisable en pratique.
Mais avec l'attaque BEAST, on a réalisé qu'en fait ce n'est pas le cas dans le cas d'un attaquant qui achète une page de publicité, qui va être insérée dans un site web, dont il contrôlera alors une partie du contenu et il se trouvera dans les conditions idéales pour réellement mettre en place ce type d'attaque pour récupérer des info du type une valeur de cookie.
Bref, si l'algorithme et sa mise en œuvre ne sont pas blindés contre *tous* les cas de figure, y compris celui du clair choisi, on finit toujours par avoir des emmerdes. Pour préciser, le problème n'était pas dans AES qui résiste aux attaques à clair connu, mais dans CBC avec un vecteur d'initialisation connu => conclusion, on aurait du abandonner depuis longtemps CBC avec vecteur d'initialisation connu
Quelques références au sujet de cette attaque : http://www.journaldunet.com/solutions/securite/securite-du-web-ssl-et-https-pirate/chiffrement-ssl-casse.shtml http://www.bortzmeyer.org/beast-tls.html http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html http://eprint.iacr.org/2004/111.pdf
