Je ne suis pas certain de poster au bon endroit... à supposer qu'il
existe un endroit ou poser cette question.
Je cherche à savoir comment déterminer (algorihmiquement) si un fichier
est chiffré (avec un taux de faux positifs/négatifs si possible très
faible, de l'ordre de 0.1%).
Dans la logique de l'algo, on eut considérer qu'un fichier chiffré avec
un procédé de chiffrement trop pourri est un fichier non-chiffré.
J'ai donc envisagé de réaliser mon test en prenant des échantillons
aléatoires de données dans le fichier à tester pour vérifier que le
contenu de chacun des échantillons, de l'ensemble des échantillons, et
des dérivées premières et secondes des fonctions approximant la série
représentée par chaque échantillon et l'ensemble "a l'air aléatoire"
(par exemple, par examen de la FFT de l'échantillon)
Peur-on considérer que tout fichier chiffré avec un procédé de
chiffrement pas trop débile a ces caractéristiques ? Se fera-t-on
insulter par une quelconque sommité de la crypto à rejeter comme "non ou
mal chiffrés" des fichiers ne présentant pas ces caractéristiques ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc Desperrier
Bob qui Trolle wrote:
Je cherche à savoir comment déterminer (algorihmiquement) si un fichier est chiffré (avec un taux de faux positifs/négatifs si possible très faible, de l'ordre de 0.1%).
J'ai donc envisagé de [...] vérifier que [...] l'ensemble "a l'air aléatoire" (par exemple, par examen de la FFT de l'échantillon)
Peur-on considérer que tout fichier chiffré avec un procédé de chiffrement pas trop débile a ces caractéristiques ? Se fera-t-on insulter par une quelconque sommité de la crypto à rejeter comme "non ou mal chiffrés" des fichiers ne présentant pas ces caractéristiques ?
Clairement oui dans ce sens, mais un fichier peut présenter des caractéristiques apparement aléatoire et ne pas être chiffré du tout, par exemple s'il est compressé avec un algorithme vraiment efficace.
C'est donc plutôt dans l'autre sens que tu risque de te faire insulter en ayant des faux positifs sur des fichiers ".bz2" par exemple.
Et la très grande majorité des fichiers chiffrés auront besoin d'un en-tête non aléatoire pour gérer les info de déchiffrement, donc il n'y aura sur un plan purement algorithmique vraiment pas grand chose pour les différencier des fichiers compressés.
L'identification par "magic number" basé sur les en-têtes, et le refus des algo/format de chiffrement totalement inconnus (dont de toute façon la sécurité ne peut absolument pas être estimée) est une solution qui mènera sûrement plus loin.
Bob qui Trolle wrote:
Je cherche à savoir comment déterminer (algorihmiquement) si un fichier
est chiffré (avec un taux de faux positifs/négatifs si possible très
faible, de l'ordre de 0.1%).
J'ai donc envisagé de [...] vérifier que [...] l'ensemble "a l'air aléatoire"
(par exemple, par examen de la FFT de l'échantillon)
Peur-on considérer que tout fichier chiffré avec un procédé de
chiffrement pas trop débile a ces caractéristiques ? Se fera-t-on
insulter par une quelconque sommité de la crypto à rejeter comme "non ou
mal chiffrés" des fichiers ne présentant pas ces caractéristiques ?
Clairement oui dans ce sens, mais un fichier peut présenter des
caractéristiques apparement aléatoire et ne pas être chiffré du tout,
par exemple s'il est compressé avec un algorithme vraiment efficace.
C'est donc plutôt dans l'autre sens que tu risque de te faire insulter
en ayant des faux positifs sur des fichiers ".bz2" par exemple.
Et la très grande majorité des fichiers chiffrés auront besoin d'un
en-tête non aléatoire pour gérer les info de déchiffrement, donc il n'y
aura sur un plan purement algorithmique vraiment pas grand chose pour
les différencier des fichiers compressés.
L'identification par "magic number" basé sur les en-têtes, et le refus
des algo/format de chiffrement totalement inconnus (dont de toute façon
la sécurité ne peut absolument pas être estimée) est une solution qui
mènera sûrement plus loin.
Je cherche à savoir comment déterminer (algorihmiquement) si un fichier est chiffré (avec un taux de faux positifs/négatifs si possible très faible, de l'ordre de 0.1%).
J'ai donc envisagé de [...] vérifier que [...] l'ensemble "a l'air aléatoire" (par exemple, par examen de la FFT de l'échantillon)
Peur-on considérer que tout fichier chiffré avec un procédé de chiffrement pas trop débile a ces caractéristiques ? Se fera-t-on insulter par une quelconque sommité de la crypto à rejeter comme "non ou mal chiffrés" des fichiers ne présentant pas ces caractéristiques ?
Clairement oui dans ce sens, mais un fichier peut présenter des caractéristiques apparement aléatoire et ne pas être chiffré du tout, par exemple s'il est compressé avec un algorithme vraiment efficace.
C'est donc plutôt dans l'autre sens que tu risque de te faire insulter en ayant des faux positifs sur des fichiers ".bz2" par exemple.
Et la très grande majorité des fichiers chiffrés auront besoin d'un en-tête non aléatoire pour gérer les info de déchiffrement, donc il n'y aura sur un plan purement algorithmique vraiment pas grand chose pour les différencier des fichiers compressés.
L'identification par "magic number" basé sur les en-têtes, et le refus des algo/format de chiffrement totalement inconnus (dont de toute façon la sécurité ne peut absolument pas être estimée) est une solution qui mènera sûrement plus loin.
Bob qui Trolle
Jean-Marc Desperrier wrote:
C'est donc plutôt dans l'autre sens que tu risque de te faire insulter en ayant des faux positifs sur des fichiers ".bz2" par exemple.
Hmmm : en effet.
L'identification par "magic number" basé sur les en-têtes, et le refus des algo/format de chiffrement totalement inconnus (dont de toute façon la sécurité ne peut absolument pas être estimée) est une solution qui mènera sûrement plus loin.
L'idée est séduisante, mais la retenir voudrait dire que la solution retenue ne serait pas pérenne (exigera un MàJ de la liste des nouveaux procédés de chiffrement inventés durant la période entre deux MàJ) et donc, que ça ne scale pas très bien sur le long terme.
Par contre, rien n'interdit de tenter d'identifier des algos de compression : Me trompe-je en supposant qu'on invente moins souvent de nouveaux algos de compression très performants que des algos de crypto (ne serait-ce que parce que la "puissance" d'une compression est facile à mesurer et les algos existants doivent déjà être très proches de la performance maximale imaginable si le problème existe effectivement ?)
Jean-Marc Desperrier wrote:
C'est donc plutôt dans l'autre sens que tu risque de te faire insulter
en ayant des faux positifs sur des fichiers ".bz2" par exemple.
Hmmm : en effet.
L'identification par "magic number" basé sur les en-têtes, et le refus
des algo/format de chiffrement totalement inconnus (dont de toute façon
la sécurité ne peut absolument pas être estimée) est une solution qui
mènera sûrement plus loin.
L'idée est séduisante, mais la retenir voudrait dire que la solution
retenue ne serait pas pérenne (exigera un MàJ de la liste des nouveaux
procédés de chiffrement inventés durant la période entre deux MàJ) et
donc, que ça ne scale pas très bien sur le long terme.
Par contre, rien n'interdit de tenter d'identifier des algos de
compression : Me trompe-je en supposant qu'on invente moins souvent de
nouveaux algos de compression très performants que des algos de crypto
(ne serait-ce que parce que la "puissance" d'une compression est facile
à mesurer et les algos existants doivent déjà être très proches de la
performance maximale imaginable si le problème existe effectivement ?)
C'est donc plutôt dans l'autre sens que tu risque de te faire insulter en ayant des faux positifs sur des fichiers ".bz2" par exemple.
Hmmm : en effet.
L'identification par "magic number" basé sur les en-têtes, et le refus des algo/format de chiffrement totalement inconnus (dont de toute façon la sécurité ne peut absolument pas être estimée) est une solution qui mènera sûrement plus loin.
L'idée est séduisante, mais la retenir voudrait dire que la solution retenue ne serait pas pérenne (exigera un MàJ de la liste des nouveaux procédés de chiffrement inventés durant la période entre deux MàJ) et donc, que ça ne scale pas très bien sur le long terme.
Par contre, rien n'interdit de tenter d'identifier des algos de compression : Me trompe-je en supposant qu'on invente moins souvent de nouveaux algos de compression très performants que des algos de crypto (ne serait-ce que parce que la "puissance" d'une compression est facile à mesurer et les algos existants doivent déjà être très proches de la performance maximale imaginable si le problème existe effectivement ?)
Jean-Marc Desperrier
Bob qui Trolle wrote:
Par contre, rien n'interdit de tenter d'identifier des algos de compression : Me trompe-je en supposant qu'on invente moins souvent de nouveaux algos de compression très performants que des algos de crypto
Les algo de chiffrement vraiment sérieux on en invente pas non plus tous les jours, le processus complet de sélection d'AES a pris plusieurs années.
Bob qui Trolle wrote:
Par contre, rien n'interdit de tenter d'identifier des algos de
compression : Me trompe-je en supposant qu'on invente moins souvent de
nouveaux algos de compression très performants que des algos de crypto
Les algo de chiffrement vraiment sérieux on en invente pas non plus tous
les jours, le processus complet de sélection d'AES a pris plusieurs années.
Par contre, rien n'interdit de tenter d'identifier des algos de compression : Me trompe-je en supposant qu'on invente moins souvent de nouveaux algos de compression très performants que des algos de crypto
Les algo de chiffrement vraiment sérieux on en invente pas non plus tous les jours, le processus complet de sélection d'AES a pris plusieurs années.