AllCrypter : utilisation gratuite jusqu'en 2006

shen

26/11/2004 à 15:17

On Fri, 26 Nov 2004 08:56:08 -0500
Guillermito wrote:

On Fri, 26 Nov 2004 15:01:17 +0100, AMcD® wrote:

J'ai pas regardé, mais je suppose qu'on peut désassembler son truc
facile non ?

C'est interdit par la licence d'utilisation. Et tu sais combien je suis
respectueux de ce genre de chose. Hmm. En plus, c'est du Visual Basic,
et c'est une horreur de regarder ça avec un désassembleur.

Mais dans une optique de compatibilité avec gpg, on a le droit de faire du
reverse-engineering non ? :)

--
shen
"You know what, I'm happy..."
Droopy

Jacques Caron

26/11/2004 à 15:25

On Fri, 26 Nov 2004 08:56:08 -0500, Guillermito
wrote:

On Fri, 26 Nov 2004 15:01:17 +0100, AMcD® wrote:

J'ai pas regardé, mais je suppose qu'on peut désassembler son truc
facile
non ?

C'est interdit par la licence d'utilisation.

Ce qui m'a fait bien rire. Rappelons que le Code de la Propriété
Intellectuelle nous dit, dans son Article L122-6-1:

[...]
IV. La reproduction du code du logiciel ou la traduction de la forme de
ce code n'est pas soumise à l'autorisation de l'auteur lorsque la
reproduction ou la traduction au sens du 1º ou du 2º de l'article L. 122-6
est indispensable pour obtenir les informations nécessaires à
l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres
logiciels, sous réserve que soient réunies les conditions suivantes :
1º Ces actes sont accomplis par la personne ayant le droit d'utiliser
un exemplaire du logiciel ou pour son compte par une personne habilitée à
cette fin ;
2º Les informations nécessaires à l'interopérabilité n'ont pas déjà été
rendues facilement et rapidement accessibles aux personnes mentionnées au
1º ci-dessus ;
3º Et ces actes sont limités aux parties du logiciel d'origine
nécessaires à cette interopérabilité.
[...]
Toute stipulation contraire aux dispositions prévues aux II, III et IV
du présent article est nulle et non avenue.

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

pornin

26/11/2004 à 17:41

According to Patrick 'Zener' Brunet <http://zener131.free.fr/ContactMe>:

De toute manière, l'objectif lui-même est un peu théorique, puisque si l'on
décode de la vidéo (ou du son ou quoique ce soit d'autre) pour l'injecter
dans un stream, même s'il est possible de le faire à la volée sans créer une
version en clair de l'ensemble, il sera toujours possible de recapturer le
signal au niveau du stream (voire de la sortie écran ou audio) pour le
réenregistrer en clair (ce qui au passage fout en l'air le principe même de
la protection de CD ou de DVD, à moins qu'on n'ait plus le droit de même les
visionner !!!!).

Soyons précis : le modèle n'est pas le même. Il est vrai que lorsqu'une
donnée doit être traitée par la machine, elle est fatalement disponible
en clair dans la mémoire de cette machine à un moment donné(*), et donc
si la machine est compromise à ce moment, c'est mort.

En revanche, tant que la machine tourne et, par exemple, affiche une
vidéo, l'utilisateur est normalement devant et applique un contrôle
"physique" sur la machine. Le fait d'écrire les données sur le disque,
même "temporairement", rend les données vulnérables à des attaques
ultérieures, à des moments où la machine n'est plus sous contrôle
physique direct.

Autrement dit, si le gars se fait piquer son portable en prenant le
métro, c'est juste gavant si les données secrète n'ont été traitées
qu'en RAM (et non envoyées dans le swap) ; si elles ont été écrites
sur le disque, c'est carrément critique.

En bref, faire l'effort de garder les données en RAM seulement a un
intérêt. Mais bien sûr tout dépend du contexte d'attaque (qui doit être
défini préalablement à toute discussion sereine sur la sécurité d'un
système).

des options de pagination

On peut en effet demander à l'OS de ne pas envoyer dans le swap des
pages données. Il faut déjà identifier les pages (ça n'a rien d'évident
dans certains langages de programmations dits "sûrs", comme Java ou
OCaml, surtout qu'avec un garbage collector qui déplace les objets, "la"
page qui contient la donnée n'est même pas bien définie) et ensuite l'OS
peut avoir des restrictions. Windows n'autorise qu'une taille finie
et pas forcément très élevée. Unix aussi, et en plus l'appel système
afférent (mlock()) est réservé à root.

Finalement c'est cet aspect jeu d'échecs qui rend la crypto
passionnante, non ?

Jusqu'à un certain point. La cryptographie moderne essaye de plus en
plus de faire des preuves de sécurité, afin de sortir du modèle où le
système est sûr parce que le concepteur serait plus "malin" ou "rusé"
que l'attaquant. On préfère des systèmes sûrs parce qu'ils reposent sur
une structure mathématiquement justifiée.

--Thomas Pornin

According to Patrick 'Zener' Brunet <http://zener131.free.fr/ContactMe>:

De toute manière, l'objectif lui-même est un peu théorique, puisque si l'on
décode de la vidéo (ou du son ou quoique ce soit d'autre) pour l'injecter
dans un stream, même s'il est possible de le faire à la volée sans créer une
version en clair de l'ensemble, il sera toujours possible de recapturer le
signal au niveau du stream (voire de la sortie écran ou audio) pour le
réenregistrer en clair (ce qui au passage fout en l'air le principe même de
la protection de CD ou de DVD, à moins qu'on n'ait plus le droit de même les
visionner !!!!).

Soyons précis : le modèle n'est pas le même. Il est vrai que lorsqu'une
donnée doit être traitée par la machine, elle est fatalement disponible
en clair dans la mémoire de cette machine à un moment donné(*), et donc
si la machine est compromise à ce moment, c'est mort.

En revanche, tant que la machine tourne et, par exemple, affiche une
vidéo, l'utilisateur est normalement devant et applique un contrôle
"physique" sur la machine. Le fait d'écrire les données sur le disque,
même "temporairement", rend les données vulnérables à des attaques
ultérieures, à des moments où la machine n'est plus sous contrôle
physique direct.

Autrement dit, si le gars se fait piquer son portable en prenant le
métro, c'est juste gavant si les données secrète n'ont été traitées
qu'en RAM (et non envoyées dans le swap) ; si elles ont été écrites
sur le disque, c'est carrément critique.

En bref, faire l'effort de garder les données en RAM seulement a un
intérêt. Mais bien sûr tout dépend du contexte d'attaque (qui doit être
défini préalablement à toute discussion sereine sur la sécurité d'un
système).

des options de pagination

On peut en effet demander à l'OS de ne pas envoyer dans le swap des
pages données. Il faut déjà identifier les pages (ça n'a rien d'évident
dans certains langages de programmations dits "sûrs", comme Java ou
OCaml, surtout qu'avec un garbage collector qui déplace les objets, "la"
page qui contient la donnée n'est même pas bien définie) et ensuite l'OS
peut avoir des restrictions. Windows n'autorise qu'une taille finie
et pas forcément très élevée. Unix aussi, et en plus l'appel système
afférent (mlock()) est réservé à root.

Finalement c'est cet aspect jeu d'échecs qui rend la crypto
passionnante, non ?

Jusqu'à un certain point. La cryptographie moderne essaye de plus en
plus de faire des preuves de sécurité, afin de sortir du modèle où le
système est sûr parce que le concepteur serait plus "malin" ou "rusé"
que l'attaquant. On préfère des systèmes sûrs parce qu'ils reposent sur
une structure mathématiquement justifiée.

--Thomas Pornin

Vous avez filtré cet utilisateur ! Consultez son message

According to Patrick 'Zener' Brunet <http://zener131.free.fr/ContactMe>:

De toute manière, l'objectif lui-même est un peu théorique, puisque si l'on
décode de la vidéo (ou du son ou quoique ce soit d'autre) pour l'injecter
dans un stream, même s'il est possible de le faire à la volée sans créer une
version en clair de l'ensemble, il sera toujours possible de recapturer le
signal au niveau du stream (voire de la sortie écran ou audio) pour le
réenregistrer en clair (ce qui au passage fout en l'air le principe même de
la protection de CD ou de DVD, à moins qu'on n'ait plus le droit de même les
visionner !!!!).

Soyons précis : le modèle n'est pas le même. Il est vrai que lorsqu'une
donnée doit être traitée par la machine, elle est fatalement disponible
en clair dans la mémoire de cette machine à un moment donné(*), et donc
si la machine est compromise à ce moment, c'est mort.

En revanche, tant que la machine tourne et, par exemple, affiche une
vidéo, l'utilisateur est normalement devant et applique un contrôle
"physique" sur la machine. Le fait d'écrire les données sur le disque,
même "temporairement", rend les données vulnérables à des attaques
ultérieures, à des moments où la machine n'est plus sous contrôle
physique direct.

Autrement dit, si le gars se fait piquer son portable en prenant le
métro, c'est juste gavant si les données secrète n'ont été traitées
qu'en RAM (et non envoyées dans le swap) ; si elles ont été écrites
sur le disque, c'est carrément critique.

En bref, faire l'effort de garder les données en RAM seulement a un
intérêt. Mais bien sûr tout dépend du contexte d'attaque (qui doit être
défini préalablement à toute discussion sereine sur la sécurité d'un
système).

des options de pagination

On peut en effet demander à l'OS de ne pas envoyer dans le swap des
pages données. Il faut déjà identifier les pages (ça n'a rien d'évident
dans certains langages de programmations dits "sûrs", comme Java ou
OCaml, surtout qu'avec un garbage collector qui déplace les objets, "la"
page qui contient la donnée n'est même pas bien définie) et ensuite l'OS
peut avoir des restrictions. Windows n'autorise qu'une taille finie
et pas forcément très élevée. Unix aussi, et en plus l'appel système
afférent (mlock()) est réservé à root.

Finalement c'est cet aspect jeu d'échecs qui rend la crypto
passionnante, non ?

Jusqu'à un certain point. La cryptographie moderne essaye de plus en
plus de faire des preuves de sécurité, afin de sortir du modèle où le
système est sûr parce que le concepteur serait plus "malin" ou "rusé"
que l'attaquant. On préfère des systèmes sûrs parce qu'ils reposent sur
une structure mathématiquement justifiée.

--Thomas Pornin

Jean-Marc Desperrier

26/11/2004 à 18:30

Sylvain wrote:

[...]; 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.

Faut pas raconter n'importe quoi non plus !!!

Distributed.net a eu besoin pour casser du 64 bits de 331 252 volontaire
et 5 années :
http://www1.distributed.net/pressroom/news-20020926.txt

Au meilleur moment, la puissance de calcul réunie était l'équivalent
45998 Athlon à 2GHz (on va dire 46000).

Or même s'ils avaient eu cette puissance de calcul disponible pendant
tout le projet, il leur aurait quand même fallu d'après leur calcul 790
jours pour casser, soit plus de 2 ans.

Les 128 bits, comme de bien entendu, présentent la même difficulté de
cassage par rapport à du 64 bits que le 64 bits par rapport à 1 bit.

C'est à dire que avec la même technologie, il faut multiplier les "2 ans
x 46000 " par le rapport avec le temps nécessaire pour casser
une clé de 1 bit, qui doit être de l'ordre de quelques centième de seconde.

Le résultat se compte même plus en millions d'années :-)

Inet

26/11/2004 à 22:45

Bien, sûr, j'ai récupéré des données dans ces conditions alors que j'étais
en prestation au ministère de l'intérieur rue Nélaton (Services Techniques).
Le problème est que la polarisation des cristaux du support magnétique ne
touche pas les cristaux aux extrémités de la t^te de lecture. On en retrouve
suffsiamment pour déteminer la précédente valeur stockée (parfois plusieurs
valeurs antécédentes). Mais le contenu sémantique permet de retrouver en fin
de compte les éléméents tant que les clusters n'ont pas été réaffectés...

Inet

Sylvain

26/11/2004 à 22:52

"Jean-Marc Desperrier" a écrit

[...]; 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.

Faut pas raconter n'importe quoi non plus !!!

Distributed.net a eu besoin pour casser du 64 bits de 331 252 volontaire
et 5 années :
http://www1.distributed.net/pressroom/news-20020926.txt

Au meilleur moment, la puissance de calcul réunie était l'équivalent
45998 Athlon à 2GHz (on va dire 46000).

[..] cette puissance de calcul disponible pendant tout
le projet, il leur aurait quand même fallu [...] plus de 2 ans.

mon point n'était pas de prétendre de tout se casse facilement en 3 jours;
je voulais simplement dire que les prétendus temps de résistance des clés
listés sur le site du soft débattu ici sont débiles.

les résultats d'expériences comme celle cité ici pour le RC5 ne sont pas une
loi: les machines utilisées ne sont pas spécialement optimisées pour
l'opération (pas de dispositif hard), le calcul n'est pas massivement
parallélisé, il tourne généralement en tache de fond (économiseur), il
repose sur une distribution aléatoire des clés candidates - le hasard, assez
improbable, aurait pu distribuer la bonne clé candidate dès la 1ière minute.

ces résultats me paraissent également non révélateur de la puissance de
calcul - et des stratégies de calcul - que pourrait déployer une entité
voulant absolument casser une clé - les démons de la NSA plane sur nous ;-)

enfin, prétendre qu'il faut X millions d'années pour casser un clé de n bits
pose - car l'estimation est généralement faite au regard de moyens actuels -
que d'ici 1 million d'année les méthodes et la puissance de calcul seront
resté constantes et qu'il faudra encore X - 1 millions d'années pour finir
la tache.

le contrepied à ces délais avec plein de zéros - sonvent matraqués sur un
air de lave-plus-blanc - peuvent être la modestie et le pragmatisme, non ?
j'espère que mon point n'était pas perçu comme du catastrophisme.

Sylvain.

"Jean-Marc Desperrier" <jmdesp@alussinan.org> a écrit

[...]; 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.

Faut pas raconter n'importe quoi non plus !!!

Distributed.net a eu besoin pour casser du 64 bits de 331 252 volontaire
et 5 années :
http://www1.distributed.net/pressroom/news-20020926.txt

Au meilleur moment, la puissance de calcul réunie était l'équivalent
45998 Athlon à 2GHz (on va dire 46000).

[..] cette puissance de calcul disponible pendant tout
le projet, il leur aurait quand même fallu [...] plus de 2 ans.

mon point n'était pas de prétendre de tout se casse facilement en 3 jours;
je voulais simplement dire que les prétendus temps de résistance des clés
listés sur le site du soft débattu ici sont débiles.

les résultats d'expériences comme celle cité ici pour le RC5 ne sont pas une
loi: les machines utilisées ne sont pas spécialement optimisées pour
l'opération (pas de dispositif hard), le calcul n'est pas massivement
parallélisé, il tourne généralement en tache de fond (économiseur), il
repose sur une distribution aléatoire des clés candidates - le hasard, assez
improbable, aurait pu distribuer la bonne clé candidate dès la 1ière minute.

ces résultats me paraissent également non révélateur de la puissance de
calcul - et des stratégies de calcul - que pourrait déployer une entité
voulant absolument casser une clé - les démons de la NSA plane sur nous ;-)

enfin, prétendre qu'il faut X millions d'années pour casser un clé de n bits
pose - car l'estimation est généralement faite au regard de moyens actuels -
que d'ici 1 million d'année les méthodes et la puissance de calcul seront
resté constantes et qu'il faudra encore X - 1 millions d'années pour finir
la tache.

le contrepied à ces délais avec plein de zéros - sonvent matraqués sur un
air de lave-plus-blanc - peuvent être la modestie et le pragmatisme, non ?
j'espère que mon point n'était pas perçu comme du catastrophisme.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

"Jean-Marc Desperrier" a écrit

[...]; 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.

Faut pas raconter n'importe quoi non plus !!!

Distributed.net a eu besoin pour casser du 64 bits de 331 252 volontaire
et 5 années :
http://www1.distributed.net/pressroom/news-20020926.txt

Au meilleur moment, la puissance de calcul réunie était l'équivalent
45998 Athlon à 2GHz (on va dire 46000).

[..] cette puissance de calcul disponible pendant tout
le projet, il leur aurait quand même fallu [...] plus de 2 ans.

mon point n'était pas de prétendre de tout se casse facilement en 3 jours;
je voulais simplement dire que les prétendus temps de résistance des clés
listés sur le site du soft débattu ici sont débiles.

les résultats d'expériences comme celle cité ici pour le RC5 ne sont pas une
loi: les machines utilisées ne sont pas spécialement optimisées pour
l'opération (pas de dispositif hard), le calcul n'est pas massivement
parallélisé, il tourne généralement en tache de fond (économiseur), il
repose sur une distribution aléatoire des clés candidates - le hasard, assez
improbable, aurait pu distribuer la bonne clé candidate dès la 1ière minute.

ces résultats me paraissent également non révélateur de la puissance de
calcul - et des stratégies de calcul - que pourrait déployer une entité
voulant absolument casser une clé - les démons de la NSA plane sur nous ;-)

enfin, prétendre qu'il faut X millions d'années pour casser un clé de n bits
pose - car l'estimation est généralement faite au regard de moyens actuels -
que d'ici 1 million d'année les méthodes et la puissance de calcul seront
resté constantes et qu'il faudra encore X - 1 millions d'années pour finir
la tache.

le contrepied à ces délais avec plein de zéros - sonvent matraqués sur un
air de lave-plus-blanc - peuvent être la modestie et le pragmatisme, non ?
j'espère que mon point n'était pas perçu comme du catastrophisme.

Sylvain.

Raymond H.

27/11/2004 à 00:13

"AMcD®" a écrit dans le message de news:
41a73729$0$21266$

Guillermito wrote:

[...]

Laisse-tomber. Le gars va modifier son truc sans cesse et comme personne
n'aura le temps ou l'envie de le lui démonter, ou bien se lassera, il
répondra "ben vas-y, casse-le mon algo ! J'ai proposé de le casser
personne n'y est arrivé, donc, c'est le meilleur, incassable, blabla."

Bonjour,

je ne dis et pense pas du tout cela. Je tiens à préciser que je suis
personnellement reconnaissant à l'égard de ceux et de celles qui tentent de
m'aider soit par leur critiques constructives ou soit par le temps qu'ils
mettent à tenter de démontrer si vraiment il est préférable ou non de
modifier la façon que j'ai d'avoir intégré la clef avec les données. Je
m'applique donc à suivre le fil de vos discussions (qui sont très
intérressantes) afin d'en tirer profit. Plusieurs têtes valent souvent mieux
qu'une.

Tu sais très bien comment ça va finir.

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi j'ajoute
qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il génère
temporairement un fichier (qu'il nettoie et supprime par la suite) afin d'en
faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap (temporaire).
Faites-en le test et vous verrez.
Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant j'essais
d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation. J'ai une façon de faire et d'autre ont leur façon de faire
et j'ai mes limites intellectuelles comme d'autres ont leur leur; il y a
toujours meilleur que nous.

Et puis bon, le gars qui te dit "moi, j'arrive pas à le casser, alors...",
ben tu peux passer en mode "Lol" direct...

En réalité j'aurais pu pousser plus loin mes tentatives d'essayer de

trouver un moyen d'arriver à trouver une solution permettant la décryption
d'une clef au sein des données cryptées. Mais je dis que si j'aurais trouvé
un solution permettant à décrypter une clef faisant partie intégrante des
données cryptées alors je ne l'aurais jamais intégrée de la façon actuelle.
Ceci dit, je ne dis pas non plus qu'il est impossible de quelques façons que
ce soit que la solution pourrait être trouvée, mais si ce serait le cas
alors j'aurai appris à faire les choses différenment et je modifierais la
façon de faire dans mes codes tout en gardant la compatibilité pour la
décryption des fichiers (ou données) qui ont été auparavant cryptés avec les
versions précédentes du logiciel.
Bonne journée :)
r.h.

En crypto, le gars qui file pas ses algorithmes, il se discrédite
lui-même, tout seul.

Enfin, puisque c'est à but commercial, pourquoi des "amateurs" devraient
se soucier de son cas ? S'il veut en tirer bénéfice, ben à lui d'en
assurer une étude professionnelle, avec tout ce que ce terme sous-entend.

J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile
non ?

--
AMcD®

http://arnold.mcdonald.free.fr/

"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
41a73729$0$21266$626a14ce@news.free.fr...

Guillermito wrote:

[...]

Laisse-tomber. Le gars va modifier son truc sans cesse et comme personne
n'aura le temps ou l'envie de le lui démonter, ou bien se lassera, il
répondra "ben vas-y, casse-le mon algo ! J'ai proposé de le casser
personne n'y est arrivé, donc, c'est le meilleur, incassable, blabla."

Bonjour,

je ne dis et pense pas du tout cela. Je tiens à préciser que je suis
personnellement reconnaissant à l'égard de ceux et de celles qui tentent de
m'aider soit par leur critiques constructives ou soit par le temps qu'ils
mettent à tenter de démontrer si vraiment il est préférable ou non de
modifier la façon que j'ai d'avoir intégré la clef avec les données. Je
m'applique donc à suivre le fil de vos discussions (qui sont très
intérressantes) afin d'en tirer profit. Plusieurs têtes valent souvent mieux
qu'une.

Tu sais très bien comment ça va finir.

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi j'ajoute
qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il génère
temporairement un fichier (qu'il nettoie et supprime par la suite) afin d'en
faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap (temporaire).
Faites-en le test et vous verrez.
Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant j'essais
d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation. J'ai une façon de faire et d'autre ont leur façon de faire
et j'ai mes limites intellectuelles comme d'autres ont leur leur; il y a
toujours meilleur que nous.

Et puis bon, le gars qui te dit "moi, j'arrive pas à le casser, alors...",
ben tu peux passer en mode "Lol" direct...

En réalité j'aurais pu pousser plus loin mes tentatives d'essayer de

trouver un moyen d'arriver à trouver une solution permettant la décryption
d'une clef au sein des données cryptées. Mais je dis que si j'aurais trouvé
un solution permettant à décrypter une clef faisant partie intégrante des
données cryptées alors je ne l'aurais jamais intégrée de la façon actuelle.
Ceci dit, je ne dis pas non plus qu'il est impossible de quelques façons que
ce soit que la solution pourrait être trouvée, mais si ce serait le cas
alors j'aurai appris à faire les choses différenment et je modifierais la
façon de faire dans mes codes tout en gardant la compatibilité pour la
décryption des fichiers (ou données) qui ont été auparavant cryptés avec les
versions précédentes du logiciel.
Bonne journée :)
r.h.

En crypto, le gars qui file pas ses algorithmes, il se discrédite
lui-même, tout seul.

Enfin, puisque c'est à but commercial, pourquoi des "amateurs" devraient
se soucier de son cas ? S'il veut en tirer bénéfice, ben à lui d'en
assurer une étude professionnelle, avec tout ce que ce terme sous-entend.

J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile
non ?

--
AMcD®

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

"AMcD®" a écrit dans le message de news:
41a73729$0$21266$

Guillermito wrote:

[...]

Laisse-tomber. Le gars va modifier son truc sans cesse et comme personne
n'aura le temps ou l'envie de le lui démonter, ou bien se lassera, il
répondra "ben vas-y, casse-le mon algo ! J'ai proposé de le casser
personne n'y est arrivé, donc, c'est le meilleur, incassable, blabla."

Bonjour,

je ne dis et pense pas du tout cela. Je tiens à préciser que je suis
personnellement reconnaissant à l'égard de ceux et de celles qui tentent de
m'aider soit par leur critiques constructives ou soit par le temps qu'ils
mettent à tenter de démontrer si vraiment il est préférable ou non de
modifier la façon que j'ai d'avoir intégré la clef avec les données. Je
m'applique donc à suivre le fil de vos discussions (qui sont très
intérressantes) afin d'en tirer profit. Plusieurs têtes valent souvent mieux
qu'une.

Tu sais très bien comment ça va finir.

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi j'ajoute
qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il génère
temporairement un fichier (qu'il nettoie et supprime par la suite) afin d'en
faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap (temporaire).
Faites-en le test et vous verrez.
Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant j'essais
d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation. J'ai une façon de faire et d'autre ont leur façon de faire
et j'ai mes limites intellectuelles comme d'autres ont leur leur; il y a
toujours meilleur que nous.

Et puis bon, le gars qui te dit "moi, j'arrive pas à le casser, alors...",
ben tu peux passer en mode "Lol" direct...

En réalité j'aurais pu pousser plus loin mes tentatives d'essayer de

trouver un moyen d'arriver à trouver une solution permettant la décryption
d'une clef au sein des données cryptées. Mais je dis que si j'aurais trouvé
un solution permettant à décrypter une clef faisant partie intégrante des
données cryptées alors je ne l'aurais jamais intégrée de la façon actuelle.
Ceci dit, je ne dis pas non plus qu'il est impossible de quelques façons que
ce soit que la solution pourrait être trouvée, mais si ce serait le cas
alors j'aurai appris à faire les choses différenment et je modifierais la
façon de faire dans mes codes tout en gardant la compatibilité pour la
décryption des fichiers (ou données) qui ont été auparavant cryptés avec les
versions précédentes du logiciel.
Bonne journée :)
r.h.

En crypto, le gars qui file pas ses algorithmes, il se discrédite
lui-même, tout seul.

Enfin, puisque c'est à but commercial, pourquoi des "amateurs" devraient
se soucier de son cas ? S'il veut en tirer bénéfice, ben à lui d'en
assurer une étude professionnelle, avec tout ce que ce terme sous-entend.

J'ai pas regardé, mais je suppose qu'on peut désassembler son truc facile
non ?

--
AMcD®

http://arnold.mcdonald.free.fr/

AMcD®

27/11/2004 à 01:14

J'avoue ne lire qu'en diagonale la plupart des posts de ce fil mai, une
question me tarabuste : pourquoi parles-tu de décryption et d'encryption ?
Cela ne veux rien dire en français.

--
AMcD®

http://arnold.mcdonald.free.fr/

Sylvain

27/11/2004 à 02:10

"Raymond H." a écrit

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi
j'ajoute

qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il
génère

temporairement un fichier (qu'il nettoie et supprime par la suite) afin
d'en

faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap (temporaire).
Faites-en le test et vous verrez.

ce point étant récurrent, je voudrais recadrer sur ce qui (me) parait
insatisfaisant.

tout d'abord, il n'est aucun "test de windows" à faire car "windows" ne lit
pas des vidéos, au contraire différents "players" (dont un Windows Media
Player) qui ont chacun leurs règles (codages) utilisent différents codecs
(modules transformant un flux de données en image animées) qui également ont
leurs règles (codages) propres.

si vous présentez votre logiciel comme permettant de visualiser des vidéos
chiffrées en les déchiffrant à la volée, la question n'est absolument pas de
savoir comment se comporte tel ou tel sous OCX ou sous codec, mais
uniquement de savoir si vous satisfaisez à votre proposition initiale; il
apparait que ce n'est pas le cas puisque vous créez des copies claires
temporaires et que vous ne donnez aucune garantie sur l'effacement de ces
copies (effacement électro-magnétique s'entend).

nous (re)répondre que votre "soft n'est pas un firewall" ou nous mettre au
"défit de trouver un film dans un swap système" est tout à fait hors sujet
et ne change rien à ces erreurs fonctionelles, il montre plutôt un
entêtement à ne pas réfléchir à un système cohérent, acceptable et utile
pour l'utilisateur.

un tel système devrait inclure:
- l'option de visualiser un contenu maintenu chiffré sur disque,
- l'option de déchiffrer une fois pour toute ce contenu

dans le premier cas, vous imposez à l'utilisateur un temps d'attente
(création du temp.) non justifié.
dans les deux cas, vous ne pouvez traiter un fichier que si l'espace disque
libre et au moins égal à sa taille - si l'utilisateur sature son disque il
n'a plus accès à ces documents chiffrés.

ces limitations aussi évidentes qu'inacceptables ne trouvent peut être pas
de solution dans le fait de glisser un OCX dans un container, en effet, mais
programmer ne se réalise pas toujours du bout de la souris.

Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant
j'essais

d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation.

la question suivante est alors: quelle est votre valeur/compétence ?

vous avez, à tout le moins, identifier des usages pouvant être utile aux
utilisateurs; peut être voudrez-vous proposer une plate-forme de
visualisation de contenu multimédia transmis chiffré afin de préserver la
vie privée - les échanges de photos numériques par mail peuvent mériter un
tel traitement - mais vous devrez alors admettre que vous devrez utiliser
des algos crypto. connus et fiables (et libre de droit dans beaucoup de
cas).

... à moins qu'il ne s'agisse d' "écouter du MP3" que "les autorités
policières [ne peuvent] décrypter" ... c'est heureusement aussi hors sujet
que fantaisiste donc je stoppe là.

Sylvain.

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

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi
j'ajoute

qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il
génère

temporairement un fichier (qu'il nettoie et supprime par la suite) afin
d'en

faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap (temporaire).
Faites-en le test et vous verrez.

ce point étant récurrent, je voudrais recadrer sur ce qui (me) parait
insatisfaisant.

tout d'abord, il n'est aucun "test de windows" à faire car "windows" ne lit
pas des vidéos, au contraire différents "players" (dont un Windows Media
Player) qui ont chacun leurs règles (codages) utilisent différents codecs
(modules transformant un flux de données en image animées) qui également ont
leurs règles (codages) propres.

si vous présentez votre logiciel comme permettant de visualiser des vidéos
chiffrées en les déchiffrant à la volée, la question n'est absolument pas de
savoir comment se comporte tel ou tel sous OCX ou sous codec, mais
uniquement de savoir si vous satisfaisez à votre proposition initiale; il
apparait que ce n'est pas le cas puisque vous créez des copies claires
temporaires et que vous ne donnez aucune garantie sur l'effacement de ces
copies (effacement électro-magnétique s'entend).

nous (re)répondre que votre "soft n'est pas un firewall" ou nous mettre au
"défit de trouver un film dans un swap système" est tout à fait hors sujet
et ne change rien à ces erreurs fonctionelles, il montre plutôt un
entêtement à ne pas réfléchir à un système cohérent, acceptable et utile
pour l'utilisateur.

un tel système devrait inclure:
- l'option de visualiser un contenu maintenu chiffré sur disque,
- l'option de déchiffrer une fois pour toute ce contenu

dans le premier cas, vous imposez à l'utilisateur un temps d'attente
(création du temp.) non justifié.
dans les deux cas, vous ne pouvez traiter un fichier que si l'espace disque
libre et au moins égal à sa taille - si l'utilisateur sature son disque il
n'a plus accès à ces documents chiffrés.

ces limitations aussi évidentes qu'inacceptables ne trouvent peut être pas
de solution dans le fait de glisser un OCX dans un container, en effet, mais
programmer ne se réalise pas toujours du bout de la souris.

Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant
j'essais

d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation.

la question suivante est alors: quelle est votre valeur/compétence ?

vous avez, à tout le moins, identifier des usages pouvant être utile aux
utilisateurs; peut être voudrez-vous proposer une plate-forme de
visualisation de contenu multimédia transmis chiffré afin de préserver la
vie privée - les échanges de photos numériques par mail peuvent mériter un
tel traitement - mais vous devrez alors admettre que vous devrez utiliser
des algos crypto. connus et fiables (et libre de droit dans beaucoup de
cas).

... à moins qu'il ne s'agisse d' "écouter du MP3" que "les autorités
policières [ne peuvent] décrypter" ... c'est heureusement aussi hors sujet
que fantaisiste donc je stoppe là.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

"Raymond H." a écrit

Déjà, quand tu vois ses raisonnements sur les fichiers temporaires dans
Windows... Si tu penses que c'est pas un grand cryptographe, moi
j'ajoute

qu'il est limité en prog Windows.

Concernant les fichiers temporaires que Windows génère, je dis que
lorsque c'est une vidéo d'une grande taille qu'AllCrypter décrypte il
génère

temporairement un fichier (qu'il nettoie et supprime par la suite) afin
d'en

faire la lecture à partir de ce fichier et que Windows n'envoie pas
l'ensemble de ces données (cette vidéo) dans un fichier swap (temporaire).
Faites-en le test et vous verrez.

ce point étant récurrent, je voudrais recadrer sur ce qui (me) parait
insatisfaisant.

tout d'abord, il n'est aucun "test de windows" à faire car "windows" ne lit
pas des vidéos, au contraire différents "players" (dont un Windows Media
Player) qui ont chacun leurs règles (codages) utilisent différents codecs
(modules transformant un flux de données en image animées) qui également ont
leurs règles (codages) propres.

si vous présentez votre logiciel comme permettant de visualiser des vidéos
chiffrées en les déchiffrant à la volée, la question n'est absolument pas de
savoir comment se comporte tel ou tel sous OCX ou sous codec, mais
uniquement de savoir si vous satisfaisez à votre proposition initiale; il
apparait que ce n'est pas le cas puisque vous créez des copies claires
temporaires et que vous ne donnez aucune garantie sur l'effacement de ces
copies (effacement électro-magnétique s'entend).

nous (re)répondre que votre "soft n'est pas un firewall" ou nous mettre au
"défit de trouver un film dans un swap système" est tout à fait hors sujet
et ne change rien à ces erreurs fonctionelles, il montre plutôt un
entêtement à ne pas réfléchir à un système cohérent, acceptable et utile
pour l'utilisateur.

un tel système devrait inclure:
- l'option de visualiser un contenu maintenu chiffré sur disque,
- l'option de déchiffrer une fois pour toute ce contenu

dans le premier cas, vous imposez à l'utilisateur un temps d'attente
(création du temp.) non justifié.
dans les deux cas, vous ne pouvez traiter un fichier que si l'espace disque
libre et au moins égal à sa taille - si l'utilisateur sature son disque il
n'a plus accès à ces documents chiffrés.

ces limitations aussi évidentes qu'inacceptables ne trouvent peut être pas
de solution dans le fait de glisser un OCX dans un container, en effet, mais
programmer ne se réalise pas toujours du bout de la souris.

Aussi, je ne prétend pas être un grand cryptographe. Il y a des gens
dont la connaissance en la matière est très élevée et en les lisant
j'essais

d'en tirer leçon. Je dois donc peser les pour et les contres. Ainsi en
est-il en programmation, je ne prétend pas être un super AS de la
programmation.

la question suivante est alors: quelle est votre valeur/compétence ?

vous avez, à tout le moins, identifier des usages pouvant être utile aux
utilisateurs; peut être voudrez-vous proposer une plate-forme de
visualisation de contenu multimédia transmis chiffré afin de préserver la
vie privée - les échanges de photos numériques par mail peuvent mériter un
tel traitement - mais vous devrez alors admettre que vous devrez utiliser
des algos crypto. connus et fiables (et libre de droit dans beaucoup de
cas).

... à moins qu'il ne s'agisse d' "écouter du MP3" que "les autorités
policières [ne peuvent] décrypter" ... c'est heureusement aussi hors sujet
que fantaisiste donc je stoppe là.

Sylvain.

Raymond H.

27/11/2004 à 02:51

"AMcD®" a écrit dans le message de news:
41a7c6f8$0$21261$

J'avoue ne lire qu'en diagonale la plupart des posts de ce fil mai, une
question me tarabuste : pourquoi parles-tu de décryption et d'encryption ?
Cela ne veux rien dire en français.

Bonjour,

Vous avez raison si vous dites qu'on ne les retrouve pas dans le
dictionnaire en français, du moins dans mon dictionnaire 'Le Petit Robert'.
Je les utilise car souvent 'en' est le contraire de 'dé', et donc plus
facile à comprendre à la 1re écoute pour les simples mortels.
J'utilise aussi ces mots car ils sont très largement employés par la
population Internaute.
Si je dis 'décryptage' alors quel est son antonyme? Cryptage n'est pas
dans mon dictionnaire. Faudrait que je reformule pour employer
'Cryptographie'. Pourtant 'graphie'...#!?#
Mais je pourrais employer 'Crypter' et 'Décrypter'. Mais le contraire
de 'décryptage' ou 'décryptement' est quoi (dans le dictionnaire)? À mon
avis ces mots sonnent comme du barbarisme à mes oreilles.
Qu'en pensez-vous?
Cordialement
r.h.

--
AMcD®

http://arnold.mcdonald.free.fr/

AllCrypter : utilisation gratuite jusqu'en 2006

10 réponses

Veuillez sélectionner un problème