J'ai écrit un peu vite. Je ne connais pas Akka. Pour cassandra, il y a une tentative de réécriture en C++ qui annonce des perf bien supérieur à la version d'origine.
Dans les applications temps réel, le plus simple est de ne pas faire d'allocation mémoire, tout est statique. Ainsi, il n'y a jamais de problème de new ou de delete, ni de latence associé.
Unity c'est ~20 millions de ligne de C++, et un jeu c# rajoute ~100k ligne dessus. La partie temps réel dure est à 100% en C++.
Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand. Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros. Avec l'augmentation de la RAM, un GC n'est pas raisonnable. C'est amusant de lire les exploits techniques des systèmes de bases de données en "RAM". Ce sont des grappes de x86, avec des To de RAM. Il est plus rapide de faire un reset que de se prendre le full GC de java. Il y a donc une foule de technique pour l'éviter.
si on lit les américains sur la culture des armes. Ils font clairement la distinction entre 3 types d'armes.
Les armes de point qui peuvent se cacher, qui est typiquement une arme de voyou et de voleur. C'est ce genre d'arme qui fait le plus de morts au USA. J'imagine qu'un jour ils arriveront à les faire enregistrer.
Il y a les armes longues, type fusil de chasse. Visible, pour "protéger ta famille". Bref, le genre de machin qu'un bon père de famille a chez lui, voir dans son camion. Il sera presque impossible pour le législateur de demander un enregistrement de ce genre d'arme, sans être vu comme un moyen d'aller ensuite les prendre et d’empêcher l'amériain moyen de se défendre.
Il y a les armes automatiques, ou les gros chargeurs, ou les kit pour transformer une arme longue en arme automatique. C'est l'arme des tueries de masse, mais ce n'est pas le type d'arme qui fait le plus de morts. Beaucoup sont pour l'interdiction de vente de ce genre d'armes.
Bref, vu le nombre d'arme en circulation là-bas, l'interdiction n'aurait aucun sens. Par contre, une segmentation de la réglementation en fonction du type d'arme seraient beaucoup mieux accepté.
J'ai adoré le coté, "je fais un serveur web applicatif en 10 lignes, qui tient la charge". Mais bon, j'ai ensuite vu tout ce qu'il fallait écrire pour utiliser un truc comme go-kit. C'est tellement verbeux, que certains ont essayé d'écrire des générateurs de code. Mais aucun n'est vraiment finalisé.
Que go est simple et donc peut devenir très verbeux, que si on a les type sum et la généricité sous la main, je comprends que l'on a pas envie de revenir à Golang.
si la précision est réellement limité sur la mesure, cela rend le DPA moisn efficace, bien sûr.
Le 2ième point oublié, c'est la possibilité de pirater linky et qu'un pirate installe un firmware de son cru. A priori, il a juste à broadcaster sur la ligne 220 en CPL.
quand je les avait appeler, il m'avait demandé combien de personne mon app devait concerner. quand je leur ai dis un seul, ma boite, ils ont dit qu'il ne le faisait pas. "Budget Insight" est bien la seul boite qui utilise le code de weboop pour le bancaire ?
Tu penses à quel genre d'attaque concernant des systèmes protégés par carte à puce ? En général, les attaques les plus bête sont simplement un bug dans le soft de gestion. J'ai mis vu des implémentations hardware du driver de lien série pour éviter des attaques dessus (genre glitch d'alimentation sur la fonction qui demande la version (une string) qui permet de faire sauter le test de fin de boucle de copie de la string pour continuer de lire la suite de la mémoire).
Pour avoir bosser pour le labo de canal+ sur le sujet, je peux dire qu'il y a un monde entre une carte à puce, et un microcontrôleur classique. Bien sur, je ne dirais pas que c'est impossible, mais conceptuellement être capable de sortir un secret d'une carte à puce particulière (et non un secret identique recopié sur 20 puces), c'est vraiment très compliqué, avoir un FIB, un LSM, un AFM, un microscope électronique, n'aide pas vraiment.
Pour faire ça, il faut connaitre parfaitement le modèle de la puce elle-même, voir si elle a une faiblesse. Ensuite, il vaut mieux avoir une autre clef avec le logiciel utilisé dans la cible, pour voir si le soft à une faiblesse. Et ensuite, s'attaquer à la clef cible en question, sachant qu'il y a une haute proba de destruction.
Dans un microcontrôleur, il suffit souvent d'utiliser le JTAG.
La sécurité est forcément par la sécurité car chaque mesure est imparfaite. L'exemple du shield est intéressant. Ils ont fait une version avec un registre il fallait lire et écrire dedans pour voir si un fil était coupé. Mais cela laissait quelques milliers de cycle à l'allumage sans protection. Ensuite, ils ont fait des "versions analogiques" qui mesuraient la résistance du shield pour détecter un by-pass. L'emplacement des détecteurs de laser n'est pas connu, cela oblige l'attaquant a cartographier la puce, pour ne pas taper dedans. Si une sécurité repose sur un nombre secret, si il est connu, cela ne marche plus (clef de chiffrage de la mémoire, ou autre), etc…
Le comportement du CMOS est connu, c'est presque une boite blanche, le seul moyen de planquer quelques choses dedans, c'est de faire une boite et de faire grossir la meule de foin.
Oui si tu passes par budget insight qui gère les modifications des banques, sinon c'est à toi de gérer chaque changement d'interface. Et budget insight vend son truc pour des applications bancaires, pas pour une PME qui veut automatiser sa relation avec sa banque.
Pour autant, d’une part Gnuk ne laisse pas les clefs dénuées de toute protection comme on vient de le voir, et d’autre part la « résistance aux attaques physiques » (tamper resistance) n’est ni l’apanage des cartes à puce, ni absolue. Carte à puce ou pas, il est toujours prudent de considérer qu’un adversaire motivé et équipé pourra extraire des données du jeton, si besoin en dépiautant la puce et en allant directement lire la valeur des bits au microscope.
Oui mais non. Si il y autant de protection dans une carte à puce, ce n'est pas pour faire joli. D'ailleurs, si un secret est unique à une puce, à moins d'un bug, il est impossible de sortir le secret, car il est trop facile de détruire la puce pendant le processus. Ce n'est pas le cas d'un chip normal.
Une carte à puce dispose d'un "shield", une grille que l'on doit "dériver" pour accéder au bus de la FLASH. Une protection de l'alimentation et des pin d'entré pour éviter les glitchs. Ils disposent aussi de capteur de laser qui détruit la mémoire, pour éviter l'injection de faute. Les mémoires internes sont cryptés. Des secrets peuvent être en dur, (genre fonction de dérivation de clef qui ajoute un grand nombre). Si vous voulez ce nombre pour avoir l'algo de dérivation de clef complet, il faut faire du reverse hardware ou avoir des bons contacts dans le service de sécurité du fabricants.
Une fois, j'avais entendu parler d'un "hash hardware" sur un SoC, mais c'était simplement un bloc AES, or AES est connu pour être une mauvaise fonction de hachage. Le truc a été cassé.
J'ai connu une histoire d'une personne étant parti au japon qui n'a pas réussi à dormir pendant 3 jours. Alors pourquoi l'inverse, pour dormir, ne pourrait pas exister ?
Je me suis éloigné du dev linux depuis un moment, mais le fichier que tu montres est la description d'un seul chip, d'un périphérique. Le problème est de savoir si il est présent ou non, et que la méthode de détection ne puisse pas "bricker" le cpu (par exemple en bidouillant la configuration des PLL).
[^] # Re: À la fois troll, à la fois fait divers
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 3.
J'ai écrit un peu vite. Je ne connais pas Akka. Pour cassandra, il y a une tentative de réécriture en C++ qui annonce des perf bien supérieur à la version d'origine.
"La première sécurité est la liberté"
[^] # Re: À la fois troll, à la fois fait divers
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 4.
Des trucs comme Kafka et akka, sont surtout IO bound, donc cela concerne surtout la qualité des lib réseau et disque.
"La première sécurité est la liberté"
[^] # Re: Mon avis personnel
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 4.
Ce que tu dis de C++ est vrai pour Golang.
"La première sécurité est la liberté"
[^] # Re: Phobie du GC
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10.
Dans les applications temps réel, le plus simple est de ne pas faire d'allocation mémoire, tout est statique. Ainsi, il n'y a jamais de problème de new ou de delete, ni de latence associé.
"La première sécurité est la liberté"
[^] # Re: Phobie du GC
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 10.
Unity c'est ~20 millions de ligne de C++, et un jeu c# rajoute ~100k ligne dessus. La partie temps réel dure est à 100% en C++.
Le problème des GC est qu'il rajoute des latences à peu n'importe où, et un peu n'importe quand. Golang dispose d'un gc avec des latences ajouté super courte (9ms de mémoire), mais au pris d'un usage du cpu plus gros. Avec l'augmentation de la RAM, un GC n'est pas raisonnable. C'est amusant de lire les exploits techniques des systèmes de bases de données en "RAM". Ce sont des grappes de x86, avec des To de RAM. Il est plus rapide de faire un reset que de se prendre le full GC de java. Il y a donc une foule de technique pour l'éviter.
"La première sécurité est la liberté"
# La culture des armes
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Des armes en Open-Source. Évalué à 4.
si on lit les américains sur la culture des armes. Ils font clairement la distinction entre 3 types d'armes.
Les armes de point qui peuvent se cacher, qui est typiquement une arme de voyou et de voleur. C'est ce genre d'arme qui fait le plus de morts au USA. J'imagine qu'un jour ils arriveront à les faire enregistrer.
Il y a les armes longues, type fusil de chasse. Visible, pour "protéger ta famille". Bref, le genre de machin qu'un bon père de famille a chez lui, voir dans son camion. Il sera presque impossible pour le législateur de demander un enregistrement de ce genre d'arme, sans être vu comme un moyen d'aller ensuite les prendre et d’empêcher l'amériain moyen de se défendre.
Il y a les armes automatiques, ou les gros chargeurs, ou les kit pour transformer une arme longue en arme automatique. C'est l'arme des tueries de masse, mais ce n'est pas le type d'arme qui fait le plus de morts. Beaucoup sont pour l'interdiction de vente de ce genre d'armes.
Bref, vu le nombre d'arme en circulation là-bas, l'interdiction n'aurait aucun sens. Par contre, une segmentation de la réglementation en fonction du type d'arme seraient beaucoup mieux accepté.
"La première sécurité est la liberté"
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 4.
J'ai adoré le coté, "je fais un serveur web applicatif en 10 lignes, qui tient la charge". Mais bon, j'ai ensuite vu tout ce qu'il fallait écrire pour utiliser un truc comme go-kit. C'est tellement verbeux, que certains ont essayé d'écrire des générateurs de code. Mais aucun n'est vraiment finalisé.
"La première sécurité est la liberté"
[^] # Re: C++ -> Python -> Go -> Rust
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ready At Dawn passe à Rust. Évalué à 8. Dernière modification le 26 juillet 2018 à 17:48.
Que go est simple et donc peut devenir très verbeux, que si on a les type sum et la généricité sous la main, je comprends que l'on a pas envie de revenir à Golang.
"La première sécurité est la liberté"
[^] # Re: Ne mélangeons pas tout
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 3.
Pour la limite temporelle, le CPL("g3") est super lent, genre quelques bps, donc, c'est fort possible que 2 min soit réellement un minimum.
cf https://twitter.com/d0cTB/status/981105488439009280
Par contre, la mise à jour du firmware, c'est pas glop :
https://twitter.com/d0cTB/status/981265458115604480
"La première sécurité est la liberté"
[^] # Re: Tu extrapoles un peu vite
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Compteur communiquant linky et collecte de la courbe de charge. Évalué à 6. Dernière modification le 24 juillet 2018 à 17:26.
On récupérerait les clef RSA avec la consomation électrique.
https://fr.wikipedia.org/wiki/Analyse_de_consommation_(cryptographie)
si la précision est réellement limité sur la mesure, cela rend le DPA moisn efficace, bien sûr.
Le 2ième point oublié, c'est la possibilité de pirater linky et qu'un pirate installe un firmware de son cru. A priori, il a juste à broadcaster sur la ligne 220 en CPL.
"La première sécurité est la liberté"
[^] # Re: Information et transfert de responsabilité
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Légalité de l'interception du flux SSL au sein d'une entreprise. Évalué à 6.
On peut même ajouter que certaines boites noir MiM utilisent des versions de openSSL complètement obsolètes et troués.
"La première sécurité est la liberté"
# business modèle ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Open Earth View - Consultation avant création d'une startup. Évalué à 3.
J'imagine que tu dois commencer par une plateforme comme open street map ou google map, avec la possiblité de créer des cartes perso.
Et tu peux fournir des cartes privés payantes comme github avec ses repositories privés.
J'imagine que la mise en commun de truc iot peut être intéressant (météo, pollution ) mais la 3D sert moins.
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
ok, faudrait que je reregarde un peu.
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 3.
quand je les avait appeler, il m'avait demandé combien de personne mon app devait concerner. quand je leur ai dis un seul, ma boite, ils ont dit qu'il ne le faisait pas. "Budget Insight" est bien la seul boite qui utilise le code de weboop pour le bancaire ?
"La première sécurité est la liberté"
[^] # Re: euh...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 3.
Tu penses à quel genre d'attaque concernant des systèmes protégés par carte à puce ? En général, les attaques les plus bête sont simplement un bug dans le soft de gestion. J'ai mis vu des implémentations hardware du driver de lien série pour éviter des attaques dessus (genre glitch d'alimentation sur la fonction qui demande la version (une string) qui permet de faire sauter le test de fin de boucle de copie de la string pour continuer de lire la suite de la mémoire).
"La première sécurité est la liberté"
[^] # Re: euh...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 3.
Pour avoir bosser pour le labo de canal+ sur le sujet, je peux dire qu'il y a un monde entre une carte à puce, et un microcontrôleur classique. Bien sur, je ne dirais pas que c'est impossible, mais conceptuellement être capable de sortir un secret d'une carte à puce particulière (et non un secret identique recopié sur 20 puces), c'est vraiment très compliqué, avoir un FIB, un LSM, un AFM, un microscope électronique, n'aide pas vraiment.
Pour faire ça, il faut connaitre parfaitement le modèle de la puce elle-même, voir si elle a une faiblesse. Ensuite, il vaut mieux avoir une autre clef avec le logiciel utilisé dans la cible, pour voir si le soft à une faiblesse. Et ensuite, s'attaquer à la clef cible en question, sachant qu'il y a une haute proba de destruction.
Dans un microcontrôleur, il suffit souvent d'utiliser le JTAG.
La sécurité est forcément par la sécurité car chaque mesure est imparfaite. L'exemple du shield est intéressant. Ils ont fait une version avec un registre il fallait lire et écrire dedans pour voir si un fil était coupé. Mais cela laissait quelques milliers de cycle à l'allumage sans protection. Ensuite, ils ont fait des "versions analogiques" qui mesuraient la résistance du shield pour détecter un by-pass. L'emplacement des détecteurs de laser n'est pas connu, cela oblige l'attaquant a cartographier la puce, pour ne pas taper dedans. Si une sécurité repose sur un nombre secret, si il est connu, cela ne marche plus (clef de chiffrage de la mémoire, ou autre), etc…
Le comportement du CMOS est connu, c'est presque une boite blanche, le seul moyen de planquer quelques choses dedans, c'est de faire une boite et de faire grossir la meule de foin.
"La première sécurité est la liberté"
[^] # Re: Sécurité ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Falkon 3 le nouveau navigateur pour KDE. Évalué à 8.
Pourquoi avoir mis le même nom ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 2. Dernière modification le 13 juillet 2018 à 11:35.
Bien sûr. Mais qui en utilise encore ?
"La première sécurité est la liberté"
[^] # Re: Banque Cooperative
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Possible coupure de service sur Liberapay. Évalué à 4.
Oui si tu passes par budget insight qui gère les modifications des banques, sinon c'est à toi de gérer chaque changement d'interface. Et budget insight vend son truc pour des applications bancaires, pas pour une PME qui veut automatiser sa relation avec sa banque.
"La première sécurité est la liberté"
# euh...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 5.
Oui mais non. Si il y autant de protection dans une carte à puce, ce n'est pas pour faire joli. D'ailleurs, si un secret est unique à une puce, à moins d'un bug, il est impossible de sortir le secret, car il est trop facile de détruire la puce pendant le processus. Ce n'est pas le cas d'un chip normal.
Une carte à puce dispose d'un "shield", une grille que l'on doit "dériver" pour accéder au bus de la FLASH. Une protection de l'alimentation et des pin d'entré pour éviter les glitchs. Ils disposent aussi de capteur de laser qui détruit la mémoire, pour éviter l'injection de faute. Les mémoires internes sont cryptés. Des secrets peuvent être en dur, (genre fonction de dérivation de clef qui ajoute un grand nombre). Si vous voulez ce nombre pour avoir l'algo de dérivation de clef complet, il faut faire du reverse hardware ou avoir des bons contacts dans le service de sécurité du fabricants.
"La première sécurité est la liberté"
[^] # Re: Gniibe préfère aussi le hard générique et documenté
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre. Évalué à 3. Dernière modification le 13 juillet 2018 à 09:47.
Une fois, j'avais entendu parler d'un "hash hardware" sur un SoC, mais c'était simplement un bloc AES, or AES est connu pour être une mauvaise fonction de hachage. Le truc a été cassé.
"La première sécurité est la liberté"
[^] # Re: fuseau horaire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal J'ai testé... me faire électriser. Évalué à 3.
J'ai pas dit mal, j'ai dis pas du tout, au point de se faire hospitaliser.
"La première sécurité est la liberté"
[^] # Re: fuseau horaire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal J'ai testé... me faire électriser. Évalué à 2.
Pourquoi ?
J'ai connu une histoire d'une personne étant parti au japon qui n'a pas réussi à dormir pendant 3 jours. Alors pourquoi l'inverse, pour dormir, ne pourrait pas exister ?
"La première sécurité est la liberté"
# fuseau horaire ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal J'ai testé... me faire électriser. Évalué à 10.
As tu tenter le voyage pour te placer dans un fuseau horaire qui te plait plus ?
"La première sécurité est la liberté"
[^] # Re: Fragmentation risk
Posté par Nicolas Boulay (site web personnel) . En réponse au journal «Understand the fact» la campagne de Arm contre le set d'instructions libre Risc-V. Évalué à 4.
Je me suis éloigné du dev linux depuis un moment, mais le fichier que tu montres est la description d'un seul chip, d'un périphérique. Le problème est de savoir si il est présent ou non, et que la méthode de détection ne puisse pas "bricker" le cpu (par exemple en bidouillant la configuration des PLL).
"La première sécurité est la liberté"