La NSA veut tout stoquer et indexer pour "plus tard".
Par exemple, pour rentrer dans les systèmes, ils visent les administrateurs système pour avoir mot de passe et accès. On peut imaginer qu'un "chantage à la maitresse" peut être très utile pour pénétrer un système.
Les services secret ont rarement des méthodes très propres.
Si le problème est de la HF dans l'alimentation, le mieux est de simplement coller un régulateur de tension derrière. Le plus compliqué est de bien mettre une différence de tention très faible pour éviter la chauffe. Les LVDO avec 0.6V et de bon condensateur doivent pouvoir faire l'affaire. Si cela chauffe trop, certain colle une résistance en amont du régulateur linéaire pour faire chuter la tension avant.
Il y a tout de même les filtres amont à faire, c'est plus simple que des filtres classique, car on peut se permettre d'utiliser des résistances. Mais ses filtres doivent se "recouvrir" parfaitement, et cela serait encore mieux si on pouvait tenir compte du rendement par fréquence de chacun des HP.
"Pour avoir déjà eu des crashs, l'aspect remise en service, la robustesse, la redondance, la sauvegarde, la résilience sont des éléments importants"
Pour moi aussi ! Et logiquement la techno de VM doit pouvoir séparer un maximum machine physique et instance de VM. Évidement, il ne faut pas de serveur de fichier qui seront d'énorme goulet d'étranglement, mais une copie physique de l'image de VM, synchronisé chaque nuit sur quelques serveur.
Pour les petits truc perso, un kimsufi est pas mal et beaucoup plus chère. A l'époque, les VM était lentes surtout les accès disques. Et tout ce qui était mutualisé, n'était pas redondé, alors qu'ils aurait pu.
Là, vous êtes proche d'une techno à la Google, où le logiciel est complètement décorrélé de la machine qui l’exécute (des machines tombent tout les jours dans leur cluster, ils ne les changent pas). Pour ça, il utilise leur techno de système de fichier distribué, de big table et map/reduce.
Ici, une instance à un instant t, peut se contenter d'être sur une seul machine à la fois. La réplication temps réelle est forcément hyper chiante à mettre en place. Mais un "sync" journalier doit pouvoir suffire à 90% des besoins surtout sur 20Go.
Je verrais bien un cloud qui garanti les données, voir le service.
Cela ne doit pas être trop dur de détecter une machine tombée, et de relancer les VM ailleurs. Il faudrait aussi garantir les données par duplication/synchro chaque nuit, par exemple, entre 3 serveurs physiques.
Je vu plusieurs fois ce genre de souci. Les gens en général brandissent du xml ou du json pour être "compatible", alors que cela n'aide que le premier niveau du parseur.
Il manque en général un bon schéma, voir quelques règles de grammaire que l'on ne peut pas exprimer dans un schéma.
J'imaginais qu'il devrait être possible de faire un format qui mélange les 2, ainsi le schéma serait aussi dans le document. Celui-ci serait plus gros, mais cela resterait raisonnable.
Si tu veux continuer le boulot avec les amplis, il y a un truc à faire coté amplification active.
Je ne comprends pas pourquoi les amplis sont lié à la source numérique, qui impose ensuite un filtrage passif complexe, alors qu'un ampli peut être très lié à un haut parleur, ce qui facilite sa conception.
En plus, un ampli ne vieillit pas, alors que les sources numériques sont obsolètes en 5 ans (nouvelle version de HDMI, nouveau codec, Bluetooth, radio internet…)
Je suis sûr que des haut parleurs amplifié avec 2 ou 3 modules amplificateurs (genre classe D ou t), un seul transfo par enceinte, qui récupère la sortie d'un ampli (mis sur 16 ohm ou plus) quelconque pourrait avoir un super son.
Le problème est d'avoir à brancher chaque haut parleur à une prise électrique, et de ne pas utiliser du sans fils (pas pérenne).
On a très rarement à écrire ce genre d'algo dans la vrai vie de programmeur. Il s'agit surtout de coller des morceaux entre eux de façon la moins sale possible.
Peux être que la mise en œuvre des design patterns classiques pourrait être une bonne façon d'apprendre.
Quel encodage ? Parce que si ton programme attend du pure ASCII 7 bits, il va faire des trucs marrants avec de l'utf8. Surtout si il interprète les caractères de contrôle.
Le passage à l'UTF8 sur les consoles Linux ne s'est pas fait de façon très joli.
Je ne parlais pas de transmettre la clé pour chaque échange, j'ai du mal m'exprimer.
C'est moi qui proposait cela, car cela a plein d'avantage dont la simplicité.
Reste la possibilité de vérifier après coup le fingerprint, comme tu le dis, mais qui te dis que ton message ne sera pas modifié en cours (principe du MITM)?
Non pas du tout. C'est ton correspondant qui doit te donner son fingerprint par un autre canaux. De ceux point de vue là, cela ne change rien avec la méthode PGP classique.
(rappel : la seule faute est de ne pas avoir nommé l'auteur).
Vu que c'est une licence NC, il fallait aussi son accord. C'est une contre façon comme une autre. C'est juste beaucoup plus toléré dans le domaine de la photo (mention "Droit Réservé").
C'est nickel chez moi sur un nexus 5 avec écran HD. Tu as quoi comme appareil ?
Samsung S2
On peut mais comme je l'ai dit, c'est inutile. C'est juste les geeks qui râlent. Pour les enfants, il est pas plus mal d'un point de vu pédagogique présenter un clavier dans l'ordre alphabétique pour découvrir les lettres.
C'est pas faux. Mais avoir du mal, c'est frustrant.
Le seul cas intéressant pour les brevets était la protection des emplois en France, dans certain cas.
J'ai eu l'exemple d'une boite française qui faisait des super capacité. Le seul moyen de virer les copies chinoise, était de faire jouer le droit des brevets sur les marchés important (Europe, japon et EU).
Normalement on fait du PreserveAspectCrop sauf cas particulier. C'est sur quelle activité que tu as ce problème ?
Sur "envoie la balle à tux" et penalty, c'est juste flou.
sur "clique et dessine", c'est déformé.
Le fond du menu est moche aussi (flou).
On liste les fontes systèmes plus 2 fontes qu'on embarquent, Andika pour le cursif et Opendyslexic. On laisse la possibilité à l'utilisateur d'installer ses fontes et de les choisir. Dès lors on est bien obligé de les montrer toutes.
Oui, mais le widget de choix ne semble pas aligné. Cela fait bizarre.
De plus, si on prends une taille trop grosse, cela dépasse du cadre, par exemple le nom de la font choisi.
On y a pensé mais c'est trop compliqué de gérer l'implantation 'normale' d'un clavier pour chaque langue. On peut dire que cette activité est plus orienté pour le déchiffrage des lettres et le concept de clavier, pas pour apprendre la frappe.
Vous ne pouvez pas juste prendre les 3 lignes de lettre de chaque clavier ? cela pourrait se faire avec uniquement 3 string par clavier.
J'avais pensé à utiliser un couple de clés PGP échangé lors de la connexion entre les amis celui qui crée le canal de conversation, génère une clé publique/privée qui est envoyé via la clé publique de chaque utilisateur pour chiffré les échanges juste pendant cette conversation (ce qui ne retire pas le fait que si la clé est corrompu, l'envoie de la clé de discussion également) mais on peux penser à un échange de ce couple par un autre canal (mail chiffré ou autre) ce qui permet aussi de convier d'autres personnes à une "conférence" sans échanger avec celles-ci ses propres clés.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
de plus ce qui devrait pouvoir être fait, c'est de signer sa clé publique "publique" (qui est stockée dans l'application) avec une clé privée qui n'est JAMAIS publiée (utiliser une fois à chaque renouvellement de clé et stocké dans un coffre derrière un pitbull, ou chez la belle mère).
Du coup lors du changement de clé on peut vérifier celle-ci avec la signature de la clé publique "de référence" dont la clé privée est bien cachée.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
Si on inclue la clef publique dans tout échange de mail entre 2 personnes, et que si la clef est présente, l'échange continu en crypté ?
Si on veut de la vrai sécurité rien n'empèche de vérifier le finger print après coup. De plus, la NSA devrait modifier à la volé tous les messages qui circulent, cela me parait bien lourd.
Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.
D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).
* avoir pour chacun la dernière clé publique utilisée.
* la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…
Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.
J'avais pensé, à utiliser une autre clef privé caché qui signe celle qui est effectivement utilisé. Pour gérer le vol de compte, je pense même crypter cette clef privé avec une clef découpé avec sss ( https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ) ce morceau de clef étant filé à des amis de confiance. Ceux-ci devraient filer le code si besoin. Je l'avais appelé la fuck-you key :) Car, c'est imparable si tu as des amis prudent. Le but est de gérer une sorte de révocation des clefs publiques proprement. PGP gère des grosses listes de clef révoqué, c'est lourd comme mécanisme.
Tu as regardé cryptocat qui est censé être ce qui se fait de mieux ?
Ton architecture me pose quelques problèmes : la communication de message devrait se faire sans passer par le serveur, c'est maintenant possible sur un navigateur (cf Firefox Hello).
Tu ne semble pas proposer de moyen contre les attaques "man in the middle". Cryptocat utilise le principe de forward secrecy. Cela revient avec PGP à conserver les clef publique de tes correspondants, et comprendre pourquoi une clef change.
La passphrase de protection, en local, c'est un peu "léger". Il faudrait ajouter un secret (128 bits) sauvé dans le navigateur (voir un fichier complet ?). Un mot de passe "d'humain", cela se casse trop facilement.
"L'auteur de GCompris que tu vois sur le Play Store c'est moi ;)"
Le problème est que tu es moins connu que ton logiciel. Si l'auteur était la "fondation GCompris" ou équivalent, cela passerait mieux (cf VLC, firefox,…).
Sinon, une petite remarque, il y a parfois des images qui sont déformés dans l'application. On dirait un "zoom fit", surtout pour les images de fond. C'est vraiment très moche (image étiré et gros pixel carré flou).
Pour une application ludique pour enfant, c'est curieux d'avoir un menu option avec 12 000 fonts disponible. Cela fait un peu, "application pour enfant avec papa geek". Je limiterais le choix, avec peut être une font spécial comme opendyslexic.
Les jeux, avec le clavier en "abcdef", c'est moche de ne pas donner de clavier "azerty", j'ai raté une configuration ? Si c'est pour apprendre un clavier, autant prendre un clavier courant.
[^] # Re: Très mauvaise nouvelle
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Textsecure : les SMS et MMS chiffrés, c'est fini. Évalué à 2.
Le forfait à 2€ permet de faire un peu de data (qq 100 de Mo) pour quelques euros de plus.
"La première sécurité est la liberté"
[^] # Re: Paranoïa
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Pourquoi ne faut-il absolument pas brancher ses appareils USB sur des bornes publiques ?. Évalué à 10.
La NSA veut tout stoquer et indexer pour "plus tard".
Par exemple, pour rentrer dans les systèmes, ils visent les administrateurs système pour avoir mot de passe et accès. On peut imaginer qu'un "chantage à la maitresse" peut être très utile pour pénétrer un système.
Les services secret ont rarement des méthodes très propres.
"La première sécurité est la liberté"
[^] # Re: Paranoïa
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Pourquoi ne faut-il absolument pas brancher ses appareils USB sur des bornes publiques ?. Évalué à 6.
Si M. Dupont est avec sa secrétaire et non sa femme, cela pourrait lui être utile plus tard. Surtout avec des photos.
"La première sécurité est la liberté"
[^] # Re: ampli ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal QSpeakers, une pièce manquante pour les DIY sous Linux. Évalué à 2.
Si le problème est de la HF dans l'alimentation, le mieux est de simplement coller un régulateur de tension derrière. Le plus compliqué est de bien mettre une différence de tention très faible pour éviter la chauffe. Les LVDO avec 0.6V et de bon condensateur doivent pouvoir faire l'affaire. Si cela chauffe trop, certain colle une résistance en amont du régulateur linéaire pour faire chuter la tension avant.
"La première sécurité est la liberté"
[^] # Re: ampli ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal QSpeakers, une pièce manquante pour les DIY sous Linux. Évalué à 2.
Il y a tout de même les filtres amont à faire, c'est plus simple que des filtres classique, car on peut se permettre d'utiliser des résistances. Mais ses filtres doivent se "recouvrir" parfaitement, et cela serait encore mieux si on pouvait tenir compte du rendement par fréquence de chacun des HP.
"La première sécurité est la liberté"
[^] # Re: j'ai mis 4€ mais....
Posté par Nicolas Boulay (site web personnel) . En réponse au sondage Quel est le bon prix pour le cloud ?. Évalué à 3.
Pour moi aussi ! Et logiquement la techno de VM doit pouvoir séparer un maximum machine physique et instance de VM. Évidement, il ne faut pas de serveur de fichier qui seront d'énorme goulet d'étranglement, mais une copie physique de l'image de VM, synchronisé chaque nuit sur quelques serveur.
"La première sécurité est la liberté"
[^] # Re: cloud avec garanti sur les données
Posté par Nicolas Boulay (site web personnel) . En réponse au sondage Quel est le bon prix pour le cloud ?. Évalué à 2.
Pour les petits truc perso, un kimsufi est pas mal et beaucoup plus chère. A l'époque, les VM était lentes surtout les accès disques. Et tout ce qui était mutualisé, n'était pas redondé, alors qu'ils aurait pu.
Là, vous êtes proche d'une techno à la Google, où le logiciel est complètement décorrélé de la machine qui l’exécute (des machines tombent tout les jours dans leur cluster, ils ne les changent pas). Pour ça, il utilise leur techno de système de fichier distribué, de big table et map/reduce.
Ici, une instance à un instant t, peut se contenter d'être sur une seul machine à la fois. La réplication temps réelle est forcément hyper chiante à mettre en place. Mais un "sync" journalier doit pouvoir suffire à 90% des besoins surtout sur 20Go.
"La première sécurité est la liberté"
[^] # Re: Changements ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Vulkan le successeur d'OpenGL. Évalué à 5.
Il fusionne openCL et openGl, diminue la complexité de l'api, et essaye d'être réellement portable ce qui n'est pas le cas d'OpenGL, dans les détails.
Peut être que l'on verra plus souvent des applications tirés parti de la vitesse des gpu.
"La première sécurité est la liberté"
# cloud avec garanti sur les données
Posté par Nicolas Boulay (site web personnel) . En réponse au sondage Quel est le bon prix pour le cloud ?. Évalué à 2.
Je verrais bien un cloud qui garanti les données, voir le service.
Cela ne doit pas être trop dur de détecter une machine tombée, et de relancer les VM ailleurs. Il faudrait aussi garantir les données par duplication/synchro chaque nuit, par exemple, entre 3 serveurs physiques.
"La première sécurité est la liberté"
[^] # Re: No brainer : Utilisation d'une plateforme EDI
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Dématérialisation de documents comptables. Évalué à 2.
Je vu plusieurs fois ce genre de souci. Les gens en général brandissent du xml ou du json pour être "compatible", alors que cela n'aide que le premier niveau du parseur.
Il manque en général un bon schéma, voir quelques règles de grammaire que l'on ne peut pas exprimer dans un schéma.
J'imaginais qu'il devrait être possible de faire un format qui mélange les 2, ainsi le schéma serait aussi dans le document. Celui-ci serait plus gros, mais cela resterait raisonnable.
"La première sécurité est la liberté"
[^] # Re: ampli ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal QSpeakers, une pièce manquante pour les DIY sous Linux. Évalué à 2.
C'est un choix de conception.
"La première sécurité est la liberté"
# ampli ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal QSpeakers, une pièce manquante pour les DIY sous Linux. Évalué à 4. Dernière modification le 03 mars 2015 à 15:15.
Si tu veux continuer le boulot avec les amplis, il y a un truc à faire coté amplification active.
Je ne comprends pas pourquoi les amplis sont lié à la source numérique, qui impose ensuite un filtrage passif complexe, alors qu'un ampli peut être très lié à un haut parleur, ce qui facilite sa conception.
En plus, un ampli ne vieillit pas, alors que les sources numériques sont obsolètes en 5 ans (nouvelle version de HDMI, nouveau codec, Bluetooth, radio internet…)
Je suis sûr que des haut parleurs amplifié avec 2 ou 3 modules amplificateurs (genre classe D ou t), un seul transfo par enceinte, qui récupère la sortie d'un ampli (mis sur 16 ohm ou plus) quelconque pourrait avoir un super son.
Le problème est d'avoir à brancher chaque haut parleur à une prise électrique, et de ne pas utiliser du sans fils (pas pérenne).
"La première sécurité est la liberté"
[^] # Re: exemple de la vrai vie
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Apprentissage du code par la pratique. Évalué à 2.
https://fr.wikipedia.org/wiki/Patron_de_conception
Ce bouquin est la référence : https://fr.wikipedia.org/wiki/Design_Patterns Il "suffirait" de faire faire implémenter les algos qui sont dedans.
"La première sécurité est la liberté"
# exemple de la vrai vie
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Apprentissage du code par la pratique. Évalué à 10.
On a très rarement à écrire ce genre d'algo dans la vrai vie de programmeur. Il s'agit surtout de coller des morceaux entre eux de façon la moins sale possible.
Peux être que la mise en œuvre des design patterns classiques pourrait être une bonne façon d'apprendre.
"La première sécurité est la liberté"
[^] # Re: Le bon chasseur et le mauvais chasseur
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche systemd : l’init martyrisé, l’init bafoué, mais l’init libéré !. Évalué à 2.
Quel encodage ? Parce que si ton programme attend du pure ASCII 7 bits, il va faire des trucs marrants avec de l'utf8. Surtout si il interprète les caractères de contrôle.
Le passage à l'UTF8 sur les consoles Linux ne s'est pas fait de façon très joli.
"La première sécurité est la liberté"
[^] # Re: Annuaire clés publiques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 2.
C'est moi qui proposait cela, car cela a plein d'avantage dont la simplicité.
Non pas du tout. C'est ton correspondant qui doit te donner son fingerprint par un autre canaux. De ceux point de vue là, cela ne change rien avec la méthode PGP classique.
"La première sécurité est la liberté"
[^] # Re: Sympa
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utilisation de photo sans autorisation. Évalué à 1.
Vu que c'est une licence NC, il fallait aussi son accord. C'est une contre façon comme une autre. C'est juste beaucoup plus toléré dans le domaine de la photo (mention "Droit Réservé").
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Samsung S2
C'est pas faux. Mais avoir du mal, c'est frustrant.
"La première sécurité est la liberté"
[^] # Re: Continuer son combat ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Nouvel exemple de brevets logiciels comme freins à l'innovation et la recherche. Évalué à 2.
Le seul cas intéressant pour les brevets était la protection des emplois en France, dans certain cas.
J'ai eu l'exemple d'une boite française qui faisait des super capacité. Le seul moyen de virer les copies chinoise, était de faire jouer le droit des brevets sur les marchés important (Europe, japon et EU).
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 2.
Sur "envoie la balle à tux" et penalty, c'est juste flou.
sur "clique et dessine", c'est déformé.
Le fond du menu est moche aussi (flou).
Oui, mais le widget de choix ne semble pas aligné. Cela fait bizarre.
De plus, si on prends une taille trop grosse, cela dépasse du cadre, par exemple le nom de la font choisi.
Vous ne pouvez pas juste prendre les 3 lignes de lettre de chaque clavier ? cela pourrait se faire avec uniquement 3 string par clavier.
"La première sécurité est la liberté"
[^] # Re: cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
C'est différent. La crypto asymétrique est connu pour être moins fiable que la symétrique (genre AES en XTS). Ce que tu proposes est différent, tu propose de refaire un échange de clef asymétrique jetable. Cela doit te donner la propriété de forward secrecy une fois la clef privé jeté. C'est pas mal, je pense.
Fait aussi très attention à tes générateurs aléatoires, toute la sécurité repose dessus. Encore une fois, tu peux faire des couches : 128 bits d'entropie minimum par couche (genre /dev/urandom et une toutouille à toi) et le mélange des couches doit aussi être cryptographique et non un simple XOR (genre sha2). Attention à ne jamais dériver les clefs, tout doit être aléatoire.
Ici, le problème est de faire simple. J'aime bien la propriété qui consiste à dire que l'on peut garantir un réseau si >50% des nœuds du réseau sont fiables. En gros, un noeud compromis ne peut tout compromettre. Dans ton cas, cela reviendrait à partager tes informations.
Regardes les protocoles comme celui proposé dans la dépêche qui utilise git et bittorrent. Celui-ci te garanti contre tout modification (un serveur deviendrait membre d'un réseau et ne serait pas isoler). Tu dois même pouvoir rajouter une couche d'authentification en utilisant le réseau bitcoin.
"La première sécurité est la liberté"
[^] # Re: Annuaire clés publiques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 2.
Si on inclue la clef publique dans tout échange de mail entre 2 personnes, et que si la clef est présente, l'échange continu en crypté ?
Si on veut de la vrai sécurité rien n'empèche de vérifier le finger print après coup. De plus, la NSA devrait modifier à la volé tous les messages qui circulent, cela me parait bien lourd.
"La première sécurité est la liberté"
[^] # Re: cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
Si le fichier est en local, on peut imaginer qu'une faille de sécurité du navigateur serait insuffisant pour attraper le fichier en question à distance. Le principe est toujours d'avoir des couches de sécurité qui sont suffisantes et le plus indépendante possible.
D'ailleurs, vu que le seul moyen d'avoir une discussion en PGP sans man in the middle avec une personne connu, est de vérifier le finger print de la clef depuis un autre canal, tu devrais aussi voir pour utiliser une clef symétrique. Les 2 personnes se débrouillent pour se refiler la clef (un fichier image ?).
* avoir pour chacun la dernière clé publique utilisée.
* la clé publique des amis connus ne devrait changée et n'être acceptée QUE si la nouvelle est chiffrée avec l'ancienne etc…
Attention avec ces gestions de clef complexes, c'est facile que l'utilisateur fasse n'importe quoi. Si la clef est compromise, signer avec l'ancienne clef, ne sert à rien.
J'avais pensé, à utiliser une autre clef privé caché qui signe celle qui est effectivement utilisé. Pour gérer le vol de compte, je pense même crypter cette clef privé avec une clef découpé avec sss ( https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing ) ce morceau de clef étant filé à des amis de confiance. Ceux-ci devraient filer le code si besoin. Je l'avais appelé la fuck-you key :) Car, c'est imparable si tu as des amis prudent. Le but est de gérer une sorte de révocation des clefs publiques proprement. PGP gère des grosses listes de clef révoqué, c'est lourd comme mécanisme.
"La première sécurité est la liberté"
# cryptocat ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 6.
Tu as regardé cryptocat qui est censé être ce qui se fait de mieux ?
Ton architecture me pose quelques problèmes : la communication de message devrait se faire sans passer par le serveur, c'est maintenant possible sur un navigateur (cf Firefox Hello).
Tu ne semble pas proposer de moyen contre les attaques "man in the middle". Cryptocat utilise le principe de forward secrecy. Cela revient avec PGP à conserver les clef publique de tes correspondants, et comprendre pourquoi une clef change.
La passphrase de protection, en local, c'est un peu "léger". Il faudrait ajouter un secret (128 bits) sauvé dans le navigateur (voir un fichier complet ?). Un mot de passe "d'humain", cela se casse trop facilement.
"La première sécurité est la liberté"
[^] # Re: android
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Comment faire la promotion d'un logiciel libre ?. Évalué à 4.
Le problème est que tu es moins connu que ton logiciel. Si l'auteur était la "fondation GCompris" ou équivalent, cela passerait mieux (cf VLC, firefox,…).
Sinon, une petite remarque, il y a parfois des images qui sont déformés dans l'application. On dirait un "zoom fit", surtout pour les images de fond. C'est vraiment très moche (image étiré et gros pixel carré flou).
Pour une application ludique pour enfant, c'est curieux d'avoir un menu option avec 12 000 fonts disponible. Cela fait un peu, "application pour enfant avec papa geek". Je limiterais le choix, avec peut être une font spécial comme opendyslexic.
Les jeux, avec le clavier en "abcdef", c'est moche de ne pas donner de clavier "azerty", j'ai raté une configuration ? Si c'est pour apprendre un clavier, autant prendre un clavier courant.
"La première sécurité est la liberté"