Alarme sans fil gérée par µC.

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From French to

Threaded View
Bonjour ,

Maintenant que je commence E0% maitriser E0% peu pres les B5%C je souhaite
mettre en place un projet d'alarme silencieuse dE9%portE9%e.

je m'explique.

Si un mE9%chant monsieur entre dans ma proprietE9% , notre cher voisin
retraitE9% et ancien gendarme (attention ca rigole pas ! ) aura un
voyant qui clignotera dans son salon.

J'ai donc pour cela ; 2 cartes TX/RX , 869 Mhz 25 mW , 2 B5% controleur
(1 cotE9% maison / 1 cotE9% voisin).

J'envoie donc des trames sE9%rie par le biais de la liaison sans fil en
RS 232.

J'ai fait des essais cela fonctionne , je peux meme me payer le luxe
d'avoir un LCD de l'autre cotE9% qui indique le type d'intrusion
(garage / salon etc...).

Ma question ne concerne pas le principe de programmation de facon
gE9%nE9%ral , mais de savoir comment sE9%curiser la liaison RS 232 sans fil=
.

En effet sans entrer dans de la parano je ne voudrais pas qu'on puisse
prendre le controle du systeme et capter la trame radio ou du moins si
on la capte ne pas pouvoir l'utiliser pour activer / desactiver le
systeme.

J'ai prE9%vu dans mon mot de 8 bits d'inclure le numE9%ro de sE9%rie de
chaque emetteur / recepteur afin qu'ils communiquent de facon "
securisE9%e " c'est E0% dire que les serial number sont verifiE9%s E0% chaq=
ue
rE9%ception d'un message pour valider un ordre.

Par contre je me suis renseignE9% et on ma dit que ce systeme de
protegeait pas la liaison que c'etait du bidon et qu'il fallait
utiliser un code tournant afin que chaque trame envoyE9%e soit unique.
J'ai vu qu'il existait le systeme Keyloq parcontre cest un peu trop
compliquE9% pour moi.

N'y aurait il pas une facon de sE9%curiser la liaison avec une commande
dans le B5%C E0% utiliser ou une formule mathE9%mathique ?

Merci E0% vous :)

Re: Alarme sans fil gérée par µC.
Emile a ecrit

Quoted text here. Click to load it

Bonjour Emile
Le verbe *securiser* avec "sans fil" ça ne marchera jamais ;o)
(un emetteur en continu sur la F et la liaison supposée securisée est
"morte"  sans avoir meme besoin de tenter de percer.

tendre a fiabiliser = oui

Puisque tu veux faire du "neuf"
la solution là la plus simple est d'encoder/crypter les trames avant
envoi.
A chaud :
envoi d'une trame cryptée watchdog aleatoirement (au moins une par
periode de temps à definir pour verif de l'integrité de la liaison)
envoi des evenements reels par trames cryptées.

voire à faire aussi de la pseudo evasion de frequence si les modules le
permettent et/ou dupliquer les vecteurs d'emission pour augmenter le
facteur "fiabilité".

Rvl



Re: Alarme sans fil gérée par µC.
On Mar 3, 3:48 pm, Emile

Quoted text here. Click to load it

Voici une technique simple E0% mettre en oeuvre,
mais suffisamment robuste aux attaques primaires :

Pour chaque trame E0% E9%mettre, l'E9%metteur gE9%nE8%re
 un octet de codage pseudo-alE9%atoire, et effectue
 avec lui un XOR sur chaque octet de la trame,
 puis ajoute ce code en fin de trame.
Le rE9%cepteur rE9%cupE8%re l'octet de codage
 et dE9%code la traF9%me avec le mEA%me algotithme.

Ainsi les trames changent continuellement, mEA%me
si les donnE9%es transmises sont toujours les mEA%mes.

Pour amE9%liorer cela, au lieu d'utiliser une valeur d'encodage
sur un seul octet il vaut mieux avoir le plus de bits possible,
et mEA%me, modifier ces bits E0% chaque XOR sur un octet de trame,
par exemple avec des dE9%calages, etc ...

De cette facon, mEA%me une trame composE9%e uniquement
de zE9%ros prE9%sentera une suite de bits changeants qui
ressemblera plus E0% du bruit qu'E0% quelque chose de sensE9%.

Il faut aussi que les trames ne soient pas trop courtes,
sinon cela simplifie l'analyse de l'encodage.
(si tes trames sont trop courtes, ajoute des octets bidons)

Tu peux t'inspirer d'algos dE9%ja existants du genre CRC :
http://en.wikipedia.org/wiki/Cyclic_redundancy_check

Exemples de programmes C pour calcul de CRC :
http://www.cl.cam.ac.uk/research/srg/bluebook/21/crc/node6.html#SECTION0006 =
0000000000000000

Re: Alarme sans fil gérée par µC.

Quoted text here. Click to load it

il faudra prevoir surtout un anti brouillage ...
si le recepteur ne recoit rien pendant  x minutes, brouillage en cours
à vérifier ?

--
-
Jean-Yves


Re: Alarme sans fil gérée par µC.
jeanyves a tapoté du bout de ses petites papattes :
Quoted text here. Click to load it

Le watchdog de rvlegran est une bonne idée pour ça.

--
LeLapin



Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it

Merci beaucoup E0% tous !

je pensais sachant que chaque boitier gere l'emission et la rE9%ception.
Envoyer par l'emetteur 1 recevoir par le 2 , le 2 lit et confirme E0%
l'emetteur qui rE9%envoit ( le tout se fait X fois ), au bout de X fois
le NB0%2 valide et E9%xecute l'ordre.(le tout avec le CRC prE9%conisE9% par
JC).
De toute maniere l'appareil emet seulement lorsque il y a une
intrusion ; en mode veille personne ne communique sauf toutes les 2 H
par exemple pour s'assurer que la liaison est encore lE0% et qu'il n'y a
pas de brouillage , si message antibrouillage pas recu au bout de X
fois , dE9%clenchement sirE8%ne chez le voisin par exemple.

J'ai aussi la possibilitE9% en commande AT de gE9%rer plusieurs canaux
d'E9%mission sur la meme frE9%quence , donc pk pas emettre sur canal 1
ensuite 2 ensuite 3 etc...?

Emile


Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it

Pour le code alE9%atoire je peux le gE9%rer avec le pic fonction " random"
pour le gE9%nE9%rer , mais se pose la question de comment aprE8%s dE9%codag=
e
de l'autre cotE9% savoir quoi executer , sachant que cest de l'alE9%atoire
le recepteur ne pourra donc pas anticiper cette valeur .?

Emile

Re: Re: Alarme sans fil gérée par µC.
Emile a ecrit

Quoted text here. Click to load it

Il existe une multitude de solution, mais je crois que dans ton cas il
te faut rester simple.

pour exemple solution simple et efficace
tu genere un nombre pseuso aleatoire sur la source
tu crypte ton msg avec un algo dont la clef est fonction du nombre
generé.
tu transmet avec la trame cryptée le nombre aleatoire generé et tu
decrypte à l'arrivée en appliquant la fonction inverse.

autre solution
si tu a une reference temporelle fiable de chaque coté, tu peux aussi
utiliser le timestamp comme generateur aleatoire.

De toutes façons, ne reve pas trop, si des "rigolos" en sont à essayer
de decortiquer ça "ON AIR", il y a de grandes chances qu'ils
choisissent une methode un peu plus brut ! :D

Au passage 2 heures entre cghque verif d'integrité de liaison, c'est
AMHA quasi equivalent à pas de protection !
+/- une trame watchdog par minute est plus realiste.
Rvl



Re: Re: Alarme sans fil gérée par µC.
rvlegran a tapoté du bout de ses petites papattes :
Quoted text here. Click to load it

+1
D'autant que comme les deux µC n'auront que ça à foutre, ça ne coûte
rien. Accessoirement, dans le militaire ou le civil sensible, on
rajoutait des watchdogs hardware pour prévenir le risque de plantage du
proc. Mais n'ayant pas d'expérience suffisante avec les PICs, je ne
sais pas s'il est plantard ou pas.

--
LeLapin



Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it

Je peux faire un truc du genre :

Si je veux envoyer la valeur 150 par exemple qui correspondrait de
l'autre cotE9% au dE9%clenchement de l'alarme par exemple ca serait du
style :

GE9%nE9%ration d'un nombre alE9%atoire d'un octet par exemple 196 ce qui
fait en binaire :11000100

150 X 196 3D% 29400
Je convertis ce rE9%sultat en binaire et je viens lui coller ma clef
alE9%atoire de 196 ce qui ferait :  111001011011000 et 11000100

Soit un mot de presque 3 octets soit 23 bits
Donc j'envoie 11100101101100011000100 par le biais de ma liaison sans
fil.

et cotE9% recepteur je fais cela dans l'autre sens c'est ca ?

Emile

Re: Alarme sans fil gérée par µC.
On Mar 3, 10:49 pm, Emile

Quoted text here. Click to load it

Je ne comprends pas pourquoi tu multiplies 150 par 196 ?
Outre le fait que cela augmente la taille des donnE9%es E0% transmettre,
il est bien plus simple et rapide de faire un XOR entre
la clE9% de codage et chaque octet de donnE9%es de la trame.

Avec ton exemple : si tu veux envoyer un seul
octet de valeur 150 avec une cle E9%gale E0% 196,
alors ta trame non cryptE9%e vaudra 3D% 0x96C4
tu cryptes en faisant un XOR entre 0x96 et 0xC4
cela donne la trame cryptE9%e E0% transmettre 3D% 0x52C4
En rE9%ception tu fais la mEA%me chose
et tu retrouves 3D% 0x96C4 ...

Mais j'ai dE9%ja attirE9% ton attention
sur le fait que plus une trame est courte,
plus il est facile de casser son cryptage :
ta bande passante est assez E9%levE9%e pour que tes
trames puissent faire au moins une centaine d'octets.

D'autre part il serait bon que le rE9%cepteur soit protE9%gE9%
contre les erreurs de transmissions, sinon c'est n'importe quoi.
Un checksum (ou mieux, un CRC qui permet de corriger certaines
erreurs) ne coFB%te pas grand-chose en programmation ni en temps ...

Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it

J'ai pas eu de plantages dans mes designs. Ils peuvent redemarrer en cas de
grosse EMI conduite (et donc c'est non bloquant bien que le programme reparte
du début), mais il y a aussi un watchdog disponible avec un oscillateur
séparé, avec un diviseur réglable selon le temps voulu entre le dernier appel
a restart_wdt() et le reset du µC.

--
cLx

Re: Alarme sans fil gérée par µC.
On Mar 3, 6:57 pm, Emile

Quoted text here. Click to load it

Il est E9%vident que ce code ( la clE9% d'encodage/dE9%codage )
doit EA%tre transmis DANS la trame : il doit en faire partie.
Tu peux par exemple ajouter cette clE9% en fin de trame,
ou en dE9%but de trame ( ce qui permet de dE9%coder les octets
suivants en temps rE9%E9l, au fur et E0% mesure de leur arrivE9%e )

Je prE9%cise qu'une clE9% composE9%e d'un seul octet ne
me semble pas suffisant pour une protection efficace :
par la force brute il n'y a que 255 possibilitE9%s
E0% essayer pour retrouver l'original ... c'est peu.

D'oF9% l'intE9%rEA%t de modifier la clE9% au fur et E0% mesure
qu'on la XOR avec chaque octet de la trame E0% transmettre :
c'est aussi simple E0% faire qu'efficace pour la protE9%ger.
D'ailleurs le XOR pur n'est qu'un rE9%flexe d'informaticien :
il peut aussi EA%tre mE9%langE9% avec des ROR et des ROL,
les bits d'une mEA%me trame peuvent EA%tres swappE9%s, etc.
( tout ceci E9%tant bien sFB%r rE9%versible pour permettre
le dE9%codage de la trame lors de la rE9%ception )

Tu peux mEA%me aller jusqu'E0% distribuer individuellement
chaque bit de la clE9% n'importe oF9% dans la trame.
Il existe une infinitE9% de possibilitE9%s pour encrypter
un message de faE7%on efficaE7%e, sans que cela ne
devienne compliquE9% E0% programmer en ASM ou en C.
La thE9%orie peut faire appel E0% des maths poussE9%es,
mais leur programmation se rE9%soud E0% quelques lignes.


Exemple de codage simple, rE9%versible avec clE9% changeante :

// ptr 3D% pointeur sur les donnE9%es
// size 3D% taille des donnE9%es en octets
// key 3D% cle de cryptage (16 bits, 32 bits, ...)

void Crypt( char *ptr, unsigned int size, unsigned int key )
{
int i, j, s 3D% sizeof(int); // util

// ajoute la cle en fin de trame
 for( i3D%j3D%0;  i < s;  j++, i +3D% 8 )
   ptr[ size + j ]  3D%  ( key >> i ) & 0xFF; // LSB first

// encode les donnE9%es
  for( s--; size--; )
  {
    *ptr++ ^3D% key & 0xFF; // codage de l'octet trame
    key 3D% ( key << 1 ) ^ ( (key >> s ) & 1 ); // cle suivante
  }
}



Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it
codage

bon dE9%jE0% transmettre une clE9% dans un message, c'est stupide...

(je viens de voir de nouveaux messages et la cryptanalyse semble
trop facile encore pour ce qui a E9%tE9% proposE9%)

ensuite, ce dont il est question ici c'est juste de l'embrouillage,
si une personne est suffisamment compE9%tente pour E9%coder et lire
le message, elle le comprendra...

pour le reste, il y a le bouquin de Bruce Schneier :
"cryptographie appliquE9%e"

et mEA%me des groupes sur usenet pour E7%a :
fr.misc.cryptologie sci.crypt sci.crypt.research
et j'en passe

enfin, j'ai entendu dire (je sais plus oF9%) que le systE8%me Keelok
de Microchip ne vaut pas grand-chose, le fait d'avoir cachE9%
le code source ne rend dE9%cidE9%ment pas le systE8%me plus fiable.

yg
--20%
http://ygdes.com / http://yasep.org

Re: Alarme sans fil gérée par µC.
On Mar 3, 11:11 pm, whygee

Quoted text here. Click to load it

Moins stupide que de croire qu'en
ayant la trame, on a aussi la clE9% :

Tu ne connais pas la taille de la clE9% (qui peut EA%tre variable)
Tu ne sais pas oF9% trouver la clE9% dans la trame.
Tu ne sais pas si la clE9% n'est pas elle-mEA%me cryptE9%e.
Tu ne connais pas l'algorithme d'encryptage.
... etc ...

Quoted text here. Click to load it

Non, parce-que ce qui va coincer ce n'est pas la
connaissance, mais l'explosion de la combinatoire.

Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it

si tu lis 1 trame.

admettons maintenant que Eve (Alice E9%tant Emile et Bob
E9%tant le voisin gendarme, cf
http://fr.wikipedia.org/wiki/Alice_et_Bob )
E9%coute patiemment les trames 1 jour, ou 2 semaines.
combien peut-elle en stocker pour examiner les corrE9%lations ?
Eve verra bien que des parties du messages ne changent
pas et sont donc nE9%cessaires au protocole.

si la clE9% ne change pas ET est transmise dans le message,
elle n'a plus de fonction de clE9%. D'oF9% les fonctions
de hachage et d'encryption dont les propriE9%tE9%s de
  confusion-diffusion sont suffisamment solides.


Quoted text here. Click to load it

non

la "connaissance" vient juste de l'entropie du message
transmis.

la premiE8%re E9%tape de la cryptanalyse c'est de voir
les corrE9%lations entre messages, trouver ce qui change,
pourquoi/quand.


Ma proposition :
  * Une clE9% "privE9%e" sur N bits. Une clE9% (identifiant) par appareil=
2E%
      comme E7%a, pas possible d'en prendre un pour E9%muler un autre.
  * Un compteur, ou mEA%me LFSR, qui incrE9%mente E0% chaque message.
  * La clE9% et le compteur sont mE9%langE9%s par un SHA-1 ce qui donne 1=
60 bits.
     E7%a utilise de l'arithmE9%tique 32 bits mais juste additions/soustr=
actions/
    dE9%calage/and/or/xor/not donc on peut coder E0% coups de macros ASM.=

     3D%> Je sais, SHA-1 n'est plus sFB%r et y'a des rainbow tables dispo=
nibles
    mais on peut l'altE9%rer : changer le nombre de rondes (pas besoin de=
 80,
    40 suffiraient) et on peut changer les "constantes magiques" (parties=
 de la clE9%).

  * Concernant la dE9%tection/correction d'erreurs :
   les codes de Hamming sont trE8%s bien :-)
   c'est encore que des XOR, E7%a a l'air complexe
   mais quand on a compris c'est super simple en fait.

  * mettre en place un systE8%me d'accusE9% de rE9%ception pour que les c=
ompteurs
     avancent en synchronicitE9%.

pas besoin de changement de frE9%quence :-)

yg
--20%
http://ygdes.com / http://yasep.org

Re: Alarme sans fil gérée par µC.
On Mar 4, 12:06 am, whygee

Quoted text here. Click to load it

| Moins stupide que de croire qu'en ayant la trame, on a aussi la
clE9% :
| Tu ne connais pas la taille de la clE9% (qui peut EA%tre variable)
| Tu ne sais pas oF9% trouver la clE9% dans la trame.
| Tu ne sais pas si la clE9% n'est pas elle-mEA%me cryptE9%e.
| Tu ne connais pas l'algorithme d'encryptage ... etc ...

Quoted text here. Click to load it

Cela reste valable pour plsieurs trames
puisque la clE9% change E0% chaque trame E9%mise,
et mEA%me E0% chaque octet d'une trame donnE9%e :
alors autant pour l'analyse ... mais admettons.

Quoted text here. Click to load it

Je doute que le cambrioleur y passe autant de temps,
surtout avec une trame E9%mise toutes les deux plombes,
comme Emile veut le faire ... mais admettons.

Quoted text here. Click to load it

Si tu ne connais pas l'algo de cryptage et que
tu ne peux pas localiser la clE9%, les corrE9%lations
te permettront-elles de *dE9%coder* le message ?

Quoted text here. Click to load it

Toutes les 'parties du message' changent E0% chaque E9%mission,
mEA%me si c'est exactement la mEA%me trame qui est E9%mise.
Je doute que le cambrioleur de base ait la puissance
de calcul nE9%cE9%ssaire, et surtout les connaissances
pour maitriser de telles analyses ... mais admettons.

Quoted text here. Click to load it

La clE9% change E0% CHAQUE E9%mission de trame,
et mEA%me pour chaque octet de chaque trame.

Quoted text here. Click to load it

Oui, elle l'est.

Quoted text here. Click to load it

Je ne tiens pas E0% jouer sur la terminologie :
pour moi, la clE9% d'un message donnE9%
est ce qui permet de dE9%crypter ce message-lE0%.
Que cette clE9% soit changE9%e me semble EA%tre la moindre
des sE9%curitE9%s, et ne lui fait pas perdre sa qualitE9% de "clE9%".

Et je rE9%pE8%te que le fait que la clE9%
soit incluse dans le message n'implique
pas que tu sois capable de l'en extraire :
tu ne sais pas oF9% sont les bits de cette clE9%,
ni dans quel ordre ils sont, ni combien il y en a, etc.

Quoted text here. Click to load it

| Non, parce-que ce qui va coincer ce n'est pas la
| connaissance, mais l'explosion de la combinatoire.

Quoted text here. Click to load it

J'entends bien, mais en thE9%orie de l'information on choisit
un message parmi un ensemble fini de messages possibles :
rien n'empE8%che d'ajouter E0% chaque trame un nombre diffE9%rent
et arbitraire de bits alE9%atoires. La longueur des trames
changeant E0% chaque E9%mission, je vois mal comment tu pourrais
dimensionner l'ensemble des possibilitE9%s ... mais admettons.

Quoted text here. Click to load it

Pour un cabrioleur de base ?
Je ne vois pas vraiment oF9% se situe l'objection.
Mais bon, c'est trE9%s intE9%ressant comme sujet ...

Quoted text here. Click to load it

Quelle que soit l'efficacitE9% redoutable de ces techniques,
je trouve justement dommmage d'utiliser des techniques connues :
rien de mieux que le non-standard pour EA%tre rE9%fractaire E0% l'analyse !
Et pas besoin de trucs lourds ...

Quoted text here. Click to load it

Et pourtant, si le cambioleur ne recoit plus rien
sur son rE9%cepteur, c'est mal barrE9% pour lui.

Mais est-ce qu'Emile va dE9%velopper et implE9%menter
un petit SHA, du Hamming, des codes en treillis
et tout le toutim, tout cela en Basic sur un Pic ?
Il peut le faire en copiant/collant du code par-ci par-lE0%,
mais s'il ne maitrise pas en profondeur le fonctionnement
de son propre programme, que vaudra la fiabilitE9% de son alarme ?


Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it

Oui je veux rester sur un systE8%me simple mais efficace , ce n'est pas
la NASA qu'on protE8%ge et pour bien connaitre le patron de l'APSAD
celui-ci m'a bien expliquE9% les techniques des cambrioleurs pour les
particuliers.

un coup de marteau , un coup de scie circulaire , un tournevis , une
bombe de mousse poluyrethane pour etouffer les sirenes et c'est tout.
tout ce qui est brouillage tout ca , c'est dans les films , ca existe
mais c'est tres rare , meme pour des banques , les mecs travaillent
soit par corruption d'un vigile soit E0% lance thermique ...! Dans tout
ce qui est hacking informatique lE0% c'est totalement diffE9%rent , mais
mon systE8%me sera reliE9% au secteur , et autonome en cas de panne de
courant pendant 72H , une carte SIM en plus pour sortir au cas ou .

Emile

Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it

Moi ce que je veux eviter c'est un parasite exterieur ayant une Z.I E0%
cotE9% de mon domicile avec des ponts roulants en HF ... !

Re: Alarme sans fil gérée par µC.
dE9%solE9% pour la longueur du message :-)

Quoted text here. Click to load it
plusieurs ?
comme combien ?

Quoted text here. Click to load it
donc ce n'est pas une clE9%.

Quoted text here. Click to load it
alors cela n'a rien E0% voir.
c'est plus ou moins de l'embrouillage,
mais pas de l'encryption.

on pourrait dire que ta "clE9%" est une sorte de vecteur
de diffusion, comme dans RC4 ou un algo similaire.
tu n'abordes pas la crE9%ation de ta "clE9%",
qui ressemble E0% un "sel" dE9%terministe
(ce qui fait confusion des genres)

Quoted text here. Click to load it
il se rend compte probablement que pour que ce soit fiable,
il faut des messages beaucoup plus souvent, comme 5s d'E9%cart...
sinon comment dE9%tecter un brouillage ?

Quoted text here. Click to load it
la crypto, et l'Histoire, montrent qu'on n'a pas forcE9%ment
besoin de dE9%coder un message pour faire des dE9%gE2%ts :-)

Quoted text here. Click to load it
alors justement, c'est assez facile E0% dE9%terminer :
tu fais un XOR bit par bit entre diffE9%rents messages,
tu verras que le rE9%sultat sera souvent le mEA%me (corrE9%lation).
sachant que le contenu du message ne change pas,
justement, tu peux retrouver la "clE9%" et remonter au processus
qui la gE9%nE8%re.

Quoted text here. Click to load it
on ne sait jamais. Emile ne nous dit pas si l'E9%ventuel
cambrioleur bosse pour la D$T ;-P

Quoted text here. Click to load it
donc ce n'est pas une clE9%.

Quoted text here. Click to load it
donc c'est encore moins une clE9% :-D

Quoted text here. Click to load it
je n'y tiens pas non plus, mais tu vois que si on
utilise un mot pour dire chacun une chose,
on s'y retrouve plus. alors accordons-nous
sur ce qu'est une clE9% et on y arriver :-)

Quoted text here. Click to load it
ah ! jusque lE0% E7%a va.
or si tu envoies la clE9% tu permets E0% Eve de dE9%crypter.
on est d'accord ?

Quoted text here. Click to load it

fail.

par dE9%finition, une clE9% est quelque chose qui ne change pas durant la=
 transmission.
ce qui E9%vite de s'empEA%trer avec la synchronisation des clE9%s de chaq=
ue cF4%tE9%.

par contre des algos comme RC4 sont des gE9%nE9%rateurs de bits pseudo-al=
E9%atoires
qui dE9%pendent d'une clE9% privE9%e. mais c'est un peu lourd pour de pet=
its messages
et il faut trop de RAM (256 octets au moins).

Quoted text here. Click to load it

si, justement.

l'information y est, ou n'y est pas.
si elle n'y est pas, ne on peut pas la trouver.
si elle y est, ben on *peut* la retrouver,
mEA%me si c'est "difficile" (priE8%re de quantifier
la difficultE9%)

Quoted text here. Click to load it
laisse-moi deviner : Emile va imaginer un systE8%me
de permutation hyper complexe qui va tomber au premier
xor entre 2 messages consE9%cutifs....

Quoted text here. Click to load it
Et Emile est bien incapable de choisir et coder cela...

Tu rends le procE9%dE9% plus complexe et pE9%nible mais pas plus inviolab=
le.

 > La longueur des trames
Quoted text here. Click to load it
mais pourquoi changer tout le temps ?
E7%a complique le code sans rien apporter.

Quoted text here. Click to load it
y'a mEA%me des newsgroups dessus, et plein de bouquins,
on parle mEA%me de confE9%rences internationales et
j'ai entendu dire que c'est utilisE9% partout ;-P

Quoted text here. Click to load it
nb: pour ceux qui savent pas ce que c'est un LFSR, voici un article trE8%
s dE9%taillE9%
http://www.unixgarden.com/index.php/comprendre/comprendre-les-generateurs =
-de-nombres-pseudo-aleatoires

Quoted text here. Click to load it

Justement je propose de modifier SHA1 (qui est pas trE8%s compliquE9%,
y'a du code source en clair partout pour E7%a, voir en fin de message
ma sauce dE9%rivE9%e de wikipedia)

l'avantage de passer les donnE9%es dans la fonction de hachage
est que E7%a garantit (modulo un hash bidouillE9%, non standard,
pour E9%viter les rainbow tables) qu'il est impossible de remonter
aux donnE9%es initiales qu'on veut transmettre.

et contrairement E0% un "block cypher" comme DES, qui ne fonctionne que s=
ur
64 bits E0% la fois, ce qui est un peu... pauvre, SHA1 gE9%nE8%re 160 bit=
s
et a un code source beaucoup plus court et simple.
c'est assez rE9%pE9%titif mais court E0% E9%crire.

Quoted text here. Click to load it
et quand mEA%me, s'il reE7%oit qqchose, E7%a change quoi ?

Quoted text here. Click to load it
j'ai pas parlE9% de treillis ;-)

et le code SHA1 est copiE9%-collE9%-modifiE9% de Wikipedia ci dessous,
ya qu'E0% traduire dans le langage choisi.
quant E0% Hamming, y'a qu'E0% lire la page wikipedia :-)
http://en.wikipedia.org/wiki/Hamming_code#General_algorithm
je me suis mEA%me permis de faire du pseudo-code pour
l'encodeur (identique au dE9%codeur, le correcteur
est un peu plus long) aprE8%s celui de SHA1.

Quoted text here. Click to load it
Ici, la fonction de hachage fournit la sE9%curitE9%,
et Hamming la fiabilitE9%. Et E7%a lui fera dE9%couvrir au passage
des aspects indispensables du monde de la programmation,
de la thE9%orie de l'information et des protocoles de communication,
avec le language qu'il choisit.



attention : le code suivant n'est pas compilable,
donc n'a pas E9%tE9% testE9%, et ne peux donc pas EA%tre garanti ;-)


**************************************************************

pseudo-code dE9%rivE9% de http://en.wikipedia.org/wiki/SHA-1

choisir les constantes:
h0 3D% 0x67452301 \
h1 3D% 0xEFCDAB89  \
h2 3D% 0x98BADCFE   > E0% changer :-)
h3 3D% 0x10325476  /
h4 3D% 0xC3D2E1F0 /

initialiser le tampon "w" de 16 mots (0 E0% 15) de 32 bits
  * mot 0 : compteur E0% incrE9%menter E0% chaque message
     (ou un LFSR en configuration de Galois, c'est mieux)
  * mots 1 E0% 15 : la "clE9%", identifiant unique de l'appareil

extension du tampon "w" E0% 80 mots (indices de 0 E0% 79) :

for i from 16 to 79
    w[i] 3D% (w[i-3] xor w[i-8] xor w[i-14] xor w[i-16]) leftrotate 1

    (note : on peut s'arranger pour n'avoir que 16 mots E0% la fois en RA=
M)

initialise les variables de calcul :
a 3D% h0
b 3D% h1
c 3D% h2
d 3D% h3
e 3D% h4

for i from 0 to 79
        if  i < 20 then
          f 3D% (b and c) or ((not b) and d)
          k 3D% 0x5A827999
   else if i < 40
          f 3D% b xor c xor d
          k 3D% 0x6ED9EBA1
   else if i < 60
          f 3D% (b and c) or (b and d) or (c and d)
          k 3D% 0x8F1BBCDC
   else
          f 3D% b xor c xor d
          k 3D% 0xCA62C1D6

         temp 3D% (a leftrotate 5) + f + e + k + w[i]
         e 3D% d
         d 3D% c
         c 3D% b leftrotate 30
         b 3D% a
         a 3D% temp

end for

h0 3D% h0 + a
h1 3D% h1 + b
h2 3D% h2 + c
h3 3D% h3 + d
h4 3D% h4 + e

envoyer les 5 mots h0 h1 h2 h3 h4 (soit 20 octets)

**************************************************************

Code de Hamming avec paritE9% :

20 octets en entrE9%e dans le tableau w (voir ci-dessus)
(attention, les indices partent de 0 mais Hamming commence E0% 1)
on crE9%e les 6 variables A, B, C, D, E, et P
(A E0% E sont les syndromes, P est la paritE9% totale)

A3D%B3D%C3D%D3D%E3D%P3D%0

pour i de 1 E0% 20
   j3D%w[i-1] (cf: dE9%calage mentionnE9% plus haut)
   si (bit 0 de i) 3D% '1' alors A 3D% A xor j
   si (bit 1 de i) 3D% '1' alors B 3D% B xor j
   si (bit 2 de i) 3D% '1' alors C 3D% C xor j
   si (bit 3 de i) 3D% '1' alors D 3D% D xor j
   si (bit 4 de i) 3D% '1' alors E 3D% E xor j
   P 3D% P xor j
fin boucle

A l'E9%mission : Envoyer w[0..19] puis A, B, C, D, E, et P
(26 octets en tout)
Note : pour s'assurer de la synchronisation,
on peut mettre un octet "0xA5" en entEA%te et un octet "0x5A"
E0% la fin

A la rE9%ception :
  rejeter tout ce qui ne se conforme pas E0% "0xA5" ... "0x5A".
  calculer les A, B, C, D, E, et P
(avec le code ci-dessus) puis faire un XOR avec les ABCDEP reE7%us.
Ensuite calculer Z 3D% A or B or C or D or E or P
  Si Z3D%0 alors pas d'erreur de transmission
     donc comparer le message reE7%u avec ceux prE9%calculE9%s
        puis envoyer un accusE9% de rE9%ception.

  sinon : compter le nombre de bit E0% 1 pour voir si
  un ou deux bits sont corrigibles. au dessus de 3,
  le message est faux ou brouillE9%.

E7%a a l'air magique comme E7%a mais c'est juste des maths appliquE9%es :=
-)
--20%
http://ygdes.com / http://yasep.org

Site Timeline