Je dois (professionnellement) implémenter l'algo de cryptage DES
(options: ECB, No Padding), avec le langage C.
J'ai lu plusieurs documentations (celle du NIST - officielle, plusieurs
'tuto' plus ou moins fiables trouvés sur internet, et le bouquin de
Bruce Schneier ' cryptographie appliquée').
On m'a fourni un programme en Java (utilisant les bibliothèques Java),
pour pouvoir comparer mon implémentation par rapport à une
implémentation fiable.
Et évidemment, je n'ai jamais le même résultat que le programme Java.
Ma question est donc la suivante:
Y-a-t'il quelqu'un ici que souhaite passer un peu de temps avec moi,
pour que j'explique mon algorithme ?
J'en suis à ma quatrième ou cinquième implémentation, et je fais
toujours choux blanc.
Cette personne pourrait me rendre un grand service en détectant l'une ou
l'autre erreur que j'aurais pu commettre ...
Je dois (professionnellement) implémenter l'algo de cryptage DES (options: ECB, No Padding), avec le langage C.
J'ai lu plusieurs documentations (celle du NIST - officielle, plusieurs 'tuto' plus ou moins fiables trouvés sur internet, et le bouquin de Bruce Schneier ' cryptographie appliquée').
On m'a fourni un programme en Java (utilisant les bibliothèques Java), pour pouvoir comparer mon implémentation par rapport à une implémentation fiable.
Et évidemment, je n'ai jamais le même résultat que le programme Java.
Il y a quelques années, j'ai vu un livre qui, sur un exemple, donnait le résultat du chiffrement après chacune des itérations. Si vous arrivez à mettre la main dessus, cela devrait vous aider à localiser vos erreurs.
-- Languages of the World: http://www.ethnologue.com/web.asp
alt3 <user@domain.invalid> :
Bonjour à tous,
Je dois (professionnellement) implémenter l'algo de cryptage DES
(options: ECB, No Padding), avec le langage C.
J'ai lu plusieurs documentations (celle du NIST - officielle,
plusieurs 'tuto' plus ou moins fiables trouvés sur internet, et le
bouquin de Bruce Schneier ' cryptographie appliquée').
On m'a fourni un programme en Java (utilisant les bibliothèques
Java), pour pouvoir comparer mon implémentation par rapport à une
implémentation fiable.
Et évidemment, je n'ai jamais le même résultat que le programme Java.
Il y a quelques années, j'ai vu un livre qui, sur un exemple, donnait
le résultat du chiffrement après chacune des itérations. Si vous
arrivez à mettre la main dessus, cela devrait vous aider à localiser
vos erreurs.
--
Languages of the World: http://www.ethnologue.com/web.asp
Je dois (professionnellement) implémenter l'algo de cryptage DES (options: ECB, No Padding), avec le langage C.
J'ai lu plusieurs documentations (celle du NIST - officielle, plusieurs 'tuto' plus ou moins fiables trouvés sur internet, et le bouquin de Bruce Schneier ' cryptographie appliquée').
On m'a fourni un programme en Java (utilisant les bibliothèques Java), pour pouvoir comparer mon implémentation par rapport à une implémentation fiable.
Et évidemment, je n'ai jamais le même résultat que le programme Java.
Il y a quelques années, j'ai vu un livre qui, sur un exemple, donnait le résultat du chiffrement après chacune des itérations. Si vous arrivez à mettre la main dessus, cela devrait vous aider à localiser vos erreurs.
-- Languages of the World: http://www.ethnologue.com/web.asp
Je dois (professionnellement) implémenter l'algo de cryptage DES (options: ECB, No Padding), avec le langage C.
(ECB + No Padding, c'est assez louche. Il y a très peu de protocoles raisonnables qui utilisent un tel mode de chiffrement. Tout ceci ressemble plus à un devoir scolaire qu'à un besoin professionnel...)
Le plus simple moyen d'implémenter quelque chose est de ne pas le faire, mais plutôt de récupérer un code existant. En cherchant sur google "DES public domain implementation", on trouve déjà quelques liens. Par exemple ceci : http://www.funet.fi/pub/crypt/cryptography/symmetric/des/csu10des.zip
C'est du vieux C (pre-ANSI) mais c'est censé fonctionner. Il existe beaucoup d'implémentations plus modernes avec des licences plus ou moins libres.
Si une réelle réimplémentation est vraiment nécessaire (par exemple si c'est vraiment un devoir scolaire), une implémentation existante est toujours valable : on peut la truffer de divers printf() pour obtenir les valeurs intermédiaires, et voir à quel endroit on diverge.
--Thomas Pornin
According to alt3 <user@domain.invalid>:
Je dois (professionnellement) implémenter l'algo de cryptage DES
(options: ECB, No Padding), avec le langage C.
(ECB + No Padding, c'est assez louche. Il y a très peu de protocoles
raisonnables qui utilisent un tel mode de chiffrement. Tout ceci
ressemble plus à un devoir scolaire qu'à un besoin professionnel...)
Le plus simple moyen d'implémenter quelque chose est de ne pas le
faire, mais plutôt de récupérer un code existant. En cherchant sur
google "DES public domain implementation", on trouve déjà quelques
liens. Par exemple ceci :
http://www.funet.fi/pub/crypt/cryptography/symmetric/des/csu10des.zip
C'est du vieux C (pre-ANSI) mais c'est censé fonctionner. Il existe
beaucoup d'implémentations plus modernes avec des licences plus ou
moins libres.
Si une réelle réimplémentation est vraiment nécessaire (par exemple si
c'est vraiment un devoir scolaire), une implémentation existante est
toujours valable : on peut la truffer de divers printf() pour obtenir
les valeurs intermédiaires, et voir à quel endroit on diverge.
Je dois (professionnellement) implémenter l'algo de cryptage DES (options: ECB, No Padding), avec le langage C.
(ECB + No Padding, c'est assez louche. Il y a très peu de protocoles raisonnables qui utilisent un tel mode de chiffrement. Tout ceci ressemble plus à un devoir scolaire qu'à un besoin professionnel...)
Le plus simple moyen d'implémenter quelque chose est de ne pas le faire, mais plutôt de récupérer un code existant. En cherchant sur google "DES public domain implementation", on trouve déjà quelques liens. Par exemple ceci : http://www.funet.fi/pub/crypt/cryptography/symmetric/des/csu10des.zip
C'est du vieux C (pre-ANSI) mais c'est censé fonctionner. Il existe beaucoup d'implémentations plus modernes avec des licences plus ou moins libres.
Si une réelle réimplémentation est vraiment nécessaire (par exemple si c'est vraiment un devoir scolaire), une implémentation existante est toujours valable : on peut la truffer de divers printf() pour obtenir les valeurs intermédiaires, et voir à quel endroit on diverge.
--Thomas Pornin
alt3
Thomas Pornin wrote:
(ECB + No Padding, c'est assez louche. et pourquoi donc ?
Il y a très peu de protocoles raisonnables qui utilisent un tel mode de chiffrement. Tout ceci ressemble plus à un devoir scolaire qu'à un besoin professionnel...) Et pourtant...
Je fais avec les informations qu'on me donne, la crypto c'est pas du tout mon truc à la base.
Le plus simple moyen d'implémenter quelque chose est de ne pas le faire, mais plutôt de récupérer un code existant. En cherchant sur google "DES public domain implementation", on trouve déjà quelques liens. Par exemple ceci : http://www.funet.fi/pub/crypt/cryptography/symmetric/des/csu10des.zip Je regarde celui-ci, merci de l'adresse.
Ceci dit, j'en ai déjà trouvé plusieurs, mais aucun de me donne le résultat que j'attend.
Si une réelle réimplémentation est vraiment nécessaire (par exemple si c'est vraiment un devoir scolaire), une implémentation existante est toujours valable : on peut la truffer de divers printf() pour obtenir les valeurs intermédiaires, et voir à quel endroit on diverge. La méthode reste valable, effectivement.
--Thomas Pornin Merci de ta réponse.
Thomas Pornin wrote:
(ECB + No Padding, c'est assez louche.
et pourquoi donc ?
Il y a très peu de protocoles
raisonnables qui utilisent un tel mode de chiffrement. Tout ceci
ressemble plus à un devoir scolaire qu'à un besoin professionnel...)
Et pourtant...
Je fais avec les informations qu'on me donne, la crypto c'est pas du
tout mon truc à la base.
Le plus simple moyen d'implémenter quelque chose est de ne pas le
faire, mais plutôt de récupérer un code existant. En cherchant sur
google "DES public domain implementation", on trouve déjà quelques
liens. Par exemple ceci :
http://www.funet.fi/pub/crypt/cryptography/symmetric/des/csu10des.zip
Je regarde celui-ci, merci de l'adresse.
Ceci dit, j'en ai déjà trouvé plusieurs, mais aucun de me donne le
résultat que j'attend.
Si une réelle réimplémentation est vraiment nécessaire (par exemple si
c'est vraiment un devoir scolaire), une implémentation existante est
toujours valable : on peut la truffer de divers printf() pour obtenir
les valeurs intermédiaires, et voir à quel endroit on diverge.
La méthode reste valable, effectivement.
(ECB + No Padding, c'est assez louche. et pourquoi donc ?
Il y a très peu de protocoles raisonnables qui utilisent un tel mode de chiffrement. Tout ceci ressemble plus à un devoir scolaire qu'à un besoin professionnel...) Et pourtant...
Je fais avec les informations qu'on me donne, la crypto c'est pas du tout mon truc à la base.
Le plus simple moyen d'implémenter quelque chose est de ne pas le faire, mais plutôt de récupérer un code existant. En cherchant sur google "DES public domain implementation", on trouve déjà quelques liens. Par exemple ceci : http://www.funet.fi/pub/crypt/cryptography/symmetric/des/csu10des.zip Je regarde celui-ci, merci de l'adresse.
Ceci dit, j'en ai déjà trouvé plusieurs, mais aucun de me donne le résultat que j'attend.
Si une réelle réimplémentation est vraiment nécessaire (par exemple si c'est vraiment un devoir scolaire), une implémentation existante est toujours valable : on peut la truffer de divers printf() pour obtenir les valeurs intermédiaires, et voir à quel endroit on diverge. La méthode reste valable, effectivement.
--Thomas Pornin Merci de ta réponse.
pornin
According to alt3 :
Thomas Pornin wrote:
(ECB + No Padding, c'est assez louche. et pourquoi donc ?
1. Parce que ça suppose que les données à chiffrer ont déjà la bonne taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de montrer directement si deux blocs de 8 octets de texte clair étaient identique avant chiffrement (car ils le seront encore après).
De fait, tous les protocoles sérieux utilisant du chiffrement symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent des modes de chiffrement plus avancés (souvent CBC, parfois d'autres choses telles que du CTR) et prévoient le padding (sachant qu'il n'est pas si facile que ça de faire un padding correct sans introduire de problèmes de sécurité).
Sans compter que DES tout seul, ça fait 56 bits de clé effective (bien que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une solidité à toute épreuve. On lui préfère souvent 3DES (prononcez : "Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche à la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un problème si la sécurité résultante est bancale).
--Thomas Pornin
According to alt3 <user@domain.invalid>:
Thomas Pornin wrote:
(ECB + No Padding, c'est assez louche.
et pourquoi donc ?
1. Parce que ça suppose que les données à chiffrer ont déjà la bonne
taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de
montrer directement si deux blocs de 8 octets de texte clair étaient
identique avant chiffrement (car ils le seront encore après).
De fait, tous les protocoles sérieux utilisant du chiffrement
symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent
des modes de chiffrement plus avancés (souvent CBC, parfois d'autres
choses telles que du CTR) et prévoient le padding (sachant qu'il n'est
pas si facile que ça de faire un padding correct sans introduire de
problèmes de sécurité).
Sans compter que DES tout seul, ça fait 56 bits de clé effective (bien
que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une
solidité à toute épreuve. On lui préfère souvent 3DES (prononcez :
"Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter
est un protocole louche à la sécurité douteuse, soit c'est un exercice
purement scolaire (auquel cas ce n'est pas un problème si la sécurité
résultante est bancale).
(ECB + No Padding, c'est assez louche. et pourquoi donc ?
1. Parce que ça suppose que les données à chiffrer ont déjà la bonne taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de montrer directement si deux blocs de 8 octets de texte clair étaient identique avant chiffrement (car ils le seront encore après).
De fait, tous les protocoles sérieux utilisant du chiffrement symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent des modes de chiffrement plus avancés (souvent CBC, parfois d'autres choses telles que du CTR) et prévoient le padding (sachant qu'il n'est pas si facile que ça de faire un padding correct sans introduire de problèmes de sécurité).
Sans compter que DES tout seul, ça fait 56 bits de clé effective (bien que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une solidité à toute épreuve. On lui préfère souvent 3DES (prononcez : "Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche à la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un problème si la sécurité résultante est bancale).
--Thomas Pornin
Erwan David
(Thomas Pornin) écrivait :
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche à la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un problème si la sécurité résultante est bancale).
DES en ECB,NoPAdding c'est juste la brique de base qui permet de construire tout le reste.
-- Real programs don't eat cache
pornin@nerim.net (Thomas Pornin) écrivait :
De cela, je déduis que soit le protocole que vous devez implémenter
est un protocole louche à la sécurité douteuse, soit c'est un exercice
purement scolaire (auquel cas ce n'est pas un problème si la sécurité
résultante est bancale).
DES en ECB,NoPAdding c'est juste la brique de base qui permet de
construire tout le reste.
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche à la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un problème si la sécurité résultante est bancale).
DES en ECB,NoPAdding c'est juste la brique de base qui permet de construire tout le reste.
-- Real programs don't eat cache
alt3
Thomas Pornin wrote:
1. Parce que ça suppose que les données à chiffrer ont déjà la bonne taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de montrer directement si deux blocs de 8 octets de texte clair étaient identique avant chiffrement (car ils le seront encore après).
De fait, tous les protocoles sérieux utilisant du chiffrement symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent des modes de chiffrement plus avancés (souvent CBC, parfois d'autres choses telles que du CTR) et prévoient le padding (sachant qu'il n'est pas si facile que ça de faire un padding correct sans introduire de problèmes de sécurité).
Sans compter que DES tout seul, ça fait 56 bits de clé effective (bien que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une solidité à toute épreuve. On lui préfère souvent 3DES (prononcez : "Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche à la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un problème si la sécurité résultante est bancale).
Pour info, il s'agit de transmission de petites mots (je n'ai pas la longueur exacte, mais elle semble être fixe), par modem RTC.
De plus, l'architecture matériel que j'utilise n'est pas compatible avec la plupart des librairies précompilées, et encore moins avec un quelconques OS (pas de win* y compris CE, pas de Linux, ...)
Enfin, je développe un client, et c'est le partenaire de mon entreprise qui développe le côté serveur, et m'a imposé ce cryptage, avec de telles options.
Vous comprendrez que ce n'est pas un choix.
Cela dit, je prends vos remarques au sérieux, dans le cas d'une critique du système mis en place côté serveur.
Thomas Pornin wrote:
1. Parce que ça suppose que les données à chiffrer ont déjà la bonne
taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de
montrer directement si deux blocs de 8 octets de texte clair étaient
identique avant chiffrement (car ils le seront encore après).
De fait, tous les protocoles sérieux utilisant du chiffrement
symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent
des modes de chiffrement plus avancés (souvent CBC, parfois d'autres
choses telles que du CTR) et prévoient le padding (sachant qu'il n'est
pas si facile que ça de faire un padding correct sans introduire de
problèmes de sécurité).
Sans compter que DES tout seul, ça fait 56 bits de clé effective (bien
que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une
solidité à toute épreuve. On lui préfère souvent 3DES (prononcez :
"Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter
est un protocole louche à la sécurité douteuse, soit c'est un exercice
purement scolaire (auquel cas ce n'est pas un problème si la sécurité
résultante est bancale).
Pour info, il s'agit de transmission de petites mots (je n'ai pas la
longueur exacte, mais elle semble être fixe), par modem RTC.
De plus, l'architecture matériel que j'utilise n'est pas compatible avec
la plupart des librairies précompilées, et encore moins avec un
quelconques OS (pas de win* y compris CE, pas de Linux, ...)
Enfin, je développe un client, et c'est le partenaire de mon entreprise
qui développe le côté serveur, et m'a imposé ce cryptage, avec de telles
options.
Vous comprendrez que ce n'est pas un choix.
Cela dit, je prends vos remarques au sérieux, dans le cas d'une critique
du système mis en place côté serveur.
1. Parce que ça suppose que les données à chiffrer ont déjà la bonne taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de montrer directement si deux blocs de 8 octets de texte clair étaient identique avant chiffrement (car ils le seront encore après).
De fait, tous les protocoles sérieux utilisant du chiffrement symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent des modes de chiffrement plus avancés (souvent CBC, parfois d'autres choses telles que du CTR) et prévoient le padding (sachant qu'il n'est pas si facile que ça de faire un padding correct sans introduire de problèmes de sécurité).
Sans compter que DES tout seul, ça fait 56 bits de clé effective (bien que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une solidité à toute épreuve. On lui préfère souvent 3DES (prononcez : "Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche à la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un problème si la sécurité résultante est bancale).
Pour info, il s'agit de transmission de petites mots (je n'ai pas la longueur exacte, mais elle semble être fixe), par modem RTC.
De plus, l'architecture matériel que j'utilise n'est pas compatible avec la plupart des librairies précompilées, et encore moins avec un quelconques OS (pas de win* y compris CE, pas de Linux, ...)
Enfin, je développe un client, et c'est le partenaire de mon entreprise qui développe le côté serveur, et m'a imposé ce cryptage, avec de telles options.
Vous comprendrez que ce n'est pas un choix.
Cela dit, je prends vos remarques au sérieux, dans le cas d'une critique du système mis en place côté serveur.
Sylvain Croussette
alt3 wrote:
Apokrif wrote: ...
Il y a quelques années, j'ai vu un livre qui, sur un exemple, donnait le résultat du chiffrement après chacune des itérations. Si vous arrivez à mettre la main dessus, cela devrait vous aider à localiser vos erreurs.
Merci de la piste.
Cordialement, alt3.
Ceci donne plusieurs exemples détaillés par itération: http://www.geocities.com/scroussette/desecb.txt Le code en C correspondant est http://www.geocities.com/scroussette/des.c Il comprend aussi le 3-DES.
alt3 <user@notregistred.com> wrote:
Apokrif <apokrif1@yahoo.com> wrote:
...
Il y a quelques années, j'ai vu un livre qui, sur un exemple, donnait
le résultat du chiffrement après chacune des itérations. Si vous
arrivez à mettre la main dessus, cela devrait vous aider à localiser
vos erreurs.
Merci de la piste.
Cordialement, alt3.
Ceci donne plusieurs exemples détaillés par itération:
http://www.geocities.com/scroussette/desecb.txt
Le code en C correspondant est
http://www.geocities.com/scroussette/des.c
Il comprend aussi le 3-DES.
Il y a quelques années, j'ai vu un livre qui, sur un exemple, donnait le résultat du chiffrement après chacune des itérations. Si vous arrivez à mettre la main dessus, cela devrait vous aider à localiser vos erreurs.
Merci de la piste.
Cordialement, alt3.
Ceci donne plusieurs exemples détaillés par itération: http://www.geocities.com/scroussette/desecb.txt Le code en C correspondant est http://www.geocities.com/scroussette/des.c Il comprend aussi le 3-DES.
pburnand0-news
Thomas Pornin wrote:
1. Parce que ?a suppose que les données ? chiffrer ont déj? la bonne taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de montrer directement si deux blocs de 8 octets de texte clair étaient identique avant chiffrement (car ils le seront encore apr?s).
De fait, tous les protocoles sérieux utilisant du chiffrement symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent des modes de chiffrement plus avancés (souvent CBC, parfois d'autres choses telles que du CTR) et prévoient le padding (sachant qu'il n'est pas si facile que ?a de faire un padding correct sans introduire de probl?mes de sécurité).
Sans compter que DES tout seul, ?a fait 56 bits de clé effective (bien que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une solidité ? toute épreuve. On lui préf?re souvent 3DES (prononcez : "Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche ? la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un probl?me si la sécurité résultante est bancale).
Pour info, il s'agit de transmission de petites mots (je n'ai pas la longueur exacte, mais elle semble ?tre fixe), par modem RTC.
De plus, l'architecture matériel que j'utilise n'est pas compatible avec la plupart des librairies précompilées, et encore moins avec un quelconques OS (pas de win* y compris CE, pas de Linux, ...)
Enfin, je développe un client, et c'est le partenaire de mon entreprise qui développe le c?té serveur, et m'a imposé ce cryptage, avec de telles options.
Vous comprendrez que ce n'est pas un choix.
Cela dit, je prends vos remarques au sérieux, dans le cas d'une critique du syst?me mis en place c?té serveur.
Il existe 1000 et une implémentations de DES en C et d'autres languages. Tout le problèmes est alors de traduire ceci en Java, si le code Java n'existe pas déjà...
Il suffit de savoir chercher avec google. DES Java crypto
Maintenand, reste à instancier les classes avec les bons paramètres pour sélectionner les options, etc...
Thomas Pornin wrote:
1. Parce que ?a suppose que les données ? chiffrer ont déj? la bonne
taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de
montrer directement si deux blocs de 8 octets de texte clair étaient
identique avant chiffrement (car ils le seront encore apr?s).
De fait, tous les protocoles sérieux utilisant du chiffrement
symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent
des modes de chiffrement plus avancés (souvent CBC, parfois d'autres
choses telles que du CTR) et prévoient le padding (sachant qu'il n'est
pas si facile que ?a de faire un padding correct sans introduire de
probl?mes de sécurité).
Sans compter que DES tout seul, ?a fait 56 bits de clé effective (bien
que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une
solidité ? toute épreuve. On lui préf?re souvent 3DES (prononcez :
"Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter
est un protocole louche ? la sécurité douteuse, soit c'est un exercice
purement scolaire (auquel cas ce n'est pas un probl?me si la sécurité
résultante est bancale).
Pour info, il s'agit de transmission de petites mots (je n'ai pas la
longueur exacte, mais elle semble ?tre fixe), par modem RTC.
De plus, l'architecture matériel que j'utilise n'est pas compatible avec
la plupart des librairies précompilées, et encore moins avec un
quelconques OS (pas de win* y compris CE, pas de Linux, ...)
Enfin, je développe un client, et c'est le partenaire de mon entreprise
qui développe le c?té serveur, et m'a imposé ce cryptage, avec de telles
options.
Vous comprendrez que ce n'est pas un choix.
Cela dit, je prends vos remarques au sérieux, dans le cas d'une critique
du syst?me mis en place c?té serveur.
Il existe 1000 et une implémentations de DES en C et d'autres languages.
Tout le problèmes est alors de traduire ceci en Java, si le code Java
n'existe pas déjà...
Il suffit de savoir chercher avec google.
DES Java crypto
1. Parce que ?a suppose que les données ? chiffrer ont déj? la bonne taille (multiple de 8 octets dans le cas de DES).
2. Parce que le mode ECB a ses propres faiblesses, comme notamment de montrer directement si deux blocs de 8 octets de texte clair étaient identique avant chiffrement (car ils le seront encore apr?s).
De fait, tous les protocoles sérieux utilisant du chiffrement symétriques (genre S/MIME, SSL, OpenPGP, OpenSSH, IPsec...) utilisent des modes de chiffrement plus avancés (souvent CBC, parfois d'autres choses telles que du CTR) et prévoient le padding (sachant qu'il n'est pas si facile que ?a de faire un padding correct sans introduire de probl?mes de sécurité).
Sans compter que DES tout seul, ?a fait 56 bits de clé effective (bien que la clé comporte stricto sensu 64 bits), ce qui n'est pas d'une solidité ? toute épreuve. On lui préf?re souvent 3DES (prononcez : "Triple DES").
De cela, je déduis que soit le protocole que vous devez implémenter est un protocole louche ? la sécurité douteuse, soit c'est un exercice purement scolaire (auquel cas ce n'est pas un probl?me si la sécurité résultante est bancale).
Pour info, il s'agit de transmission de petites mots (je n'ai pas la longueur exacte, mais elle semble ?tre fixe), par modem RTC.
De plus, l'architecture matériel que j'utilise n'est pas compatible avec la plupart des librairies précompilées, et encore moins avec un quelconques OS (pas de win* y compris CE, pas de Linux, ...)
Enfin, je développe un client, et c'est le partenaire de mon entreprise qui développe le c?té serveur, et m'a imposé ce cryptage, avec de telles options.
Vous comprendrez que ce n'est pas un choix.
Cela dit, je prends vos remarques au sérieux, dans le cas d'une critique du syst?me mis en place c?té serveur.
Il existe 1000 et une implémentations de DES en C et d'autres languages. Tout le problèmes est alors de traduire ceci en Java, si le code Java n'existe pas déjà...
Il suffit de savoir chercher avec google. DES Java crypto
