AllCrypter : utilisation gratuite jusqu'en 2006

"Guillermito" <guillermito@pipo.com> a écrit dans le message de news:
pmn6cgl56fs8$.tf3lky3xpge7$.dlg@40tude.net...

On Thu, 25 Nov 2004 12:55:53 -0500, Raymond H. wrote:

cela me fait sourire :)

C'est bien, il faut garder le moral. Je crois quand même que vous n'avez
pas saisi le sens profond de mon message précédent. J'ai dû me perdre
dans les détails.

Donc, le fait que les données sont transformées en hexadécimal n'est
pas pour rendre incompréhensible les données cryptées (puisqu'elles sont
déjà incompréhensibles) mais seulement pour rendre compatible avec
Internet
(via courriel) les données déjà cryptées.

J'ai bien compris ça. Je ne confonds pas votre algorithme de chiffrage
avec le fait que vous transformez par la suite du binaire en ASCII, en
utilisant la représentation hexa de chaque octet (entre nous, c'est pas
terrible comme idée, ça multiplie la taille par deux). En fait, ça me
facilite plutôt le travail, puisque je n'ai même pas à regarder le
résultat de votre chiffrage avec un éditeur hexadécimal.

Concernant la clef, elle peut ou non être incluse dans AllCrypter.
Ceci
est au choix de l'utilisateur.

J'ai utilisé les options par défaut.

Si la clef est incluse, alors AllCrypter
pourra vous dire si la clef, dont vous écrivez pour le décryptage, n'est
pas
la bonne pendant que vous tentez de décrypter votre fichier ou vos
données.

Si la clef est incluse, tout le monde peut déchiffrer le message, et
votre logiciel ne sert strictement à rien. C'était mon message
subliminal numéro 1.

Vous faites toute une affirmation ici :-) Moi même avec mes codes

devant mes yeux je n'arriva pas à déchiffrer une clef. Et si tout le monde
'peut' (comme vous le dites) déchiffrer le message si une clef est incluse
alors je vous met au défit de le faire comme tout le monde 'peut' (comme
vous le dites) le faire.

Mon second message subliminal, c'est qu'un algorithme de chiffrement qui
ne modifie que quelques bits du message chiffré quand on modifie un bit
de la clef, est à mettre immédiatement à la poubelle.

Ici il est question de base 256 et évidenment un octet représente 8
bits. D'un octet à l'autre il est normal que leurs bits peuvent se
ressembler à l'oeil, comme dans n'importe quoi. Et ce pas pas parce que
cela 'SEMBLE' à l'oeil facile que l'encryption n'est pas de bonne qualité.
Souvent les choses qui semblent simples sont plus performantes. On voit
cela au fur et à mesure que la technologie se développe. Par exemple si
vous prenez un avion d'armée américaine furtif en forme de triangle presque,
il a l'air d'une forme assez simple. Et pourtant il y a 50 ans les avions
avaient des formes beaucoup plus compliquées. Mais on sait que les avions
d'aujourd'hui sont beaucoup plus performantes même si ceux-ci ont des
ordinateurs de controle que des anciens n'avaient pas. Ce n'est pas parce
que la structure d'une maison semble plus simple qu'elle est moins
avantageuse que les anciennes structures d'il y a quelques sciècles.
Peut-être mon exemple n'est pas ce qu'il y a de mieux mais c'est seulement
pour dire qu'il ne faut pas toujours se fier aux apparences et que ce n'est
pas des pages de calculs qui fait qu'un algorithme est plus performant. Je
crois que les meilleures choses se trouvent souvent dans une simplicité plus
performante.
Mais soyez certain que je ne suis pas en train de dire que je suis
infallible et meilleur que tout le monde. Loin de là! Je ne suis pas là
pour me mesurer à d'autres qui ont fait des programmes de cryptage. Chacun
ont leur façon de faire.

Si je dis que votre réponse me fait sourire, c'est que ca me fait
plaisir de voir que des gens comme vous essais de décortiquer le résultat
crypté en rapport avec votre clef, etc. C'est quand même interressant de
voir la façon de vous raisonnez là-dessus.
N'ésitez pas à me partager vos autres critiques. Elle peuvent être
constructives pour tous.
Sur ce, passez une bonne journée
r.h.

--
Guillermito
http://www.guillermito2.net

On Thu, 25 Nov 2004 03:41:07 -0500, Raymond H. wrote:

Vous pouvez même décrypter
les données d'un fichier sans même décrypter le fichier lui-même

"Guillermito" <guillermito@pipo.com> a écrit
Je ne comprends pas cette phrase. Ou alors elle ne veut rien dire.

"Patrick 'Zener' Brunet" <invalid-use.link@web.page> a écrit

D'un point de vue impartial,
... j'ai cru comprendre qu'il s'agit de déchiffrer à la volée ou en bloc,
mais en tout cas en mémoire pure, sans générer de fichier en clair. Donc
en

l'absence d'un debugger ou autre outil permettant d'analyser la mémoire,
il

n'y aurait pas de fichier en clair (même fugitif et/ou caché) qui puisse
être subrepticement copié au passage par un outil quelconque.

c'est également ce que j'avais interprété - au défaut de le lire.

hélas cette infirmation est gratuite et erronée; Windows swappe comme la
plupart des OS et ne pas faire soi-même de fopen ne garantit nullement
qu'aucune copie disque n'est réalisée.

et pratiquement de telles copies disque seront créées si 1) l'OS est mis en
veille prolongée alors que le soft s'exécute, 2) si un process de plus haute
priorité s'accapare toute la mémoire dispo et au dela (forcant la
réallocation de mémoire virtuelle), 3) si un vilain process (kernel?) dumpe
toute la mémoire.

Sylvain.

"Raymond H." <divers_rh@hotmail.com> a écrit

Ici, lorsqu'une vidéo de 500Mo est déchiffé par exemple, et que
l'utilisateur n'as que 128Mo de mémoire vive (RAM), la seule solution que
je

voie est de stoquer temporairement ces données dans un fichier temporaire
sur le disque, ceci est évident puiqu'il n'entre pas tout dans la mémoire
vive.

un lecteur de vidéo stockée/diffusée chiffrée n'a besoin en clair à un
instant donné que de la définition de la frame rendue (l'image affichée); il
ne devrait en aucun cas ""s'amuser"" à tout déchiffrer avant de commencer la
lecture (remarque: même dans ce cas, un espion pourra capturer l'image en
cours).

par ailleurs, puisque vous vous placez sous Windows, vous pouvez tout à fait
allouer 500Mo même s'il n'existe que 128Mo de RAM physique ... et l'espion
se nourrirra du swap windows au lieu du votre.

au delà de cet exemple, le fait de stocker le résultat clair de la
décryption est une erreur de conception (qu'elle que soit la taille du
fichier); bien sur il est des cas où cet enregistrement clair sera le choix
de l'utilisateur mais on préférera alors régler cela par un conseil donné
plus haut dans ce thread: disposer d'un module crypto (qui n'enregistre
rien, scramble ses données, sait évoluer en environnement hostile, etc...)
et un module applicatif (IHM) qui pourra proposer l'enregistrement en clair
des données traitées.

Sylvain.

"Sylvain" <mail@noSpam.net> a écrit dans le message de news:
41a65a44$0$25127$8fcfb975@news.wanadoo.fr...

On Thu, 25 Nov 2004 03:41:07 -0500, Raymond H. wrote:

Vous pouvez même décrypter
les données d'un fichier sans même décrypter le fichier lui-même

"Guillermito" <guillermito@pipo.com> a écrit
Je ne comprends pas cette phrase. Ou alors elle ne veut rien dire.

"Patrick 'Zener' Brunet" <invalid-use.link@web.page> a écrit

D'un point de vue impartial,
... j'ai cru comprendre qu'il s'agit de déchiffrer à la volée ou en bloc,
mais en tout cas en mémoire pure, sans générer de fichier en clair. Donc
en

l'absence d'un debugger ou autre outil permettant d'analyser la mémoire,
il

n'y aurait pas de fichier en clair (même fugitif et/ou caché) qui puisse
être subrepticement copié au passage par un outil quelconque.

c'est également ce que j'avais interprété - au défaut de le lire.

hélas cette infirmation est gratuite et erronée;

Bonjour,
l'affirmation 'décrypter les données d'un fichier sans même décrypter
le fichier lui-même' est bien exact. En effet, dans ce cas le fichier
lui-même qui est crypté demeure intact et inchangé, mais néanmoins le
fichier est ouvert via un OpenFile afin d'y lire les données cryptées pour
les décrypter par paquets en les mettant temporairement dans un fichier
temporaire pour qu'AllCrypter en fasse la lecture à partir de celui-ci. Par
la suite, ce fichier temporaire est nettoyé (les données sont remplacées par
des espaces pour empêcher des gens d'y lire ses données) puis supprimé du
disque dur. Cette façon de faire est nécessaire surtout avec des vidéos de
plusieurs centaines de méga-octetc qui n'entreraient pas au complet en
mémoire vive lorsque la taille de celle-ci est inférieure à la taille du
fichier lui-même.
r.h.

Windows swappe comme la
plupart des OS et ne pas faire soi-même de fopen ne garantit nullement
qu'aucune copie disque n'est réalisée.

et pratiquement de telles copies disque seront créées si 1) l'OS est mis
en
veille prolongée alors que le soft s'exécute, 2) si un process de plus
haute
priorité s'accapare toute la mémoire dispo et au dela (forcant la
réallocation de mémoire virtuelle), 3) si un vilain process (kernel?)
dumpe
toute la mémoire.

Sylvain.

"Raymond H." <divers_rh@hotmail.com> a écrit

Vous faites toute une affirmation ici :-) Moi même avec mes codes
devant mes yeux je n'arriva pas à déchiffrer une clef.

ce point ne peut que vous discréditer: vous affirmez soit 1) programmer sans
comprendre ce que vous codez (et comment croire à la qualité du résultat),
soit 2) que le chiffrement résulte d'un processus non déterministe .... ou
plutôt 3) vous n'avez pas lu la remarque faite.

Et si tout le monde
'peut' (comme vous le dites) déchiffrer le message si une clef est incluse
alors je vous met au défit de le faire comme tout le monde 'peut' (comme
vous le dites) le faire.

la réponse commune à la forme d'honoraires.

Mon second message subliminal, c'est qu'un algorithme de chiffrement qui
ne modifie que quelques bits du message chiffré quand on modifie un bit
de la clef, est à mettre immédiatement à la poubelle.

Ici il est question de base 256 et évidenment un octet représente 8 bits

merci pour cette avancée.

D'un octet à l'autre il est normal que leurs bits peuvent se
ressembler à l'oeil, comme dans n'importe quoi.

rappel: Guillermito a montré que lorsque l'on change UN bit de la clé, le
chiffré change peu; je reprends un des exemples qu'il vous a fourni (clair:
aaaaaaaaaa):

clé aaaa
chiffre 938D8F91939597999B9597

clé baaa
chiffr 968F8F91939597999D9798

pour vous fournir une comparaison peut être moins subliminale, un algo DES
56 bits tout moisi donne (clair aaaaaaaa):

clé aaaaaaaa
chiffre 29932350C098DB5D

clé baaaaaaa
chiffre 1BA300BCCC9AF9B5

voyez-vous mieux ce que "dépendance du chiffre avec la clé" peut signifier ?

Et ce pas pas parce que cela 'SEMBLE' à l'oeil facile
que l'encryption n'est pas de bonne qualité.

ben si, juste dans 100% des cas.

[..] un avion d'armée américaine furtif en forme de triangle presque,
il a l'air d'une forme assez simple [...]

une aile d'oiseau (et donc d'avion de ligne) est simple; un B2 est très
compliqué et n'est pas un triangle (le reste est classifié).

pour revenir à votre soft, le "débat cryptographique" qui fait l'essentiel
de vos pages ouèbes est peu convaincant - on retiendra que selon vous il
existe des systèmes plus nuls encore, soit.

vos chiffres sur la résistance d'un système vs la taille de la clé sont
multiplement erronés: a) l'utilisateur ne peut saisir pour sa clé que des
caractères imprimables, l'entropie réelle est bien moins que 8 bits/char
(oui, il peut générer un clé (avec un générateur non aléatoire) pour ne pas
pouvoir la resaisir ni (humainement) la mémoriser); par ailleurs casser des
clés (symmétriques) de 64 (vrai) bits ne demande que qlq heures, le temps
exact pour 128 bits serait sujet à controverse mais est accessible.

votre système utiliserait une clé "que vous seul connaissez" mais vous nous
parlez longuement d'échanges de courriel; avez-vous bien ciblé la finalité
du soft ?

l'unique (IMHO) intérêt de votre soft est le couplage d'un système
(prétendument/peut être/quasi/à voir) cryptographique avec un browser
d'image, un player de film/musique (entre autres); une telle application a
en effet un sens car rendant le chiffrement des données transparent pour
l'utilisateur (ordinaire), elle contribue à encourager chacun à protéger sa
vie privée et ses données numériques; une application de cette sorte
utilisant un CSP ou P.11 choisi par l'utilisateur aurait un intérêt.

crdlt,
Sylvain.

"Raymond H." <divers_rh@hotmail.com> a écrit

l'affirmation 'décrypter les données d'un fichier sans même décrypter
le fichier lui-même' est bien exact.

affirmer qu'il fait beau peut être exact aussi...

lorsque le formalisme n'est pas défini et que la proposition n'est qu'un
slogan, chacun peut "affirmer" car personne n'est touché par l'affirmation.

En effet, dans ce cas le fichier
lui-même qui est crypté demeure intact et inchangé, mais néanmoins le
fichier est ouvert via un OpenFile afin d'y lire les données cryptées pour
les décrypter par paquets en les mettant temporairement dans un fichier
temporaire pour qu'AllCrypter en fasse la lecture à partir de celui-ci.

tout le monde a compris que vous faites cela, et tout le monde pensera que
1) c'est inutile (erreur de conception) 2) une faille de sécurité.

n'avez-vous jamais vu une animation flash sur le Net, ni écouté la radio, ni
vu un bout de film ???
où avez-vous vu qu'il faille tout stocker pour commencer l'exploitation ?

Par la suite, ce fichier temporaire est nettoyé (les données sont
remplacées

par des espaces pour empêcher des gens d'y lire ses données) puis
supprimé du disque dur.

consulter (par exemple) le site du NIST ou du DoD pour une définition
(formelle) du terme "nettoyer".
(google NIST wipe sanitization)

Sylvain.

"Sylvain" <mail@noSpam.net> a écrit dans le message de news:
41a66fa4$0$16339$8fcfb975@news.wanadoo.fr...

"Raymond H." <divers_rh@hotmail.com> a écrit

l'affirmation 'décrypter les données d'un fichier sans même décrypter
le fichier lui-même' est bien exact.

affirmer qu'il fait beau peut être exact aussi...

lorsque le formalisme n'est pas défini et que la proposition n'est qu'un
slogan, chacun peut "affirmer" car personne n'est touché par
l'affirmation.

En effet, dans ce cas le fichier
lui-même qui est crypté demeure intact et inchangé, mais néanmoins le
fichier est ouvert via un OpenFile afin d'y lire les données cryptées
pour
les décrypter par paquets en les mettant temporairement dans un fichier
temporaire pour qu'AllCrypter en fasse la lecture à partir de celui-ci.

tout le monde a compris que vous faites cela, et tout le monde pensera que
1) c'est inutile (erreur de conception) 2) une faille de sécurité.

Il est à remarquer qu'AllCrypter ne se limite pas seulement à faire la
lecture d'une vidéo, mais une personne pourrait par exemple ouvrir une image
dans l'une des fenêtres d'AllCrypter pour y insérer un message crypté ou une
autre image qui elle est cryptée. Ce n'est qu'un exemple, mais les
possibilités sont beaucoup plus grande. Donc ici, une image doit être
complètement lu et mis en mémoire pour être affiché à l'écran; et cela
n'empêche pas à un logiciel espion de faire une capture de l'écran de
l'utilisateur. Et dans ce cas, la faille de sécurité n'est pas AllCrypter
mais cette faille est sur l'ordinateur de l'utilisateur qui doit protéger
son environnement des logiciels espions. Il ne faut pas prendre non plus
AllCrypter pour un firewall ou un utilitaire servant à protéger l'ordinateur
de l'utilisateur; ce n'est pas son but. Et de plus, si Windows crée un
fichier swap pour ses propres services cela ne remonte pas de l'autorité
d'AllCrypter pour aller le supprimer pour faire planter l'ordi de
l'utilisateur. Je dis seulement, que les fichiers qu'AllCrypter crée
temporairement pour ses propres besoins sont nettoyés puis supprimés. Le
termes nettoyer un fichier signifie bien changer ses données contre d'autres
données, par exemple des espaces, des zéros ou des un. Ensuite AllCrypter le
supprime. Donc, ce qu'AllCrypter crée, il le nettoie et le supprime.
De plus lorsqu'AllCrypter décrypte les données d'une vidéo de 500Mo par
exemple, cette vidéo est lu à partir d'un fichier temporaire qui ne laisse
plus sa trace après avoir été nettoyer et supprimer par AllCrypter. De
plus, lorsqu'une vidéo est lu à partir de ce fichier temporaire, elle n'est
sûrement pas recopié dans le fichier swap de Windows; je met au défit à
quiconque de vérifier que son fichier swap ou autre prend 500Mo de plus lors
de la lecture d'une vidéo dans AllCrypter. Dans AllCrypter, la lecture peut
se faire par petite portion au fur et à mesure de l'avancement de sa
lecture. On ne trouve donc pas l'ensemble de ces donnée copié ailleurs sur
le disque par Windows dans un fichier temporaire.

n'avez-vous jamais vu une animation flash sur le Net, ni écouté la radio,
ni
vu un bout de film ???
où avez-vous vu qu'il faille tout stocker pour commencer l'exploitation ?

Je comprend ce principe mais cela demanderait une codification différente
ainsi que des modules en surplus. Chacun sa façon de faire pour simplifier
les choses. Mais je comprend quand même ce que vous voulez dire. Et peu
importe la façon employée cela n'empêche pas un logiciel espion de prendre
des captures de l'écran de l'utilisateur si son ordinateur n'est pas
protégé; ainsi en est-il pour les touches du claviers pressées ou le son
joué.

Par la suite, ce fichier temporaire est nettoyé (les données sont
remplacées

par des espaces pour empêcher des gens d'y lire ses données) puis
supprimé du disque dur.

consulter (par exemple) le site du NIST ou du DoD pour une définition
(formelle) du terme "nettoyer".

Un fichier qui ne contient que des 'A' et qu'on remplace tous ses 'A'
par des '0' alors ce fichier a été nettoyé. Peut importe que l'écriture se
fasse une ou 5 fois. Quand on nettoie une table on enlève la saleté qui est
dessus.
C'est comme me dire que le mot encrypter signifie décrypter sans avoir
besoin de la clef, et pourtant cette définition existe. Ce terme
'encrypter' est un anglisisme. Mais un même terme peut avoir différentes
significations et pourtant au fil des âges un terme peut changer de
définition ou en avoir une ou plusieurs de plus. Et peut être causé par
l'emploie et l'acceptation du terme par la multitude.
Or, ce terme 'encrypter' que je ne trouve même pas dans mon dictionnaire
français chez moi (le Petit Robert qui date de quelques années), a aussi la
signification de crypter des données selon beaucoup de personne de la
communauté Internaute. La multitude le confirme et ce mot est accepté dans
une très grande échelle sur la planète. C'est pourquoi je pense que ce
deuxième sens devraient être dans le dictionnaire de la langue française.
Mais cela est sujet à interprétation selon l'acceptation que chacun en fait.
C'est comme d'autres mots ayant différentes significations au fils du temps,
ou un même mot ayant un sens en France et un autre sens au Québec. Tout
ceci pour dire qu'ici le terme 'nettoyer' un fichier signifie bien changer
les données dans un fichier en les remplacant par d'autre données, et ce
remplacement est obligatoire car s'il n'y a pas de 1 (un: présence) sur le
disque on y lit des 0 (zéro: absence). Passons...

(google NIST wipe sanitization)

Sylvain.


Je vous remerci néanmoins pour vos commentaires constructifs qui amènent à

des réflexions intéressantes.
Bonne journée
r.h.

"Sylvain" <mail@noSpam.net> a écrit dans le message de news:
41a66c7e$0$31678$8fcfb975@news.wanadoo.fr...

"Raymond H." <divers_rh@hotmail.com> a écrit

Vous faites toute une affirmation ici :-) Moi même avec mes codes
devant mes yeux je n'arriva pas à déchiffrer une clef.

ce point ne peut que vous discréditer: vous affirmez soit 1) programmer
sans
comprendre ce que vous codez (et comment croire à la qualité du résultat),
soit 2) que le chiffrement résulte d'un processus non déterministe .... ou
plutôt 3) vous n'avez pas lu la remarque faite.

Ici, je parle du fait de décrypter sans avoir la clef; cela je n'y
arrive pas moi-même, et je ne dois pas être capable de faire cela. Si j'y
arriverais, alors cela me discréditerait. Je ne me procurerais jamais un
logiciel d'encryptage si son programmeur est capable de décrypter mes
données sans avoir ma clef; cela ne serait pas bon.

Et si tout le monde
'peut' (comme vous le dites) déchiffrer le message si une clef est
incluse
alors je vous met au défit de le faire comme tout le monde 'peut' (comme
vous le dites) le faire.

la réponse commune à la forme d'honoraires.

Mon second message subliminal, c'est qu'un algorithme de chiffrement
qui
ne modifie que quelques bits du message chiffré quand on modifie un bit
de la clef, est à mettre immédiatement à la poubelle.

Ici il est question de base 256 et évidenment un octet représente 8 bits

merci pour cette avancée.

D'un octet à l'autre il est normal que leurs bits peuvent se
ressembler à l'oeil, comme dans n'importe quoi.

rappel: Guillermito a montré que lorsque l'on change UN bit de la clé, le
chiffré change peu; je reprends un des exemples qu'il vous a fourni
(clair:
aaaaaaaaaa):

clé aaaa
chiffre 938D8F91939597999B9597

clé baaa
chiffr 968F8F91939597999D9798

pour vous fournir une comparaison peut être moins subliminale, un algo DES
56 bits tout moisi donne (clair aaaaaaaa):

clé aaaaaaaa
chiffre 29932350C098DB5D

clé baaaaaaa
chiffre 1BA300BCCC9AF9B5

voyez-vous mieux ce que "dépendance du chiffre avec la clé" peut signifier
?

Je comprend ce que vous amenez. Mais cette exemple semble donner
l'impression d'une certaine facilité pour la recherche d'une clef utilisée.
Mais comme je dis, cela SEMBLE. Essayez des caractères différents et vous
verrez que cette route ne tiendra plus.
De plus, si cela adonne que le fait de ne changer qu'un seul caractère
de la clef ne donne que quelques changements au niveau des données cryptées
(et ici il faut mentionné que la chaine est courte avec des caractères
répétés) cela ne veut rien dire puisque les données cryptées sont quand même
différentes. Le nombre 100 000 donne un certain nombre de possibilités de
combinaisons, et en changeant ce nombre par le nombre 100 001 cela donnera
quand même au moins le même nombre de possibilité de recherche pour trouver
la clef. Qu'il n'y ait qu'une seule donnée qui change ou que toutes les
données changent cela ne rend pas obligatoirement moins difficile à trouver
la clef et le nombre de possibilité peut être autant. Et concernant le
calcul apparant des bits cela ne diffère à rien, à mon avis, concernant le
nombre de possibilité de calculs différents possiblement réalisable.

Cordialement
r.h.

Et ce pas pas parce que cela 'SEMBLE' à l'oeil facile
que l'encryption n'est pas de bonne qualité.

ben si, juste dans 100% des cas.

[..] un avion d'armée américaine furtif en forme de triangle presque,
il a l'air d'une forme assez simple [...]

une aile d'oiseau (et donc d'avion de ligne) est simple; un B2 est très
compliqué et n'est pas un triangle (le reste est classifié).

pour revenir à votre soft, le "débat cryptographique" qui fait l'essentiel
de vos pages ouèbes est peu convaincant - on retiendra que selon vous il
existe des systèmes plus nuls encore, soit.

vos chiffres sur la résistance d'un système vs la taille de la clé sont
multiplement erronés: a) l'utilisateur ne peut saisir pour sa clé que des
caractères imprimables, l'entropie réelle est bien moins que 8 bits/char
(oui, il peut générer un clé (avec un générateur non aléatoire) pour ne
pas
pouvoir la resaisir ni (humainement) la mémoriser); par ailleurs casser
des
clés (symmétriques) de 64 (vrai) bits ne demande que qlq heures, le temps
exact pour 128 bits serait sujet à controverse mais est accessible.

votre système utiliserait une clé "que vous seul connaissez" mais vous
nous
parlez longuement d'échanges de courriel; avez-vous bien ciblé la finalité
du soft ?

l'unique (IMHO) intérêt de votre soft est le couplage d'un système
(prétendument/peut être/quasi/à voir) cryptographique avec un browser
d'image, un player de film/musique (entre autres); une telle application a
en effet un sens car rendant le chiffrement des données transparent pour
l'utilisateur (ordinaire), elle contribue à encourager chacun à protéger
sa
vie privée et ses données numériques; une application de cette sorte
utilisant un CSP ou P.11 choisi par l'utilisateur aurait un intérêt.

crdlt,
Sylvain.

Raymond H. a écrit le vendredi 26 Novembre 2004 05:34 :

consulter (par exemple) le site du NIST ou du DoD pour une définition
(formelle) du terme "nettoyer".

Un fichier qui ne contient que des 'A' et qu'on remplace tous ses 'A'
par des '0' alors ce fichier a été nettoyé.  Peut importe que l'écriture
se fasse une ou 5 fois.

Non. Il reste toujours des traces magnétiques

@+
--
Thomas Labourdette

On Fri, 26 Nov 2004 00:37:39 -0500, Raymond H. <divers_rh@hotmail.com>
wrote:

Le nombre 100 000 donne un certain nombre de possibilités de
combinaisons, et en changeant ce nombre par le nombre 100 001 cela
donnera quand même au moins le même nombre de possibilité de recherche
pour trouver la clef. Qu'il n'y ait qu'une seule donnée qui change
ou que toutes les données changent cela ne rend pas obligatoirement
moins difficile à trouver la clef et le nombre de possibilité peut
être autant. Et concernant le calcul apparant des bits cela ne diffère
à rien, à mon avis, concernant le nombre de possibilité de calculs
différents possiblement réalisable.

Vous avez l'air de penser que le seul moyen de "casser" une clef est la
force brute (essayer toutes les combinaisons jusqu'à ce qu'on tombe sur la
bonne). Je pense qu'il faudrait que vous essayez d'éviter de réinventer la
roue (et une mauvaise en plus) et que vous appreniez ce qu'est la
cryptanalyse. C'est le minimum avant de s'improviser cryptographe: c'est
un peu comme si quelqu'un tentait de concevoir une nouvelle serrure sans
se demander comment les voleurs font pour ouvrir les précédentes sans les
clefs.

On notera au passage que la version encodée (je dis bien encodée et pas
"cryptée" ou chiffrée) de la clef stockée dans le fichier présente des
collisions. Les clefs " " (4 espaces) et "````" donnent le même
résultat (81 83 85 87 89 8B 8D). Pour un encodage qui prend presque deux
fois plus de place que l'original, c'est quand même pas terrible!

On note aussi que si tous les caractères sont identiques on a un +2
d'octet en octet, a priori quelque soit le caractère en question (j'ai pas
vérifié in extenso). Il semblerait que certaines transitions soient liées
en fait à la différence entre deux caractères de la clef, le reste
provenant de vagues permutations de bits sur les différents caractères. Je
pense que quelques heures (que je n'ai pas) devraient permettre de trouver
la clef (ou plutôt les clefs) qui correspondent à la version encodée dans
le fichier.

Je pense qu'il y en a qui vont bien rigoler.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/