Alarme sans fil gérée par µC. - Page 2

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

Translate This Thread From French to

Threaded View
Re: Alarme sans fil gérée par µC.
On Mar 4, 3:08 am, whygee

Quoted text here. Click to load it

LE0%, je crois qu'on est partis ...

| si tu lis 1 trame.
Quoted text here. Click to load it

C'est E0% toi de me le dire, puisque c'est toi qui
soutiens de pouvoir remonter au message original.
( sans savoir en extraire la clE9% ni connaitre l'algo utilisE9% )

Quoted text here. Click to load it

Si tu veux ... alors appelons cela une 'E9%lc',
cela ne change rien E0% l'efficacitE9% finale.

Quoted text here. Click to load it
 > alors cela n'a rien E0% voir.
Quoted text here. Click to load it

D'accord, admettons.
Justement, s'il s'agissait d'une technique standard,
on pourrait lui appliquer des mE9%thodes standard.
Or, ma proposition est justement de procE9%der autrement
pour satisfaire au but visE9% : empE9%cher la reconstitution
des donnE9%es d'origine en partant des donnE9%es 'embrouillE9%es'.

Quoted text here. Click to load it

Je ne remets pas en cause ce que tu dis sur les techniques
standard, par contre je remets en cause ton rE9%flexe
de vouloir TOUT ramener E0% ces techniques.

Dans ce contexte, tes objections ne sont valables que
pour l'ensemble des mE9%thodes (plus ou moins) bien E9%prouvE9%es
dont tu supposes E0% priori l'efficacitE9% sur une mE9%thode
qui justement n'utilise PAS ces mE9%thodes-lE0%.
Tu ne connais pas l'algo d'embrouillage utilisE9%,
ni mEA%me la profondeur de complexitE9% E0% laquelle il opE8%re,
et tu prE9%tends casser ce code avec des mE9%thodes
faites pour d'autres types d'obfuscations.

Quoted text here. Click to load it

Oui, tout E0% fait.

| 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

Je veux bien, mais tu n'as pas rE9%pondu E0% ma question.

| Toutes les 'parties du message' changent E0% chaque E9%mission,
| mEA%me si c'est exactement la mEA%me trame qui est E9%mise.
Quoted text here. Click to load it

Ce n'est vrai que s'il existe une bijection unique
entre les poids respectifs de chaque bit du message
d'origine et de chaque bit du message brouillE9% :
or ce n'est pas le cas ici puisqu'on insE9%re des bits
alE9%atoires E0% des endroits arbitraires dans la trame
et qu'en plus on swappe les bits significatifs de la trame :
tu auras beau XORer bit E0% bit diffE9%rentes trames brouillE9%es
( dont la longueur varie et dont les bits changent de position )
tu verras que le rE9%sultat NE sera PAS souvent le mEA%me.

| Je doute que le cambrioleur de base ait la puissance
| de calcul nE9%cE9%ssaire, et surtout les connaissances
| pour maitriser de telles analyses
 > on ne sait jamais. Emile ne nous dit pas si
Quoted text here. Click to load it

Dans ce cas il se fout que le voisin se pointe,
E0% fortiori si ce voisin est un gendarme ...

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

Si tu veux. Appelons-la une 'E9%lc'.

Quoted text here. Click to load it

Oui, si tu veux. Cela ne change rien au rE9%sultat :
l'embrouillage effectuE9% est rE9%sistant aux attaques que tu as proposE9%.

| pour moi, la clE9% d'un message donnE9%
| est ce qui permet de dE9%crypter ce message-lE0%.

Quoted text here. Click to load it

Non, pour des raisons que j'ai dE9%ja E9%voquE9% plusieurs fois :

1. La 'E9%lc' est diffE9%rente pour chaque message.
2. La 'E9%lc' est modifiE9%e E0% chaque fois qu'on
   s'en sert pour XORer un octet du message.
3. Les bits de la clE9% sont dispersE9%s dans le corps des bits du
message.
4. On ajoute au message des bits alE9%atoires E0% des endroits
arbitraires.
5. On peut mEA%me envoyer de temps en temps des messages totalement
bidons
  (qui ne codent pas pour une commande incluse dans le protocole de
com)
  pour bruiter les calculs issus d'une collecte d'interceptions,
etc ...

Ergo, j'attends toujours que tu me dises comment tu comptes retrouver
la 'E9%lc' E0% partir d'une analyse statistique des messages interceptE9%s.

MEA%me si je te donnais la clE9%, elle ne te servirait pas E0% grand-chose
puisque tu ne connais pas l'algo utilisE9% pour le brouillage,
d'autant plus qu'il ne s'agit pas d'un algo standard.
Et il n'est pas dit qu'on utilise un seul algo, le mEA%me E0% chaque
fois :
certains bits de la 'E9%lc' peuvent servir E0% indiquer quel algo
utiliser.

| 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%".
Quoted text here. Click to load it

Et alors ?  Je mets en place un brouillage, je fais ce que je veux.
Si tu refuses d'appeler cela une 'clE9%', ok, appelons-la une 'E9%lc',
cela ne me gE8%ne pas. Toujours est-il que le rE9%sultat
est de rendre le message plus rE9%sistant aux attaques
que si la clE9% restait toujours la mEA%me E0% chaque encodage.

C'est comme si tu me disais que je n'ai pas le droit d'utiliser
une technique non-standard et inconnue : j'en ai d'autant plus
le droit que c'est justement ce qui va compliquer les attaques.

Quoted text here. Click to load it

Et par suite, ce qui rend le message moins rE9%sistant aux attaques.
( et je n'ai pas parlE9% de synchronisation de clE9%s )

Tu critiques ma proposition sur les bases d'une technique diffE9%rente :
tous les animaux ne sont pas des E9%lE9%phants, mais tu persistes E0%
analyser
un nouvel animal (par exemple un oursin) toujours en termes
d'E9%lE9%phants
parce-que c'est ce que tu connais dE9%ja. C'est comprE9%hensible,
mais tu te trompes (sic) parce-que cela n'a aucune chanE7%e d'aboutir.

Tu as le droit de refuser d'envisager une technique d'embrouillage
dont la clE9% change continuellement, ou qu'on swappe arbitrairement
tous les bits d'un bloc de donnE9%es, etc ...
Mais cela n'empE8%che personne de s'y prendre comme E7%a,
et que toute attaque se basant sur l'idE9%e que le brouillage
utilisE9% est connu, sera par dE9%finition vouE9%e E0% l'E9%chec.

| 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

Quoted text here. Click to load it

Je pense plutF4%t que c'est E0% toi de prouver ce que tu avances.
Comment fais-tu pour retrouver chaque bit d'une 'E9%lc'
dont tu ne connais ni le nombre de bits, ni leur ordre,
ni leur position dans tous les bits d'un message ?

Quoted text here. Click to load it

Rien de complexe : la mise en oeuvre est
bien plus simple que ne l'est sa description.

Quoted text here. Click to load it

Imagine ce que tu veux, mais ne te contentes pas d'affirmer :
considE9%rant le brouillage proposE9%,
donne la preuve formelle que tu seras
capable de remonter au message original.

Quoted text here. Click to load it

Notre conversation porte sur des considE9%rations qui vont
au-delE0% de ce qu'Emile veut rE9%aliser, il l'a dit lui-mEA%me.

Quoted text here. Click to load it

Oui.


Si c'est + complexe c'est forcE9%ment + inviolable,
ne serait-ce que par l'E9%norme quantitE9% de permutations
possibles sur tous les bits d'une trame de longueur suffisante.
( d'autant plus que cela ne correspond E0% aucun standard )

| La longueur des trames changeant E0% chaque E9%mission, je vois
| mal comment tu pourrais dimensionner l'ensemble des possibilitE9%s
Quoted text here. Click to load it

Pour compliquer les attaques, E9%videmment !
Si la mEA%me 'E9%lc' est utilisE9%e pour tous les messages, que tous
ses bits restent groupE9%s au mEA%me endroit des messages, etc,
alors certains types d'attaques fonctionneront;
mais si la 'E9%lc' change pour chaque message et qu'elle y est
dispersE9%e, enfouie, ces mEA%mes attaques ne fonctionneront plus.
Et c'est bien le but.

Quoted text here. Click to load it

Non, le code n'est pas si compliquE9%,
et mEA%me moins lourd que certains trucs standards,
en termes de code source et de taille RAM.

Quoted text here. Click to load it

Si : cela diminue fortement les approches d'attaques possibles.
Depuis le dE9%but de nos E9%changes tu tentes de rE9%duire ma
proposition E0% une sorte d'encodage plus ou moins standard :
c'est exactement le contraire de ce que je propose;
pour cette raison tes objections ne tiennent pas.

Quoted text here. Click to load it

Mais c'est justement parce-que c'est
connu qu'il faut procE9%der autrement.
Ce n'est pas une obligation, mais c'est une possibilitE9%,
et je ne vois pas ce qui empE8%cherait de l'envisager.

Quoted text here. Click to load it

C'est justement E0% cela que je pensais pour gE9%nE9%rer
la 'E9%lc' : si tu en croises PLUSIEURS, chacun ayant
un polynF4%me gE9%nE9%rateur qui soit diffE9%rent des autres,
et que tu XOR ensemble leurs sorties bit, tu obtiens
une sE9%quence astronomiquement longue et de trE9%s bonne
qualitE9% pour embrouiller un message. Et cela ne nE9%cE9%ssite
aucune table et ne prend que quelques lignes de code.
Ils sont bien, ces corps de Galois ...

Quoted text here. Click to load it

Alors comment fait le rE9%cepteur ami pour la reconstituer ? ;o)

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.
Quoted text here. Click to load it

Cela change qu'il aura au moins quelque chose E0% se mettre
sous la dent, plutF4%t que rien du tout - d'autant plus
qu'il est censE9% EA%tre un expert en cryptographie avancE9%e.
Si la frE9%quence de la porteuse HF saute d'une bande E0% une autre,
il faudra au cambrioleur un matE9%riel bien plus sophistiquE9%
qu'un simple rE9%cepteur, rien que pour se constituer
une collection "suffisante" de messages interceptE9%s.

Quoted text here. Click to load it

Certes, mais je rE9%pE8%te : quelle est la fiabilitE9%
d'un programme lorsqu'il est copiE9%/collE9%/bricolE9%
par une personne qui avoue s'y connaitre peu ?

Quoted text here. Click to load it

Oui, c'est un bon exercice ...
Il lui reste ensuite E0% E9%prouver son alarme, en trouvant un ami
qui veuille bien jouer le rF4%le du cambrioleur expert en crypto
avec tout son matos : ordinateur, scanner radio, etc ...
Mais c'est un bon exercice.

Quoted text here. Click to load it

Trop facile !

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

... loin de FSE et surtout du "probleme" d'Emile  :oÞ

avant de deboucher sur de la "grosse" techno durcie :

Il faut serier l'importance des facteurs negatifs sur le bilan de
restitution :

1- le vecteur transmission envisagé est de par sa nature considéré non
fiable, il peut simplement etre periodiquement etre déjà +/- evalué
mais pas certifié.

2- les datas transmises et pour autant qu'elles atteignent déjà le
recepteur seront toujours susceptibles d'etre
interceptées,analysées/decodées/desembrouiller, etc.

3- envisager un "codage/embrouillage/cryptage, etc" de data là et
quelle que soit la robustesse supposée et/ou intrinseque de telle ou
telle methode (déjà publiquement evaluée ou "proprietaire" ) ne suffira
pas a evacuer là le 1er point ;o)


Le seul et reel but ici au sujet puisque Emile est le concepteur de son
projet est simplement de progresser et c'est déjà en soit un bon but !

Qu'il passe finalement ses data en clair ou derivée d'une methode X ou
Y ne changera finalement pas grand chose .



Là le 1er niveau de securisation des data (pas de fiabilisation)
viendra simplement d'Emile puisqu'il sera le seul (sauf à le
documenter) à connaitre ce a quoi il aura finalement abouti. ;o)

Apres il faut simplemnt voir si qq'un voudra (but ? ) mettre en oeuvre
des moyens sinon lourds, au moins déjà pas à la portée du 1er rat de
cave venu) pour "contrecarrer/contourner" ce qu'aura fat Emile, et si
c'est le cas alors Emile n'aurait meme pas eu à devoir se poser la
question de realiser ainsi son projet ! :D

RvL



Re: Alarme sans fil gérée par µC.
On Mar 4, 2:32 pm, "rvlegran"

| LE0%, je crois qu'on est partis ...
Quoted text here. Click to load it

Exact, mais une fois qu'on est lancE9%s ...

Quoted text here. Click to load it

Oui.


Si les donnE9%es sont E9%mises en clair, sans protection
particuliE8%re, et que j'intercepte une trame qui signifie

 "tout va bien, ne dE9%clenche pas l'alarme, relance le watchdog"

et que je la rE9%E9mets telle quelle pE9%riodiquement,
son rE9%cepteur d'alarme va rester collE9% en position "relax"
pendant que je vide sa cave E0% vin ?

Re: Re: Alarme sans fil gérée par µC.
Jean-Christophe a ecrit
Quoted text here. Click to load it
Ce sont toujours des discussions interessantes :oÞ

Quoted text here. Click to load it

Alors ce ne sera pas par hasard de "petit voleur", mais c'est que tu
avais initialement determiné la cible (et son pourquoi à etre ciblée)
et déjà engagé des moyens d'attaque/contournement qui ne sont pas à la
portée du 1er rat de cave venu ! ;o)

Rvl



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

Voici la doc sommaire de mes fameuses cartes. C'est pas du caca en
thE9%orie. J'ai achetE9% une paire de cartes comme cela.

http://www.atim.com/IMG/pdf/ARM-U8.pdf

Emile

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

on les trouve oF9% ?

Quoted text here. Click to load it
yg
--20%
http://ygdes.com / http://yasep.org

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

Chez eux ! Atim !
Mais j'ai trouvE9% du moins cher chez Ercogener , par contre service
commercial dE9%plorable il en savent moins que moins c'est dire ... !
lol

Emile

Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it
ah chouette ils sont au salon RTS E0% la fin du mois,
je pourrai donc leur rendre visite (E0% eux aussi,
et 3 jours de salon c'est E0% peine suffisant pour
dE9%vorer des yeux tout ce qu'ils proposent)

Quoted text here. Click to load it
yg
--20%
http://ygdes.com / http://yasep.org

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

Pour le tarif il faut compter chez Atim environ 80 euros HT piE8%ce pour
une carte bidirectionelle en 25 mW.
Chez erco pour 50/60 euros on a la meme chose en 500 mW :)

J'ai fait des tests de portE9%e et ca crache bien ! meme avec des arbres
un peu partout :)

Emile

Re: Alarme sans fil gérée par µC.
Bonjour les trolls ! :-)

Quoted text here. Click to load it
ah ben quand on tient un bon sujet, on le lE2%che pas :-)

Quoted text here. Click to load it
par le principe simple que si la donnE9%e y est,
on peut l'extraire (je dis pas comment)

Quoted text here. Click to load it
qui est "moyenne" car basE9%e sur l'obfuscation,
envoyer du sable en l'air  (ou de l'encre dans l'eau)
et non un systE8%me mathE9%matique quantifiE9%.

"on dE9%place des bits un peu partout et on admire
le rE9%sultat en pensant que les autres n'y comprendront rien..."
le type de systE8%me qu'on n'utilise plus depuis un siE8%cle,
sauf dans certains systE8%mes "pour la forme".

Quoted text here. Click to load it
bon...


en crypto et dans d'autres domaines touchant aux maths
et aux thE9%ories fondamentales de l'information,
les standards existent pour une chose :
E9%viter E0% tous de rE9%inventer la roue carrE9%e, ou triangulaire
comme ici.

Ensuite on peut changer les pneus, mettre des
rayons ou passer E0% la fibre de carbone...
mais E0% trop vouloir sortir des sentiers battus on
se retrouve dans les ronces.

Je ne suis pas un cryptographe, j'ai juste vu et compris
que par le passE9%, aucun systE8%me n'est parfaitement fiable,
donc il n'y a pas de remE8%de (hacheur, crypteur) miracle,
mais par contre il y a plein plein plein de systE8%mes
qui ont E9%choutE9% et il faut comprendre pourquoi, afin
de ne pas faire les mEA%mes erreurs. J'en ai identifiE9% plusieurs
dans ce que tu proposes et je montre qu'avec un simple
hash bien utilisE9% (et qu'on sort un peu du sentier,
SANS compromettre sa soliditE9%) on a un rE9%sultat correct.

Quoted text here. Click to load it

cf plus haut : tu fais reposer ta "soliditE9%" sur "l'ignorance"
ou "l'obfuscation", c'est pas bien.

Quoted text here. Click to load it
l'avantage de ma mE9%thode est justement qu'elle est E9%prouvE9%e,
documentE9%e, on connait ses forces et faiblesses.
toi tu en es bien incapable, d'une part parce qu'aucune
E9%tude ne permet de quantifier ses qualitE9%s, d'autre part...
parce qu'elle n'existe que dans ta tEA%te :-)

Quoted text here. Click to load it

tu proposes pas de la sE9%curitE9%, juste de la poudre aux yeux donc...

et d'ailleurs toi non plus tu ne connais pas l'algo que tu proposes,
j'attends de voir ton code source ! :-P

(si si je suis sE9%rieux, j'ai envie de voir :-D)

Quoted text here. Click to load it
soit environ 17000 messages par jour,
dont on connait la monotonicitE9% du contenu.
miam miam :-)

Quoted text here. Click to load it

1) ton algorithem suggE9%rE9% ne prE9%sente
que de la diffusion, pas de la confusion.
ce n'est PAS de l'encryptage, juste du brouillage.

2) faire reposer la "sE9%curitE9%" sur le secret de l'algo
est illusoire.

Quoted text here. Click to load it

ce que tu dE9%cris c'est une sorte de jeu de bonneteau, donc
de permutations avec beaucoup de "sel"...
je ne suis pas impressionnE9% :-)

Quoted text here. Click to load it
ah mais il peut faire des E0% cF4%tE9%s, hein ;-P
c'est que E7%a paie mal, fonctionnaire,
et tu ne peux mEA%me pas EA%tre syndiquE9%...

Quoted text here. Click to load it
grmpfh....

c'est pas comme E7%a qu'on fait un systE8%me sFB%r, E0% ma connaissance.
E0% chaque objection que je ferai, tu ajouteras une autre couche
de "brouillage" et E7%a continuera et continuera, jusqu'E0% devenir
plus complexe que DES :-D

Quoted text here. Click to load it
S'il n'y a pas de nE9%gociation prE9%alable d'une donnE9%e secrE8%te,
il n'y a pas de sE9%curitE9%, et n'importe qui ayant compris
ton super systE8%me (dont j'attends encore de voir le code source)
va pouvoir gE9%nE9%rer ton flux de donnE9%es pour faire croire
que le systE8%me fonctionne et la cave E0% vins est sous bonne garde.

Quoted text here. Click to load it
dans ce cas ce que tu dE9%cris est la sortie d'un gE9%nE9%rateur pseudo-a=
lE9%atoire,
un "keystream" E0% la maniE8%re d'un "stream cipher", voir
http://en.wikipedia.org/wiki/RC4
"RC4 generates a pseudorandom stream of bits (a keystream).
  As with any stream cipher, these can be used for encryption
  by combining it with the plaintext using bit-wise exclusive-or;
  decryption is performed the same way (since exclusive-or is a
  symmetric operation). (This is similar to the Vernam cipher
  except that generated pseudorandom bits, rather than a
  prepared stream, are used.)"

Tu noteras que les concepteurs consciencieux de systE8%mes de sE9%curitE9%

(la NSA mise E0% part) se gardent bien d'inclure des bits de la clE9%
dans le flux encodE9%, quelle que soit la position.


Quoted text here. Click to load it

diffusion, mais pas confusion.

ah et aussi : clE9% ou "E9%lc" ? keystream ou key ?

et pourquoi, mais D4% pourquoi foutre la clE9% dans le message ???
c'est une signature qu'on veut, pour autentifier le message,
pas le code du coffre !

Quoted text here. Click to load it

et lE0%, c'est la cata :
  - l'alE9%atoire n'existe pas dans un CPU/MCU
  - la mEA%me source d'entropie (en fait, l'E9%tat du gE9%nE9%rateur)
     va EA%tre utilisE9%e pour "clE9%" et le reste, d'oF9% corrE9%lations=

  - l'arbitraire d'un codeur : http://xkcd.com/221 /

Quoted text here. Click to load it
oui donc pour toi le moyen de cacher un systE8%me pas fiable est de le
noyer dans le bruit... sFB%r, E7%a augmente l'entropie mais pas la sE9%cu=
ritE9%.

Quoted text here. Click to load it
s.

j'attends ton code source :-)
au fait, je t'ai fourni le mien, j'attends ta critique ...
moi je sais oF9% je peux encore un peu blinder mon systE8%me
mais j'ai voulu garder le code simple.

Quoted text here. Click to load it

tu remarqueras que tu ne fournis mEA%me pas de donnE9%es E0% regarder,
juste des grandes idE9%es...

Quoted text here. Click to load it

bien, bien, donc technique nB0%42 pour fiabiliser un algo pas fiable :
lui accoler d'autres algos pas fiables. E7%a marchait E0% l'E9%cole prima=
ire
mais ensuite, on voit rapidement les limites. D'oF9% l'apparition des
standards...

Quoted text here. Click to load it
haha c'est mignon ^_^

Quoted text here. Click to load it
moi, un peu.

dE9%jE0%, mal utiliser ou inventer des noms montre qu'il te reste
encore pas mal E0% apprendre :-) je ne suis qu'un amateur, je
le reconnais, mais je reconnais aussi dans ce fil plein de signes du peti=
t
cryptographe dE9%butant ^_^ mais c'est en se cassant les dents
qu'on apprends, j'en suis conscient. et il faut bien commencer
quelque part.

 > Toujours est-il que le rE9%sultat
Quoted text here. Click to load it
mais pourquoi DIABLE fous-tu une clE9% dans le flux ???
c'est lE0% la faiblesse fondamentale, le non-sens de ton systE8%me.

et tu as encore entretenu la confusion entre "clE9%" et ta "E9%lc",
on ne va pas avancer :-/

Quoted text here. Click to load it
oh mais tu as tous les droits.
c'est juste qu'il ne vaut mieux pas que tu prE9%tendes concevoir
des systE8%mes de sE9%curitE9%.

Quoted text here. Click to load it
justement l'inverse :
  si tu ne synchronises pas, avec liaison bidirectionnelle,
  tu ne peux pas garantir l'origine d'un message ou mEA%me
  les attaques par "replay".

Quoted text here. Click to load it
ah tiens, un autre angle de "discussion" apparait...

Quoted text here. Click to load it
(attention, quand tu t'E9%nerves, tu E7%oE7%ottes :-D)

sur le fond :
je n'ai rien E0% analyser, juste de vagues affirmations concernant
des bits alE9%atoires et d'autres bits d'une clE9% qui se balade dans
un message E0% accordE9%on... on appelle E7%a "snake oil" dans le jargon =
crypto.

Quoted text here. Click to load it
"arbitrairement" : lE0% est la faiblesse du raisonnement.
en crypto, le seul arbitraire est la clE9%.

Quoted text here. Click to load it
oh que non.
mais ensuite prE9%tendre que E7%a va rE9%sister, parce que soi-mEA%me
on ne voit pas les failles, relE8%ve de ... hmmmm... voilE0% :
l'ignorance et l'optimisme.

Quoted text here. Click to load it
c'est trE8%s prE9%tentieux de dire E7%a, prouve-le.

donc E7%a veut dire que les standards actuels du NIST comme
AES http://fr.wikipedia.org/wiki/Advanced_Encryption_Standard
sont de la poudre aux yeux ?

Quoted text here. Click to load it

c'est facile E0% dire mais tu n'as rien d'autre E0% me fournir.

d'autre part tu imagines que puisque toi tu ignores
quelque chose, ou n'est mEA%me pas conscient que E7%a existe,
d'autres ne peuvent forcE9%ment pas le savoir non plus.

Quoted text here. Click to load it
alors code-le pour le prouver :-)

Quoted text here. Click to load it

tu n'as pas donnE9% de preuve *formelle* du contraire.

Quoted text here. Click to load it

ben j'ai publiE9% du code source, E0% lui de voir s'il prE9%fE8%re
inventer un autre chateau de sable, ou utiliser des briques
E9%prouvE9%es.

Quoted text here. Click to load it
non, juste plus pE9%nible.

l'inviolabilitE9% informationnelle ne peut EA%tre garantie que par les ma=
ths
correctement mises en oeuvre. le reste dE9%pend de l'E9%paisseur de la co=
uche de titane :-)

Quoted text here. Click to load it

l'avantage des standards en crypto est de fournir un cadre prE9%cis
et des bornes infE9%rieures sur la complexitE9% de l'attaque.
tu n'en fournis aucune ainsi qu'aucun moyen de le prouver.
moi je n'ai rien eu E0% rE9%inventer, juste utiliser judicieusement.

Quoted text here. Click to load it
mais E7%a ne le rend pas plus sFB%r

Quoted text here. Click to load it

mais si j'ai bien compris :
tu envoies ta "E9%lc" originale dans le message, parce que tu la gE9%nE8%
res
"alE9%atoirement" E0% chaque nouveau message. Donc tu t'exposes
aux attaques par rejouage.

alors oui tu pourrais par exemple mE9%moriser tous les "E9%lc" dE9%jE0% e=
nvoyE9%s
pour vE9%rifier que c'est pas rejouE9% mais ta taille mE9%moire va explos=
er.

Quoted text here. Click to load it
montre-le :-)

Quoted text here. Click to load it
possible, mais moins sFB%r.

Quoted text here. Click to load it
non puisqu'on sait que le message E0% transmettre, lui, ne change pas :-)=

ton entropie effective est proche de 0 bits ... puisque tu envoies
tout le temps la mEA%me chose. ta "E9%lc" est comme un "sel",
que tu fournis dans le message E0% des fins plus de fiabilitE9%
que de sE9%curitE9%.

Quoted text here. Click to load it
et parce que tu sors des sentiers battus, tu te prends
dans les ronces, et au mieux tu rE9%inventes la roue.

Quoted text here. Click to load it
connu pour marcher.
"procE9%der autrement" t'expose E0% plus que rE9%inventer la roue :
tu risques fortement de retomber sur des types de failles
dE9%jE0% maintes fois exploitE9%es mais dont tu ignores l'existence.

Quoted text here. Click to load it
la prudence ?

Quoted text here. Click to load it
NE JAMAIS UTILISER DE LFSR POUR UN SYSTEME CRYPTO !!!
la confusion et diffusion sont bonnes mais tellement
dE9%terministes qu'on ne les utilise plus depuis les annE9%es 50...

 > si tu en croises PLUSIEURS, chacun ayant
Quoted text here. Click to load it
2 objections mathE9%matiquement prouvables :
  1) croiser/chainer/combiner plusieurs LFSR revient E0%
      obtenir un autre LFSR. donc passer du temps
      E0% trouver une combinaison "maline" de LFSR est
      une perte de temps.
  2) une fois qu'on a compris que plusieurs LFSR combinE9%s
      reviennent E0% un autre LFSR, alors on peut utiliser
      d'autres attaques : en connaissant 2N bits en sortie
      du LFSR , on peut reconstruire aussi bien le polynF4%me
      que l'E9%tat du LFSR.

c'est pas moi qui le dis, c'est Schneier.

d'autre part : comment tu initialises ton LFSR au dE9%but
de chaque nouveau message ?

conclusion : oublier les LFSR.

 > Et cela ne nE9%cE9%ssite
Quoted text here. Click to load it

oui, ils sont tellement dE9%terministes...
par curiositE9% tu voulais combien de bits pour ton LFSR ? :-)

Quoted text here. Click to load it

je l'ai expliquE9% : il prE9%calcule le message qu'il attend
(en avec le mEA%me algo et les mEA%mes donnE9%es que le capteur)
et compare le message avec celui entrant.

cette approche est possible justement parce que l'entropie
effective est proche de zE9%ro : on s'attend E0% un message,
au pire un deuxiE8%me indiquant l'effraction.
on peut donc les prE9%calculer.

autrement il faudrait utiliser un "block cipher" qui lui
est plus complexe, mais permet d'encoder plus de messages.

Quoted text here. Click to load it
bof... E7%a pourrait EA%tre un cache-misE8%re pour ton super-systE8%me,
mais E7%a part toujours de suppositions non mathE9%matiques.

Quoted text here. Click to load it
meilleure que celle d'une personne qui
  - compte sur le secret de l'algo
  - ne publie aucun code source pour E9%tayer ses dires
  - utilise un LFSR dans un algo de crypto (lE0% c'est le ponpon)
j'arrEA%te lE0%, je ne veux pas jeter la premiE8%re pierre,
E9%tant donnE9% qu'E0% une E9%poque moi aussi je pensais que mes
systE8%mes E9%taient meilleurs "parce que je les avais inventE9%s" :-)

Quoted text here. Click to load it
moi je me suis fait les dents avec des ensembles de Mandelbrot
et des automates cellulaires... on voit ce que E7%a donne aujourd'hui ;-)=


Quoted text here. Click to load it
dE8%s que l'ami voit SHA, il sait qu'il a affaire E0% une TRES grosse
bEA%te, et comme les constantes et rondes sont changE9%es, il ne peut
pas utiliser les rainbow tables publiques.

Quoted text here. Click to load it
t'as vu aussi E0% quelle heure j'ai E9%crit E7%a ? :-P

mais on va "compter les points" !

ta mE9%thode "dahut" :
   - repose sur l'obfuscation de l'algorithme
   - n'existe pas / aucun code source n'a E9%tE9% proposE9%
ma mE9%thode "E9%lE9%phant" :
   - repose sur un systE8%me E9%prouvE9% (subtilement modifiE9%) et quant=
ifiE9%
   - existe (code source publiE9%)
   - implE9%mentation sans effort se codage ou de rE9%flexion/invention
   - requiert approx. 50 octets dans un PIC

bon, je retourne faire joujou avec mes FPGA :-)

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

Re: Alarme sans fil gérée par µC.
On Mar 4, 8:15 pm, whygee

| c'est toi qui soutiens de pouvoir remonter au message original
| sans savoir en extraire la clE9% ni connaitre l'algo utilisE9%

Quoted text here. Click to load it

Ben non, ne le dis pas, contente-toi de l'affirmer.

Quelques prE9%cisions :

Ma suggestion visait E0% rE9%pondre aux besoins limitE9%s
d'Emile - et non E0% rivaliser sur le terrain de la crypto.
Tu as prE9%tendu pouvoir remonter au message d'origine
mais n'as jamais pu le prouver malgrE9% mes demandes,
tu esquives les questions en rE9%pondant par d'autres questions,
t'appropries des algos E9%crits par d'autres,
cites des sources sous l'argument d'autoritE9%,
et tu finis par vanner d'un ton condescendant.

Quoted text here. Click to load it

C'est ca ton truc ?  DE9%solE9%, j'ai passE9% l'E2%ge.
Un bon E9%lE8%ve apte E0% reproduire ce qu'il a appris
en avancant droit sur un chemin tracE9% par d'autres,
c'est trE9%s contemporain comme conditionnement.
Le sujet E9%tait prometteur, dommage que tu l'aies enterrE9%
dans des orniE8%res. Tant pis, et je n'en garde aucun grief.

Quoted text here. Click to load it

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

Bonsoir Jean-Christophe
ha ba non ! pas d'accord ;o)

ce qui doit etre transmit et deduit d'une maniere ou d'une autre dans
la trame c'est simplement la possibilité de retrouver la (bonne) clef.

Cette(les) clef doit etre déjà embarquée sur les terminaux.
Sans rentrer sur de la crypto dure, il suffit de transmettre un octet A
( déjà 256 possibilitées) et d'associer la valeur A pointant sur un
tableau rempli de chaque coté avec une clef identique (cryptage
symetrique), clef qui reste(ra) parfaitement discrete (en contenu et
taille) puisqu'elle ne sera a aucun moment "ON AIR"

mais là on sort de l'electronique
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

Je reste persuadé que le meilleur moyen de dérouter un voleur, c'est de
sortir des sentiers battus et de se faire une norme perso. Genre
envoyer les bits dans le désordre, moduler hors normes, bref faire un
truc absolument pas standard et totalement inattendu. Le voleur est
rarement un électronicien/cracker hors pair, et avec un matos de base
il ne pourra pas faire le rétroprocessing nécessaire et s'attaquera au
voisin.

Mais ça n'est qu'àmha.

--
LeLapin



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

Principe de base :
Ce qui tient longtemps, n'est pas "publiquement" documenté ;o)
Rvl



Re: Alarme sans fil gérée par µC.
Quoted text here. Click to load it
"sE9%curitE9% par le secret", c'est E7%a ?
demandez E0% Sony : ce qui tient longtemps
c'est tout ce qui n'est pas intE9%ressant.

mEA%me en rE9%alisant SHA-1 (qui est un hash simple) dans un PIC,
ce qui est tout E0% fait possible (bien qu'indigeste)
il y a toujours la possibilitE9% de se faire avoir
par des rainbow tables, une rE9%alisation mauvaise
(rE9%utilisation accidentelle de vecteurs) ou
une cryptanalyse de base (xorer un message
avec une clE9% privE9%e ? autant la transmettre !)

bon j'arrEA%te lE0% :-)

Quoted text here. Click to load it
yg

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

Re: Alarme sans fil gérée par µC.
On Mar 3, 11:38A0%pm, LeLapin

Quoted text here. Click to load it

Tout E0% fait d'accord avec toi.

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

Quoted text here. Click to load it

Salut HervE9%.

Quoted text here. Click to load it

Certes, mais il me semble que tu pars du principe qu'il
suffit de connaitre la clE9% pour dE9%crypter la trame, or :

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

J'ajoute encore qu'il est possible de disperser
les bits de la clE9% arbitrairement dans la trame :
mEA%me en connaissant la version non cryptE9%e de la trame,
( ce qui n'est pas le cas du vilain cambrioleur lambda )
tu pourrais par exemple tenter des XOR avec la trame cryptE9%e
pour retrouver la clE9%, etc ... mais cela ne marchera pas :
la combinatoire est beaucoup trop E9%levE9%e.

A l'inverse, mEA%me si tu as E0% la fois
la trame encryptE9%e ET la clE9% (en clair)
tu ne sais toujours pas comment dE9%crypter la trame ...

Quoted text here. Click to load it

Ah oui, c'est pas mal du tout comme E7%a, totalement opaque.

Mais (je dE9%fends a crE8%merie :o) cela nE9%cE9%ssite une table,
( bien qu'une table ne coFB%te pas grand-chose )
tandis-qu'avec ma mE9%thode pas besoin de table;
certes la clE9% elle-mEA%me est bien transmise,
mais elle est totalement introuvable dans la trame.

Quoted text here. Click to load it

Oui, mais bon, la culture gE9%nE9%rale,
le plaisir d'E9%changer des idE9%es ...


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

Je ne programme pas encore en C je dE9%but j'en suis qu'au basic et lE0%
je dE9%but en ASM donc je suis lent E0% assimiler lol

je pensais pour le CRC envoyer la trame 3 fois et si au bout de 3 X
c'est la meme alors je valide...
Pour la fonction XOR peux tu sil te plait m'expliquer basiquement le
principe ?

Merci

Emile

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

Y'a pas de ou exclusif dans le jeu d'instructions du PIC ? Ca
m'étonnerait bien.
Vérification faite, tu as deux instructions selon le besoin :
XORWF f,d     Logical exclusive OR with W with constant
XORLW k     Logical exclusive OR with W with f

Cette fonction est implémentée sur quasi tous les Basics et Cs. Mais là
je connais trop peu le PIC pour te le détailler.

Pour la définition de la fonction, c'est tout bête, ça fonctionne bit à
bit comme la porte logique du même nom.
Wiki l'explique très bien :
http://fr.wikipedia.org/wiki/Ou_exclusif

--
LeLapin



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

Quoted text here. Click to load it

LeLapin t'a donnE9% un lien : le XOR est un ou-exclusif.
( c'est l'un OU l'autre MAIS pas les deux E0% la fois )
C'est une fonction de base comme le ET et le OU.
Le gag est que c'est rE9%versible, d'oF9% son intE9%ret.
Si 'A' est ton message et 'B' ta clE9% de cryptage :

 'A' XOR 'B' 3D% C  (le message 'A' est encryptE9% en 'C')
 'C' XOR 'B' 3D% A  (le message 'C' est dE9%cryptE9% en 'A')

Donc on fait la mEA%me chose pour crypter que pour dE9%crypter.
Mais c'est archi-connu par tout le monde : coder un message
de cette faE7%on avec une clE9% d'un octet ne rE9%sistera pas
plus de trente secondes E0% un gamin (mEA%me un tout petit :o)
Donc il faut implE9%menter un truc maison plus robuste.

Mais de toutes faE7%ons, ce n'est pas lE0%
qu'est le point faible de ton alarme radio.

Quoted text here. Click to load it

Que se passe-t'il si j'E9%mets continuellement du bruit sur
la mEA%me frE9%quence que celle de tes E9%metteurs/rE9%cepteurs ?
Ils ne pourront plus se transmettre de donnE9%es,
et je pourrai tranquillement dE9%pouiller ta cave E0% vin ...
et l'encodage des donnE9%es ne peut rien contre cela.

Site Timeline